/*
 * title "The comma operator"
 * author "Dylan Lom"
 * date "2021-07-02"
 * link stylesheet /main.css
 */

# $(echo $title)

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:

<pre><code>
    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);
</code></pre>

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...

<pre><code>
    // Prototype in some made-up language
    printweather: (name: string, temp: int) -> int
    // Function call
    printweather "Dylan", 21+22
</code></pre>

Now visually, we're approaching functional languages and LISPs, but with
commas...

## Similarities to Python

In Python you can create tuples in this manner:

<pre><code>
    >>> 1,
    (1,)
</code></pre>

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:

<pre><code>
    >>> [1,]
    [1,]
    >>> x = 1,
    >>> [x]
    [(1,)]
    >>> list(x)
    [1]
</code></pre>

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:

<pre><code>
    >>> one, = [1]
    >>> one
    1
    >>> name, temp = "Dylan", 21+22
</code></pre>

## Conclusion

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...