stz unexpected syntax

As I'm making an experimental parser for stz I came across something interesting that I'd overlooked. It all stems from the type information in a method or a block (or a signature):

[ a foo: b | uint, uint -> uint | ... ]

It's the uint, uint → uint that I'm talking about here. The intention is to run this code at compile time with an interpreter in the compiler to get the correct result. Except , is for making lists.

The uint, uint should create a list of arguments and the → should then convert that list in to a method-type which has argument types and a return type.

But lists are meant to be inside brackets, eg: (uint, uint) → uint. But I don't want to have to add brackets everywhere in the type information. For one, it's ugly, and for two... it's two extra characters.

This leads me to the question - can type-inferred lists be made without brackets? I suspect the answer is yet and here's where it gets neat. If that's true then what does the following parse into:

a + b c: d e, f

I've deliberately left all brackets off just to make it ambiguous looking. Because the basic rule is 'left evaluates first' it should mean that the order of execution is as follows:

t1  = d e
t2  = b c: t1
t3  = a + t2
out = t3, f

But if the precedence was 'right evaluates first' then we'd instead get:

t1  = d e
t2  = t1, f
t3  = b c: t2
out = a + t3

And how about this:

a x1: b, c x2: d, e

Is that an x1:x2: call or an x1: followed by an x2: call?

The same problem happens between binary calls and keyword calls:

a x1: b + c
a + b x1: c

Does the + happen first or the x1: call?

The rule should be 'the right evaluates first' because the right hand side is always an argument. If you want the left to evaluate first then you put it in brackets:

(a x1: b) + c
(a + b) x1: c

Now that we know that the right evaluates first we can write something like this:

opengl clear-color: 0.0, 0.0, 0.0, 1.0

glClearColor(0.0, 0.0, 0.0, 1.0);

Of course since we're using stz we'd likely make a color structure and a nicer API to opengl. Or may be we wouldn't (or shouldn't?), but if we did it'd look like this:

[ _ clear-color: color | package, rbga-color |
  system glClearColor: color red, color green, color blue, color alpha ]

opengl clear-color: black

Of course this doesn't actually make the following code 'nice':

a x1: b, c x2: d, e

Because that would be interpreted as:

a x1: b, (c x2: (d, e))

And what we really want it to do is this:

a x1: (b, c) x2: (d, e)

The answer is to make the precedence of , be lower than anything else.

Oh and also - we can use inferred type lists with a typed variable, which is kinda neat. Two ways to do the same thing makes me nervous but they are slightly different:

people: (list of: person) = jane, bob, sam
people = ( person | jane, bob, sam )

The first version implies the types of jane, bob, and sam. The second version implies the type of people.