The venerable master Zardoz was walking with a student, Zed. Hoping to prompt the master into a discussion, Zed said "Master, I have heard that objects are a very good thing - is this true?" Zardoz looked pityingly at the student and replied, "Foolish pupil - objects are merely a pitiable substitute for closures."

Chastised, Zed took leave from the master and retreated into a quiet cell in the basement of Gates Hall, intent on studying closures. Zed carefully read the 3110 course notes, and implemented an OOP language using OCaml and closures. Zed learned much, and looked forward to informing the master of this progress.

On the next walk with Zardoz, Zed attempted to impress the master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a pitiable substitute for closures." Zardoz responded by hitting Zed with a stick, saying "When will you learn? Closures are merely a pitiable substitute for objects."

At that moment, Zed became enlightened.

It's always a good time to reread cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

Related (and funny): Execution in the kingdom of nouns : steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

I like that Cook paper, but am surprised that he doesn't mention the angle from which one can see an object as a set of functions that have been partially evaluated against an underlying record.

I agree on the three elements suggested as fundamental PL building blocks: from memory (the site seems to be broken), creating new data from old, structuring stuff, and pattern-matching - the latter being split into creating types and filling slots in a template

While the site is struggling, I managed to capture the text:

Basic building blocks of a programming language

I've tried to understand category theory, but while I can't say I've got the mathematical skills to understand it, I think I kind of grasp what it intends to do. It is basically a way of building bigger things out of smaller things as flexibly as possible.

Designing my language I get inspired by this thought, and started to think along those lines. This means trying to realize what are the basic building blocks from which to build larger blocks, i.e. from where do I start?

In an attempt to figure this out, I thought about what languages typically tries to do. What I found so far are:

1. Calculate data, i.e. from data produce some other data, i.e. functions

2. Organize data into hierarchy (lists, structs, maps, let's call these types just to have some name)

3. Find patterns in data

The idea here is to make these elements as versatile as possible, so they can be combined without restriction as long as it is reasonable. Allow functions to generate other functions, hierarchies and/or patterns. Allow hierarchies to contain functions, other hierarchies and/or patterns. Allow patterns to describe functions, hierarchies and/or other patterns.

First of all, do you agree that these three could be used as basic building blocks, or is there something missing or wrong?

Secondly, the pattern. I can see patterns used in two that seems like distinctly different ways. One is that you write a template like code, which you could see as a patter

n. You insert a few values and out comes a type, a function, or something. Another way of using it would be to say this is an expected pattern with some variables in it, th

en apply data to it, and if it matches the pattern you get the value of the variables the pattern contained.

Perhaps those two cases of patterns should be named differently? Any thoughts on this?