I’ll prefix this with the fact that I have never done any sort of language
development, am only vaguely familiar with the terminology and am making wild
speculation around a shower thought; is ,
an operator?
I automatically lumped it in with as a syntactical token (see above if this is
not a thing), things like []{}();
; and in most languages it probably is. But
an interesting way of looking at it is like the :
(cons) operator in Haskell
You have, lets say, a function call:
printf("Hello %s, today is %d kelvin!", "Dylan", 21+274);
I think most people parse the comma here as a delimiter, delimiting where one expression ends and the next begins. But we can also look at it as constructing the list of arguments to pass to the function:
List args = "Hello %s, today is %d kelvin!", "Dylan", 21+274;
// Haskell cons operator:
// "Hello %s, today is %d kelvin!" : "Dylan" : 21 + 274 : []
printf(args);
Here we approach C’s array initilization (sub out the curlies from squares and you’ve got popular list initialisation a la python and js).
parameter args[] = {"Hello %s, today is %d kelvin!", "Dylan", 21+274};
Note: The included Haskell example won’t compile because it can’t handle lists with multiple types – just like the last C example, but it’s more for illustration than anything.
So, what if we just say functions accept lists of args (I think this is close to how LISP works – where an expression is a list with the first value being the function – but I’m not a LISP programmer and haven’t written anything in it…). For type-checking reasons we could generate anonymous types for the parameters (sort of how you might define a Props type for a JSX component), however the potential power of implementing the language in this way is defeated unless you can do compile-time type-checking on lists constructed at runtime…
// Prototype in some made-up language
printweather: (name: string, temp: int) -> int
// Function call
printweather "Dylan", 21+22
Now visually, we’re approaching functional languages and LISPs, but with commas…
In Python you can create tuples in this manner:
>>> 1,
(1,)
What’s neat about the Python example is that it illustrates something that
perhaps the example in the previous example didn’t: the end of the statement is
inferring the cons to the empty list (see the Haskell example where we needed
to explicitly :[]
to construct a list).
However when you approach it from this angle, the Python analogy breaks pretty quickly:
>>> [1,]
[1,]
>>> x = 1,
>>> [x]
[(1,)]
>>> list(x)
[1]
If Python was consistant with this approach both expressions would’ve evaluated
to what the second did – a list containing a single tuple. Obviously this
wouldn’t be very useful for a list construction, so the []
acts like a call
to the list constructor.
Python’s array deconstruction is also interesting to consider here, in how it relates to the argument list being expanded in the function called:
>>> one, = [1]
>>> one
1
>>> name, temp = "Dylan", 21+22
So this wasn’t very satisfying, nothing transformative came about considering a comma-operator in a traditional imperitive statically-typed language context, but I mostly wanted to write down this thought so I didn’t forget it :_). Maybe I should’ve mentioned that at the start of the article…