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?

  • lispm@alien.topBEnglish
    1·
    11 months ago

    The symbol will be interned in some package. A keyword symbol is in the package KEYWORD. That’s slightly better than to use the symbol of some other package, which “pollutes” that package with that symbol. ;-)

    An alternative, out of fashion because of the upper case, is to use a string “FOOBAR”.

    • 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).

    • paulfdietz@alien.topBEnglish
      1·
      11 months ago

      Using the string also means your code won’t work in Allegro with its optional non-standard symbol reading.

      • lispm@alien.topBEnglish
        1·
        11 months ago

        That’s about the so-called “modern mode”, where standard Common Lisp symbols internally have lower case names (which violates the Common Lisp standard) and the default readtable case is :preserve. In the standard it is :upcase. Also other predefined symbols have lowercase names.

        https://franz.com/support/tutorials/casemode-tutorial.htm

        Is that incompatible language change used by other implementations?

        See CLHS 1.4.1.4.1 Case in Symbols: http://www.lispworks.com/documentation/HyperSpec/Body/01_dada.htm

        • “As such, case in symbols is not, by default, significant.”

        • “The symbols that correspond to Common Lisp defined names have uppercase names”

        • eadmund@alien.topBEnglish
          1·
          11 months ago

          As an aside, I think that every Common Lisp implementation should support a modern mode. The upcasing behaviour of CL — defensible at the time — is in hindsight an easily-fixable mistake.