For example, I’ve seen someone defining a package like so:

(defpackage :foobar
  (:use :cl))

instead of:

(defpackage foobar
  (:use cl))

Is there any actual difference? Or it’s just a personal preference, and has no effect on the program at all?

  • fvf@alien.topBEnglish
    1·
    11 months ago

    Better use #:foobar to make it a symbol that isn’t interned at all.

    • IReadToKnowIAmAlone@alien.topBEnglish
      1·
      11 months ago

      Is interning that bad ?

      Perhaps I’m misunderstanding it, but IMHO, interning means that particular symbol string will be recorded/hashed once in a map like data structure and thereafter will be referenced everywhere using a pointer to it, whereas frequently used but uninterned symbol would imply a new string always. i.e. memory savings with interning, but ofcourse too many interned symbols which are not used at all would be waste.

      Any clarifications to my (mis)understanding are welcome.

      Thanks!

      • fvf@alien.topBEnglish
        1·
        11 months ago

        An interned symbol will hang around forever, adding load to GC, memory footprint, symbol clutter, etc. A non-interned symbol has nearly zero of any of these costs.

        These are very minor considerations, perhaps only meaningful for release-quality library code.

      • release-account@alien.topBEnglish
        1·
        11 months ago

        I prefer `#:foobar` because it simplifies auto-completion. Every time you start typing out a keyword, the package name tends to appear towards the top of the list, and it’s kinda annoying. Maybe we just need smarter auto complete frameworks that take the frequency of symbol use into account, but it’s easy enough just to use `#:foobar`.

        • SlowValue@alien.topBEnglish
          1·
          11 months ago

          Maybe we just need smarter auto complete frameworks that take the frequency of symbol use into account,

          Since quite some years there is company-prescient in case you are using Emacs with SLIME / SLY and company.el. Look at its readme to learn there exist other similar packages (Imo since more than a decade already).