4 ms·

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

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

KerrAvon 3y ago
Using the C for loop syntax is looney tunes, though. Do range support and leave that 70's stuff in the dust.
- donpdonp 3y ago
  its got 'for k in list {}' (https://nature-lang.org/docs/the-basics/control-flow#iteration-loop https://nature-lang.org/docs/the-basics/control-flow#iterati...) though array.for_each(lambda) is a better way to go, imho.
irq-1 3y ago
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.
munificent 3y ago
> 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]?
- dmoy 3y ago
  Or ["5", "-", "2"] even
- jrajav 3y ago
  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 3y ago
    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;
tikhonj 3y ago
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.
archargelod 3y ago
> 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, ] ```
ozyschmozy 3y ago
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

KerrAvon 3y ago

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

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

irq-1 3y ago

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.

munificent 3y ago

> 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]?

dmoy 3y ago
Or ["5", "-", "2"] even
jrajav 3y ago
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 3y ago
  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;

tikhonj 3y ago

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.

archargelod 3y ago

> 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, ] ```

ozyschmozy 3y ago

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