Use (A×B×C) names for TypedTuples

[shingarov]

Smalltalk-25 is, (to borrow Luciano's words) about "reimagining Smalltalk categorically". Tuples are meant to be the "product" half of the cartesian structure on data. (A×B×C) is the natural notation everyone expects for product types. It also nicely renders void as ().

The downside is that in the current syntax we lose homoiconicity. Two comments on this:

1. I am not sure if Smalltalk-25 wants to be more like Lisp, or like Haskell.
2. Maybe the blame is on the current syntax that () doesn't evaluate to void?

[janvrany]

The question is:

t1 := Int ⨰ String,
t2 := Compiler evaluate: t1 name.

Should t2 by the "same" tuple, that is Int ⨰ String?

If so, the code breaks for tuples where ivars (slots / elements) are named, for example:
TypedTuple ofAll: { #x -> Int . #y -> Int } (this was the idea behind my original name).

I do not know whether or not we want that.

Other than this comment LGTM.

[shingarov]

Should t2 be the "same" tuple

That's "the Lisp perspective" I mentioned in the commit message. The class name design of Smalltalk-80 follows along very nicely, in that the homoiconicity equation:

∀x. (Compiler evaluate: (x storeString)) = x

holds for classes because the class's name evaluates to the class. The bigger question is, whether we accept this principle, or do we accept the arguments of the Haskell designers against homoiconicity, and consciously reject #storeString. In the latter case,

the code breaks for tuples where ivars

is exactly what I am referring to when I say "The downside is..."

Shouldn't '×' be '⨰'?

If we follow the Lisp perspective, then yes. But if we follow the Haskell perspective, #⨰ is just an implementation hack because at this point of Building-the-Steam-Engine™, #× and #⨰ are not automatically the same, whereas #printString simply answers back a nice mathematical notation. This is where high-level design waters get muddy, because if we agree with Ken Iverson that the-most-natural-mathematical-notation IS the best programming language (and I do agree with him very strongly), then that is what the Compiler should accept. I.e. we have come to the conclusion that, regarding homoiconicity, Lisp wins over Haskell. Hmm, perhaps this PR is too narrow to discuss this huge question. Maybe we can even talk about it in Lund (with "the big guys" too)

[janvrany]

the code breaks for tuples where ivars

but, with this new ∷ (*) we can elegantly solve this, preserving homoiconicity for "tuple classes" just like ST80 does for normal classes.

So, I'm deferring merge of this until ∷ gets in and then update this PR.

(*) discussed privately

[shingarov]

Hmm. So now the difference between Named Records (i.e. #x::Int × #y::Int) and Algebraic Products (i.e. Int × Int, resulting in #_1::Int × #_2::Int) becomes even more crucial. Perhaps they should be two different Smalltalk-80 classes?

[janvrany]

Perhaps they should be two different Smalltalk-80 classes?

Yeah, I was thinking the same. Let's slow down a bit and let me think.