[donpdonp]

The syntax choices are really nice here. It has a lot of what I would pick for a language. The one-liner test cases are awesome, <> for generics is comfortable since I use rust, sum types like elm are awesome. If I were to add something (well take it away really) its to use whitespace for array element separators. Eliminates the whole trailing comma issue and looks cleaner, though I admit it might create parsing ambiguities. 'try expr', returning (val,err) is curious and I think I like it better already than try {} catch {}.

[munificent]

> If I were to add something (well take it away really) its to use whitespace for array element separators. Eliminates the whole trailing comma issue and looks cleaner, though I admit it might create parsing ambiguities.

Indeed:

    var array = [
      5
      - 3
    ]

Does that produce [5, -3] or [2]?

[jrajav]

I've sometimes wondered why not make `-` whitespace dependent to resolve this one. Signed numbers store the sign bit in their representation, so enforcing the sign character to be in the same word also seems reasonable - and is there anyone who would mind actually having to put at least one space around binary arithmetic operators? We've all agreed that that's the sane way to write them by now, yes?

[teo_zero]

I'm one of those who would complain. I often write n+1 and n-1 without spaces. And I hate C for preventing space removal from expressions like:

  *z = *x / *y;
  addr = mask & &x;
  x + ++y;

[dmoy]

Or ["5", "-", "2"] even

[archargelod]

> If I were to add something its to use whitespace for array element separators. Eliminates the whole trailing comma issue...

I like how Nim solves this problem: just allow trailing comma on last element. It makes easier to copy paste elements, move them around and even sort (e.g. in vim).

```

var list = @[

  a,

  b,

  c,

]

```

[KerrAvon]

Using the C for loop syntax is looney tunes, though. Do range support and leave that 70's stuff in the dust.

[donpdonp]

its got 'for k in list {}' (https://nature-lang.org/docs/the-basics/control-flow#iterati...) though array.for_each(lambda) is a better way to go, imho.

[tikhonj]

The Nix language uses whitespace in lists and I'm not the biggest fan—it works well when list elements are simple expressions (individual identifiers, numbers... etc) but gets awkward and confusing if you want to have more complex expressions. It's worse in Nix because Nix also uses whitespace for function application, so even function calls require extra parentheses, but I'm not a fan of it in any non-Lisp syntax I've used.

[irq-1]

I'd like: drop 'try' and always allow and error to be returned, and ignored or checked at the users discretion. Optionally add "@error" or such, and let the tooling add or remove the annotation.

An FFI like luajit is asking alot, but inspired by it would be nice.

[ozyschmozy]

The one liner test cases drew my attention as well, it's pretty neat. Does any other language provide this sort of thing? I guess it wouldn't be hard to implement decorators for this in python