4 ms·
I have considered using pattern bindings to easily create "field pun" bindings. For example, one can already introduce all the fields of a record as local bind
by willtim 8y ago
I have considered using pattern bindings to easily create "field pun" bindings.
For example, one can already introduce all the fields of a record as local bindings, e.g.
let {..} = import "List.x"
or just a subset using, e.g.
let {reverse} = import "List.x"
Similarly for function argument bindings, e.g.
f {x, y} = x - y
The above is just syntactic sugar for:
f r = r.x - r.y
Such named arguments of course prevent arguments with the same type being passed in the wrong order, e.g.
f {x=2, y=1}
There is still some minor work to be done to better support inline type annotations on such patterns to make them more usable.
Your idea of unifying bindings with records is interesting and not something I have considered.
- CuriousSkeptic 8y agoActually I even thought of unifying records and lambdas. Which could end up with a concatenative language, where application is commutative. Couldn’t find a syntax that made sense though...
- garmaine 8y agoDo you have any notes on this? It is something I’m actively researching.
- CuriousSkeptic 8y agoNot much. But basically a bit inspired by Cat (a stack based, typed, concatenative language), and a thought that stacks could be replaced by first class environments and rewriting, so you could have a concatenative language with partial evaluation. Instead of the usual ordered parameter lists, and/or curried functions with partial application, functions take environments and produce environments. A program like "{a=1}{b=2}{c=a+b}" would evaluate to "{c=3}". While "{b=2}{c=a+b}" evaluates to "{c=a+2}"
- garmaine 8y agoSo the values in the environment are single use? I’m going to think on this...