It's simple and also has an excellent choice of where to invest in powerful features. It looks like an elegant, minimal selection of things existing languages already do well, while cutting out a lot of cruft.
The site also mentions two differentiating and less established features that make it sound like more than yet another fp remix: type-based ownership and algebraic effects.
While ownership stuff is well explored by Rust and a less explicit variation by Mojo, this sounds like a meaningful innovation and deserves a good write-up! Ownership is an execution-centric idea, where fp usually tries to stay evaluation-centric (Turing v Church). It's hard to make these ideas work will together, and real progress is exciting.
I'm less familiar with algebraic effects, but it seems like a somewhat newer (in the broader consciousness) idea with a lot of variation. How does Loon approach it?
These seem like the killer features, and I'd love to see more details.
(The one technical choice I just can't agree with is multi-arity definitions. They make writing code easier and reading it harder, which is rarely or never the better choice. Teams discourage function overloading all the time for this reason.)
Thanks for sharing!
You're right, ownership and effects are the real differentiators. The idea here is to let the compiler discover ownership rather than it being declared imperatively
Regarding algebraic effects, Loon uses continuations similar to Koka but more restrictive. Effects are declared with operations, and every side effect (IO, failure, async, state) is an effect that propagates through the call graph. The interesting part is `handle`, which lets you intercept effects:
[handle [load-config "app.toml"]
[IO.read-file path] [resume "mock contents"]
[Fail.fail msg] "default"]
Multi-arity: get lost! fork me?
How much of this is actually real?
[0] https://github.com/ecto/loon
2. The macros examples on the website don't show binding situations. Are the macro hygienic like in Scheme?
3. Why the choice of [] over ()?
1. effects are tracked in the type system as row types, so they compose with HM inference pretty naturally. the tricky part is effect polymorphism. Loon handles that similarly to how koka does it, with row polymorphism. no ambiguity issues so far but idk
2. yes, macros are hygienic! documenting some binding situations would make a great first PR :)
3. easier to type!
x : Nat x = 5
You just say x = 5
I personally don't like that you don't seem to be able to manually describe the type for a fn/var, because it's very useful when prototyping to write stubs where you provide the typedef but then the actual variable/function is just marked as "todo"
That being said I took a look at the roadmap and the next major release is the one that focuses on Effects, so perhaps I'm jumping the gun a tad. Maybe I'll whip this out for AoC this year!
Oh dear, why? Abrasive aesthetics aside, this is bad for people with certain non-English keyboard layouts. Not me, but many do exist.
They do require worse acrobatics than a shift key on a German keyboard, though - one of the Alt keys is special and needed to trigger them, if memory serves.
Well, that's another argument for everyone to use an English layout for coding, I suppose.
Why the square brackets in particular? Notation is such an annoying part of this stuff, I’m actually leaning towards pushing a lot of structure to the filesystem
Definitely cool in concept, but very performance-intensive and slow.
[fn square [x] [* x x]]
fn square(x) = x * x;
Also
> Hindley-Milner inference eliminates type annotations.
I think it's pretty widely agreed at this point that global type inference is a bad idea. The downsides outweigh the upsides. Specifically: much worse errors & much less readable code.
I do. The advantage being that if you suddenly realize that you want to do super-duper-multiplication instead of regular multiplication, you can just change the name instead of having to rewrite the entire expression. And honestly, having a few random functions be called differently from others feels gross.
Lisp and similar are just "hey it's really easy to write a parser if we just make all programmers write the AST directly!". Cool if the goal of your language is a really simple parser. Not so cool if you want to make it pleasant to read for humans.
That's my impression, at least. Like I said, I've never actually used a Lisp. Maybe I'm put off by the smug superiority of so many Lisp people who presume that using Lisp makes them better at programming, smarter, and probably morally superior to me.
This looks like a really neat project/idea; seeing the road map is exciting too, nearly everything I'd want.
I don't love the brackets syntax, or the [op val1 val2] ([* x x]) style, but I appreciate the attempt at clarity and consistency and none of these things are dealbreakers.
I do wonder why they've leaned so hard into talking about the type system being out of sight. Again, not a dealbreaker, but I feel strongly that explicit typing has a place in codebases beyond "describe something because you have to".
Strongly typed languages strike me as providing detailed hints throughout the codebase about what "shape" I need my data in or what shape of data I'm dealing with (without needing to lean on an LSP). I find it makes things very readable, almost self-documenting when done right.
From their docs about their choices: "The reasoning is simple: types exist to help the compiler catch your mistakes. They do not exist to help you express intent, at least not primarily." This strikes me as unnecessarily pedantic; as someone reading more code than I write (even my own), seeing a type distinctly—particular as part of a function signature—helps me understand (or add strong context) to the original author's goal before I even get to reading the implementation.
I find this doubly so when working through monadic types where I may get a typed error, a value, and have it all wrapped in an async promise of some kind (or perhaps an effect or two).
By the same token many languages allow you to leave out type annotations where they may be simple or clearly implied (and/or inferred by the compiler), so again, I'm not understanding the PoV (or need) for these claims. Perhaps Loon simply does it better? Am I missing something? Can I write return types to stub functions?
From the above blog post: "That's how good type inference feels! You write code. The types are just there. Because the language can see where it's going." Again, it feels strongly geared towards a world where we value writing code over reading/maintaining/understanding code, but maybe that's just my own bias/limitations.
Will follow it closely.
> You never annotate a function signature unless you want to for documentation purposes.
so it sounds like function annotation is still an option for the purposes of communication, just no longer required in all cases.
[1] https://loonlang.com/concepts/from-rust
I agree that seeing types is helpful, though typing them is also not necessary. Perhaps the solution is an IDE that shows you all the types inferred by the compiler or maybe a linter that adds comments with types on file save.
see "The Editor as Type Viewer" section in the docs: https://loonlang.com/concepts/invisible-types
Types exist so that the compiler can reason about your code better - but not incidentally, they also help you reason about your code better!
To wit: even when working in dynamic languages, it's often considered a good practice to write down in docstrings the types of objects a function can operate on, even without static enforcement. Thinking about types is helpful for humans, too.
And it's not even just a thing to help you read code in the future - types help me write code, because as I sit down to write a function I know the possible values and states and capabilities of the object I'm working with. In the best of cases I can analytically handle all the possible cases of the object, almost automatically - the code flows out of the structure of the type.
THIS. So much. This observation is extremely intuitive to me.