Whenever unambiguous we print to a simpler form, e.g. `switch ((foo, bar))` -> `switch (foo, bar)`. Both accepted at parsing time
Conversation
Oh dear…
Well I guess it remains to be seen whether the folks start hating it after the initial honeymoon period. How easy is it to explain `(f(x) >> f())` to people? (using Elm/F# composition operators /w tupled args here)
1
1
There's some annoyance after "honeymoon" period, but it's mostly about additional parens being hard to track with eyes - no complaints related to semantics.
1
We'll reduce the number of parens we print to mitigate that issue and then reevaluate how many problems the tuples being (like, this) still cause.
1
I do need to keep my pre-existing biases in check here too, and it's good you're having a go at challenging the status quo.
1
How hard would it be to create an alternate, Elm-style syntax for Reason? As somebody who writes a great deal of Rust, I kind of feel type signatures on top make much more sense for a type-driven programming style, as does dropping parens. Makes the code much cleaner and lighter.
3
1
1
The Elm-style syntax for Reason is just called OCaml.
1
1
5
OCaml has its types inline with the definition. Not really the same 🙄
1
I started to use
let foo : 'a -> string -> 'a list = fun x bar -> ...
which, while not as nice as Haskell, is kinda ok IMHO.
1
1
Or you can wrap with modules which have `val` type definitions, but it's verbose and not really practical.
1
Yeah, just kind of feel like the general movement is towards encouraging type-driven program design, rather than optimizing the value-level and trying to hide all types via inference. Baby steps I guess!
I was thinking of proposing a change to allow `var` in module structs that desugars to the equivalent `let` statement.
1