One of the classes I'm taking this term alternates between Haskell and Smalltalk in trying to teach a bunch of seniors and graduate students "extreme programming" and how coding in the real world is different from in school. In one of the exercises we were working with an attempt to formulate Haskell-like tuples and lists in Smalltalk, in particular trying to debug the implementation we were given. We found numerous issues with the implementation, but one in particular has been nagging me. It indicates inherent limitations in the syntax of Smalltalk, but mulling it over, it seems to be an even deeper issue than that.
Part of the implementation for tuples was overloading the comma operator (normally string concatenation) to create pairs like
(a, b) or triples like
(a, b, c) etc. The problem was this, how do we do tuples of tuples? Using code like
((a, b), (c, d)) does not give us a pair of pairs, but rather is equivalent to
(a, b, (c, d)). I thought, at first, it was a problem of associativity; when the parser sees the second comma, the one after the b, it takes the preceding object and combines it with what follows, in effect it's acting like an operator for constructing lists. Reversing the associativity of the operator just gives us the same problem in the other direction yielding
((a, b), c, d). This is not an issue for Haskell because the parentheses are required and so they let us know for certain when we're done making a tuple. But in Smalltalk as with most languages, the parentheses are only there as suggestions on how to create a parse tree.
All this diagnosis I did for the exercise, but I've just struck something. ( There is a deep seated difference between "destructive" and "constructive" operations in any language. )