[Cuis-dev] Thoughts about symbols

[Luciano Notarfrancesco]

Thanks for sharing Martin, great insights!

On Tue, Jan 28, 2025 at 14:02 Martin McClure <martin at hand2mouse.com> wrote:

> 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/20250128/5461405c/attachment.htm>