<div dir="ltr">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...<div><br></div><div>The selector could also know the senders, so you'd have both implementors and senders in a single place without any special/additional tracking. <div><br></div><div>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.</div><div><br></div><div>@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.<br></div><div><br></div><div>Cheers,</div></div><div>pocho</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2025 at 4:02 AM Martin McClure <<a href="mailto:martin@hand2mouse.com" target="_blank">martin@hand2mouse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Hi all,</p>
<p>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.</p>
<p>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 <i>partially</i>
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.<br>
</p>
<p>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.</p>
<p>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 <i>not</i> 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.</p>
<p>Compare that to the conventional way, where a full method lookup
is based on <i>two</i> 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.<br>
</p>
<p>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.<br>
</p>
<p>Regards,</p>
<p>-Martin<br>
</p>
<div>On 1/27/25 10:20 PM, Luciano
Notarfrancesco via Cuis-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div dir="auto"><span style="font-family:-apple-system,helveticaneue;font-size:16px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0);display:inline">It
is interesting to imagine what other things a symbol could
be, if not text</span><span style="font-size:16px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:-apple-system,helveticaneue;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)">,
for example in a graphical language. However I </span>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...</div>
<div dir="auto"><br>
</div>
<div dir="auto">Interesting that in Bee #abc ~= ‘abc’… is there
a good reason to do that? In Cuis they are equal.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Regards,</div>
<div dir="auto">Luciano</div>
</div>
<div dir="auto"><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2025 at
20:24 Javier Pimás <<a href="mailto:elpochodelagente@gmail.com" target="_blank">elpochodelagente@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Now that the thread has been resurrected. I
also thought about this when working on Bee. A
<div>symbol being a holder of a token _and_ also an arity.
I always thought of parsing elements and</div>
<div>counting colons an unpleasant part of Symbol design.</div>
<div><br>
</div>
<div>We never tried it, as it would take quite some work,
and I feared we could find some insurmountable</div>
<div>problem in the road ending with a waste of too much
time. The extra benefit of dropping the duplicated</div>
<div>unicode/String hierarchy was motivating though.</div>
<div><br>
</div>
<div>Some questions I got at that moment:</div>
<div>- How would equality between String and Symbol work
(in Bee #abc = 'abc' is false).</div>
<div>- What would be the required protocol for the token?
Can we have horses as tokens? what if they move a leg :)</div>
<div>- The token would become something opaque, without
needing to be a String, hence without its api, would
that be good or bad?</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Pocho</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2025 at
9:38 AM Luciano Notarfrancesco via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 27,
2025 at 19:33 Luciano Notarfrancesco <<a href="mailto:luchiano@gmail.com" target="_blank">luchiano@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">I tend to think of #= as an
equivalence relation, and #== as the actual
equality of set theory.</div>
</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">I mean, not really “the equality of
set theory”, but the underlying, most basic
equality of elements (instances) in Smalltak.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto"><br>
</div>
</blockquote>
</div>
</div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
</blockquote>
</div>
</blockquote></div>