The reason for the syntax is that HVM aims to be a low level compile target, which sounds confusing because closures make it look very high level, but it should be seen as LLVM IR. It isn't meant for direct human use on the long term. Ideally it will be the compile target of languages like Haskell, Lean, Idris, Agda, Kind (my language) and others. As such, I just went for a syntax that simplifies and speeds up parsing, while still keeping it usable if you need to manually edit: there is no backtracking on this syntax.
There aren't. Kind is more stable, is more JS-looking and less Haskell-looking, which makes it more practical IMO, has a super fast JS compiler and you can write React-like apps on it easily, but some work is needed to improve the type-checker performance when certain syntax sugars are used. The core's performance is superb, though.
Idris2, I can't comment much. All I know is that I envy its unification algorithm and synthesis features. Its syntax is more haskellish, if you like that. It seems less mature in some aspects, though. Very promising language overall.
My guess is the author just picked the simplest syntax to parse in order to demonstrate the tech. If it works and shows to be successful you can always write a GHC (or whatever) backend that compiles to this runtime. Maybe come up with some binary IL etc
> I’m not sure what the reasoning was here. I hope the author or others can shed some light.
From my point of view, the author almost made it into s-expressions, but decided not to go all the way, which (imo) would have been amazing and the "cleanest" (although I don't like using the term "clean" for code, it's so subjective). I'd like to have some light shed over the decision not to go all the way.
On a quick scan, it seems to be some more things than just `let`. One example would be `(Main n) = (Sum (Gen n))` should be closer to `(define Main (n) (Sum (Gen n)))` or similar. Not sure the change would be as easy as you think, but happy to be proven otherwise ;)
A `let` could assume un-even amount of forms in it and only evaluate the last one, using the other ones as bindings.
Example from your README:
(Main n) =
let size = (\* n 1000000)
let list = (Range size Nil)
(Fold list λaλb(+ a b) 0)
(define Main (n)
(let size (\* n 1000000)
list (Range size Nil)
(Fold list λaλb(+ a b) 0)))
Could even get rid of the parenthesis for arguments (`(n)` => `n`) and treating forms inside `define` the same as `let`.
> On a quick scan, it seems to be some more things than just `let`. One example would be `(Main n) = (Sum (Gen n))` should be closer to `(define Main (n) (Sum (Gen n)))` or similar.
Good point.
> Could even get rid of the parenthesis for arguments (`(n)` => `n`) and treating forms inside `define` the same as `let`.
No, because non-curried functions are a feature. If we did that, every function would be curried. Which is nice, but non-curried functions are faster (lots of lambdas and wasteful copies are avoided using the equational rewrite notation), so they should be definitely accessible.
Just wanted to clarify that I definitely don't think this looks like a bad language as-is, I don't want to give the impression because of this small preference, it's less valuable (but I'm sure you knew that already). It's really impressive design, congratulations on getting it out for the world to play with :)
Curious, this suggests (lambda a b form) to go along with (let a 42 form). I've seen let without the extra parens but not define or lambda. Thanks for the aside.
Yeah, can't remember if I've seen that in the wild either before. Just as a disclaimer, the idea is off-the-cuff and I'm not 100% it would work in practice or be beneficial beyond containing less parenthesizes. You wouldn't be able to have multiple forms that gets evaluated for example, without having to wrap it in something like `do`, is the first argument against it. But maybe multiple forms in the body is less common than one in the first place.
Many questions arise, for a small amount of benefit (imo), so not sure it's worth it.
We do have "elegant," which to me means "intellectually ergonomic." Something can be "beautiful" while being totally intimidating and impossible for a human to work with, it can be "easy" despite wasteful complexity because it you can confidently work through the cruft, but "elegant" implies both beauty and ease, fitting naturally to our human mental capabilities without unnecessary detail.