[Cuis-dev] Thoughts about symbols

[Martin McClure]

Hi all,

I just skimmed this thread, and want to make some comments on the idea 
of Symbols, even though they're in a rather different direction. These 
comments are not based on math, just software engineering ideas.

More than a decade ago, Andrew Black made a comment something like how 
identity comparisons (#==) were not a good part of the language and 
should not be used. That got me thinking, and I /partially/ agree with 
him. I now think of #== as a "systems programming" tool that should be 
avoided in application code. I now use #== mostly for things like 
defining a unique sentinel object for hashed collections that accept nil 
as a key. And that's more on the "systems programming" side of things.

Those thoughts about identity comparisons led me to think about why 
Symbols are what they are, and whether they are actually useful. I now 
suspect that Symbols are less a useful language feature than a neat 
trick that made it easier to implement Smalltalk selectors on a machine 
with limited resources.

So when I was designing Mist (Smalltalk in most respects), I didn't 
include Symbols. For selectors I used instances of class Selector. 
Selectors darn well knew what their arity was, and what string 
represented them in source code, and other things. Each Selector also 
had a method dictionary, keyed by class of receiver, and classes did 
/not/ have method dictionaries. This made method lookup simpler -- 
except in the case of #perform:, you know the identity of the Selector 
at compile time, so the Selector's method dictionary can be part of the 
method's literal frame (in a conventional Smalltalk architecture -- Mist 
allowed the method's code to reference the method dictionary directly) 
so you just do a single hash table lookup and you have the method.

Compare that to the conventional way, where a full method lookup is 
based on /two/ keys, the selector and the receiver's class. And you have 
to do lookups working your way up the class hierarchy until you get a 
match or run out of superclasses. So the Mist way is simpler at runtime. 
The drawbacks to the Mist way are that it takes more memory for the 
method dictionaries (and in pathological cases that could add up) and 
that it complicates the compiler/development tools.

Anyway, am I advocating we move toward getting rid of Symbols? No. But I 
think it's worth thinking twice before using Symbols in normal code, and 
only using them if it really does make your code more readable and 
easier to understand, or where they're required.

Regards,

-Martin

On 1/27/25 10:20 PM, Luciano Notarfrancesco via Cuis-dev wrote:
> It is interesting to imagine what other things a symbol could be, if 
> not text, for example in a graphical language. However I don’t see a 
> clear benefit for Cuis in allowing arbitrary objects for symbols 
> instead of only strings, and it would be difficult, as you point out, 
> because everywhere in the image we assume they are strings and they 
> correspond to identifiers and message selectors following the grammar 
> rules (binaries with some set of characters, keywords with colons 
> before each arguments, etc). AFAIK the VM doesn’t care what selectors 
> are tho… they could be SmallIntegers, or Morphs...
>
> Interesting that in Bee #abc ~= ‘abc’… is there a good reason to do 
> that? In Cuis they are equal.
>
> Regards,
> Luciano
>
>
> On Mon, Jan 27, 2025 at 20:24 Javier Pimás 
> <elpochodelagente at gmail.com> wrote:
>
>     Now that the thread has been resurrected. I also thought about
>     this when working on Bee. A
>     symbol being a holder of a token _and_ also an arity. I always
>     thought of parsing elements and
>     counting colons an unpleasant part of Symbol design.
>
>     We never tried it, as it would take quite some work, and I feared
>     we could find some insurmountable
>     problem in the road ending with a waste of too much time. The
>     extra benefit of dropping the duplicated
>     unicode/String hierarchy was motivating though.
>
>     Some questions I got at that moment:
>     - How would equality between String and Symbol work (in Bee #abc =
>     'abc' is false).
>     - What would be the required protocol for the token? Can we have
>     horses as tokens? what if they move a leg :)
>     - The token would become something opaque, without needing to be a
>     String, hence without its api, would that be good or bad?
>
>     Best regards,
>     Pocho
>
>     On Mon, Jan 27, 2025 at 9:38 AM Luciano Notarfrancesco via
>     Cuis-dev <cuis-dev at lists.cuis.st> wrote:
>
>
>
>         On Mon, Jan 27, 2025 at 19:33 Luciano Notarfrancesco
>         <luchiano at gmail.com> wrote:
>
>             I tend to think of #= as an equivalence relation, and #==
>             as the actual equality of set theory.
>
>
>         I mean, not really “the equality of set theory”, but the
>         underlying, most basic equality of elements (instances) in
>         Smalltak.
>
>
>         -- 
>         Cuis-dev mailing list
>         Cuis-dev at lists.cuis.st
>         https://lists.cuis.st/mailman/listinfo/cuis-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250127/f6065b0f/attachment-0001.htm>