Syntax discussion -- should we overhaul the syntax?

[SebastianMestre]

The parser, and the current (concrete) syntax both have a number of issues that need addressing. I propose a parser rewrite, accompanied with a syntax overhaul.

This thread is so we can talk about it, and come up with some ideas for how it could look like.

I will start by proposing a few different things, then we can discard them, and add new ones, as we go.

[SebastianMestre]

Idea 1 -- unified call syntax

The whole thing with poly parens and normal parens is ugly. Instead, we could just use parens. Also, for consistency, we could use parens for constructors. Then, we could determine whether it's a typefunc call, a function call, or a constructor call using unification during metacheck.

letters : array(string()) = make_array(5, "A");

Drawbacks:

• Making the type arguments optionally explicit is tricky, because it all looks the same. (I don't actually know how hard this would be, but I'm pretty certain it's not too hard) (NOTE: we currently don't have this feature, for various reasons)

func := make_array(string());               // this is a function from (int, string) to array of string
value := make_array(5, "A");                // this is an array of string
also_value := make_array(string())(5, "A"); // this is an array of string

Alternative -- bracket typefunc calls

If we use brackets ([ and ]) for typefunc calls, it makes the optional type parameters easier, and, since it would be rare in real code, we don't need to worry much about the case of a polycall returning an array, which we index into.

func := make_array[string[]];               // this is a function from (int, string) to array of string
value := make_array(5, "A");                // this is an array of string
also_value := make_array[string[]](5, "A"); // this is an array of string

Consequence 1

If we use parens for constructors, there is no way a block statement can get confused by the arguments to a constructor. Thus, we could omit parens from if-else statements (and others, too).

[SebastianMestre]

Idea 2 -- do-end style blocks

I don't like these, but maybe you do. I got the idea from Ruby.

fib := fn (n) do
    a := 0;
    b := 1;
    while (n != 0) do
        sum := a + b;
        a = b;
        b = sum;
    end
    return a;
end;

[SebastianMestre]

Idea 3 -- different / shorter functions

Now that we have more experience with parsing, we can afford neater function expressions

// idea 1
sum := |x, y| x + y;

// idea 2
sum := (x, y) => x + y;

// idea 3
sum := fn (x, y) = x + y;

// idea 4
sum := fn (x, y) x + y;

[SebastianMestre]

Idea 4 -- get rid of colons

In pretty much every place where they appear by themselves, colons could be easily removed, and be replaced by whitespace.

version string<::> := "v1.0.36";
sum := fn(x int<::>, y int<::>) => x + y;
pair := struct {
  first  int<::>;
  second int<::>;
};

[SebastianMestre]

Idea 5 -- Use semicolons instead of commas in function calls

After writing a bit of Jasper code, I found myself doing this refactor quite often:

// before:
x := foo<::> { expr1; expr2; expr3; };
y := foo<::> { expr4; expr5; expr3; };

// after:
make_foo := fn(value1, value2) => foo<::> { value1; value2; expr3; };
x := make_foo(expr1, expr2);
y := make_foo(expr4, expr5);

I noticed that changing semicolons to commas, removing spaces, and, to a lesser degree, replacing braces for parens, was really annoying.

I propose changing comas to semicolons in function calls, and allowing a trailing semicolon on the argument list. Also, we should pick a stance on spaces around parens.

Whether we should change the constructor and call argument delimiters (namely braces and parens) is a separate discussion. (see Idea 1)

// before:
x := foo<::> { expr1; expr2; expr3; };
y := foo<::> { expr4; expr5; expr3; };

// after:
make_foo := fn(value1, value2) => foo<::> { value1; value2; expr3; };
x := make_foo ( expr1; expr2; );
y := make_foo ( expr4; expr5; );

Thoughts? @lushoBarlett