@Nick Smith See this example - In the implementation of

sum

,

fold

wants a “binary operator” function that takes two parameters - an “accumulator” and an “item”. In Haskell, which is based on positional arguments, I’d simply pass the operator “+”. But in Lamdu I can’t because the parameters of “+” are not called “accumulator” and “item”. So instead I use a lambda which uses “+”. However it gets sugared as a “lightweight lambda”, with underlines under the lambda symbol and under its parameters where used. This isn’t too heavyweight and it also gives us helpful places to display the intermediate values of everything (when display of evaluation results is enabled)

Oh cool. Does the sugar happen automatically? Does the programmer still type the full lambda before it gets simplified? Seems like an interesting feature. I'd imagine that for larger functions the lack of an explicit parameter list might harm readability, but at that point the sugar is probably unnecessary anyway.

The sugar happens automatically when the code matches a certain pattern (all parameters are in use is one condition). The conditions are such that it doesn’t tend to happen for larger functions

Why do you represent records this way? Seems like it introduces an ordering amongst fields.

@Nick Smith Perhaps “merge” is the way to go, and I’m interested in compelling examples for it. However with “merge” you still have the same ordering freedom where you can either construct a full record or merge many small ones where you have freedom in their ordering.

Unless "merge" is an operator from a set of sets to a set 😛

Yeah it appears like a nice idea. Iirc there is some language that has it. But it’s probably more complicated to make type-inference work for it

The issue would seem to be that order and names don't matter to us as readers when it comes to addition. Addition is an abstraction layer high enough already.