tfeb / symbol-nicknames Goto Github PK

In a proper version of this nicknames would not be symbols, just pairs of a name & package. Make things more like that:

• #6
• deleting a nickname should unintern the symbol.

I am not sure this is the right thing to do. In a real native implementation, where symbols had nicknames which were not themselves symbols, it would be. But symbol nicknames is never going to be that.

First of all, I think it is a very interesting thing that hopefully will become a semi-standard extension at some point :).

I am wondering if you saw symbol-links? It seems to be almost exactly the same thing (both the idea & infect/hack mechanics).
(repo link: https://github.com/Gleefre/symbol-links)

There is also some sort of discussion on the theme that happened in this reddit thread: https://www.reddit.com/r/Common_Lisp/comments/14bxxvz/symbol_links_or_how_to_create_aliases/
One seemingly important issue would be the second value of find-symbol:

I have many code which have case dispatching on second value of find-symbol, yes. All this would need to be changed. Any program which seeks to do any sophistication with symbols and packages will likely break if there are links.
-- u/zyni-moe

One more thing - I just implemented the symbol-link hack for CMUCL and CCL, so I thought you might be interested in that too.

P.S. i didn't use discussions because I don't know what they are, sorry for any inconvenience.

First of all, I'll state that symbol nicknames are obviously strongly desirable.
I've been dreaming about them for years...

Frankly, I'm fucking ECSTATIC just at the thought of (eq 'λ 'lambda).

Also, I'll make my own unit testing framework soon, and I'll have a macro called verify, or v, or ✔,
but I'd really rather just call it verify and encourage the user to import it as ✔ if they like.
(Doing the forwarding as a new macro is just gross, at least in the general case.)

But I digress...

So, I think the obvious Right Thing™ is just to make the package system properly object-oriented, so that the user can then trivially implement their own extensions such as package-local symbol nicknames on top. That wouldn't necessarily be less work, but it would absolutely be much more impactful in terms of opening up exciting possibilities.

So basically, you can think of cl:package and cl:symbol as being, like, standard-package and standard-symbol.

So there should be new package and symbol "marker classes" that both standard and user-defined packages and symbols must inherit from to be properly recognized as packages and symbols.

And then of course, you convert the usual cast into Generic Functions: find-symbol, intern-symbol, etc.
Seems like a pretty obvious idea to me, so there is probably not much to explain?
I'm sure the devil is in the details, but heh...

(edit: We would probably also need an extensible reader/printer and readtables, at least...)

On a related note, I would really fucking LOVE to be able to define my own types of arrays in this way, which would properly be recognized as "real" arrays by the system. Obviously I should be able to make a new kind of array that is just the aggregation of a sequence of other arrays, or an array that just reverses the sign of all its members, that kind of thing... (Obviously the entire language should be revised in this way... eventually.)

Anyway, obviously this is all quite badly written, but I figured I would not just sit back and let you waste your time attacking a tiny subset of the real problem... I hope this is deemed useful...

Why did you silently delete this obviously extremely important and historic discussion?