Hacker News Reader

Comment by cfallin | Hacker News Reader

I wonder if anyone is working on a full rework of Haskell's syntax, a la Facebook's Reason for OCaml? I'm a big fan of the semantics but not as much the syntax of Haskell, too, and it would be interesting to see what a more... current-day-mainstream... syntax (Rust-like braces-and-semicolons-expression-based-language style, perhaps) would do for it.

View on HN

This is what I'm doing with plastic [1], though it also has some semantic differences: strict instead of lazy, monads become objects.

[1] https://github.com/DanielWaterworth/plastic

That doesn't compile to Haskell.

I'm surprised that you expected it to.

edit: Having looked at Reason more closely, I now see where the confusion came from. Sorry, I didn't mean to deceive you.

There was Liskell, but unfortunately it seems to be unmaintained :(

This would be absolutely amazing actually.

Wait till you see a rust-style datatype polymorphic over 4 parameters, and use that type over and over again. Haskell syntax may not make much sense coming from algol-inspired syntax, but to express its patterns it makes sense otherwise you end up with scala type lambda madness.

Both purescript and agda have this

I'm curious, what sorts of issues arise with complex types that Haskell-like syntax handles better? (Genuinely curious here -- I've written a little Haskell but am by no means an expert...)

IMHO a Rust-style type `Option<HashMap<String, Vec<u32>>>` is a little noiser than the Haskell-style type `Maybe (Map String [Int])`, but not fatally so. Maybe there are much worse cases though?

The big one is `->`; all the 'template argument'-inspired syntaxes for this are terrible. Once you realize you want operators (and polymorphic operators, at that!) in your types, the `<u32>`syntax falls apart.

I am not a fan of C#'s `Func<a,b>` at all.

https://github.com/lamdu/lamdu

Reply on news.ycombinator.com