[Cuis-dev] Thoughts about symbols

Tue Jan 28 10:43:11 PST 2025

Martin, that looks like a very nice approach. I think we might have even
talked about it personally in the past but my memory is fragile...

The selector could also know the senders, so you'd have both implementors
and senders in a single place without any special/additional tracking.

It might even provide space for extension method namespaces, where a same
string could result in different selectors depending on some context. Might
be confusing to the programmer though.

@luciano: I don't know the reason behind #abc != 'abc', it was just like
that when I arrived and never felt the need to change it.

Cheers,
pocho

On Tue, Jan 28, 2025 at 4:02 AM 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/618b8cf1/attachment-0001.htm>