[Cuis-dev] Thoughts about symbols

[Juan Vuletich]

Hi Luciano,

On 11/29/2024 2:27 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>
> If we think of == as equality, and = as an equivalence relation,
>

That's Okish... I think you're talking "Math-wise".

In Math there's usually no (never any?) mutable state, so there's no 
concept of a 'thing' not being equal to a previous self (i.e. not #=) 
while keeping identity (i.e. stilll #==). In that mindset and specific 
scope, there's no need to talk about identity. So, "thinking of #== as 
equality" makes sense, although I'd use a different selector to avoid 
confusion.

> the Symbol #xxx is just the equivalence class of all Strings ‘xxx’, 
> and any String instance ‘xxx’ is a representative of that equivalence 
> class. This construction is useful if you need to use objects under 
> equality = in a context where equality is == (for example, keys of an 
> IdentityDictionary). And, an IdentityDictionary with Symbols as keys 
> is just like a Dictionary with Strings as keys.
>

So far, so good.

If we only used Symbols, SmallIntegers and Characters ( where #== and #= 
are "the same"), there would be no need for a separate 
IdentityDictionary class. That could be a nice simplification.

> So, from this point of view, a symbol should be all about equality, 
> about = and #hash.
>

I believe it indeed is!

> Now, in Cuis we have two parallel symbol classes depending on the type 
> of characters in their names: Symbol and UnicodeSymbol.
>

Yes. And I see no contradiction between this and your last claim. #==, 
#identityHash, #= and #hash are treated with enough care than having two 
classes is not a problem. This applies to Strings too. If you have a 
String and a UnicodeString with same Characters in same order, they will 
#= to true and will answer the same #hash (and that is true even for 
UnicodeStrings with different Unicode Normalization Forms!).

> Would it be better to replace this with a single and more general 
> Symbol with an instance variable ‘representative’, that can be a 
> String, or a UnicodeString (or possibly any object)? What do you think?
>

I don't see what we'd gain by doing that. It makes sense, but I don't 
see a problem in the current design, and I think it makes sense too.

Thanks,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich