Hacker News Reader

Comment by CuriousSkeptic | Hacker News Reader

I’ve toyed with the idea of doing a language like this. With a small difference, records would be the only way to express values and bindings.

There would be no need to think of currying and partial application of functions as it would naturally follow from partially evaluating incomplete record inputs.

Another (nice?) property would be that a value always comes with a name binding. This no need to encode semantics of values purely as positions in lists and tuples.

So a question then to an implementer, is this something you considered? Is feasible?

View on HN

Late reply, but telescopes seem to be based on a similar thought:

(http://www.nuprl.org/documents/Constable/Automath-35years.pd...)

RECENT RESULTS IN TYPE THEORY AND THEIR RELATIONSHIP TO AUTOMATH, ROBERT L. CONSTABLE

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.

Actually 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...

Do you have any notes on this? It is something I’m actively researching.

Not 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}"

So the values in the environment are single use? I’m going to think on this...

I've felt for a while that something like this would be superior to the positional way of working, in most cases. But I don't know whether this would result in an elegant system in reality, or not. What if positional were just sugar for records indexed by natural numbers?

There are some precedence in SQL. Which seems to work out ok for the most part. But then in SQL functions are not relations, and do use positional parameters, so not entirely pure either.

Som help from type/name inference might help in wiring things togetger.

It would also make the entire runtime environment (code and data) a homoiconic relational database.

Reply on news.ycombinator.com