this post was submitted on 17 Oct 2023
1 points (100.0% liked)

Lisp

53 readers
3 users here now

founded 1 year ago
MODERATORS
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] IReadToKnowIAmAlone@alien.top 1 points 1 year ago (2 children)

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!

[–] release-account@alien.top 1 points 1 year ago (1 children)

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.top 1 points 1 year ago (1 children)

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

[–] Soupeeee@alien.top 1 points 1 year ago
[–] fvf@alien.top 1 points 1 year 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.