Here's something interesting from LtU: "Basic bui...
# linking-together
d
Here's something interesting from LtU: "Basic building blocks of a programming language" http://lambda-the-ultimate.org/node/5652 I'd comment but I've lost my account deets and can't create a new one cos the site seems broken right now. So I'll comment here instead...
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?
n
IMO the author is way, way off. There is nothing profound or essential about the features listed, apart from the obvious fact that every programming language needs data and a way to process it.
d
IMO the author is spot on! 😄 which is the kind of diversity we like to see here, eh? If you start with these things, you can create a nice pure programming language that only has the essential bits in it: no extraneous crap that comes from machine constraints, or from legacy thinking and computer science history.
Obviously I'm saying this because this exactly describes my own language and how I got to it: distilling programming down to its fundamental elements. For me, it ended up being: • start with structure, syntax: types are patterns • match patterns/types • transform into new structures, which can be seen as patterns or types Then go around again.
It would seem that you, @Nick Smith perhaps represent the beliefs or philosophy of this community, since you were the only one replying and were so vociferously opposed! Does anyone else have anything to say on this subject?
n
I moreso think the author’s thoughts are very vague and that perhaps they haven't spent much time (months or years) exploring the different kinds of languages out there and really thinking deeply about what the fundamental building blocks might be. Which is fine – the author is entitled to discuss these things in public irrespective of the time they have spent on it. But ultimately, without spending time, the conceptualization they are able to come up with is unlikely to be insightful. That's all I meant to say – I don't find the author’s conceptualization insightful.
d
OK that's fair 😃👍
Re reading my post, I'm cringing at how hostile it could sound, so apologies for that and thanks for not taking it wrong! 🫣🤗 .. I didn't intend it to be!
❤️ 1
j
I didn’t comment because I don’t get it. Sounds like this is a description of term rewriting? I just don’t have any thoughts because it seems pretty vague to me.
👍🏼 1
👍 1
d
Yes, term rewriting is related to the points he makes and to my own PL.
a
I'm kinda with Nick. The categorization there almost seems to vague to even be wrong. Neither of them are well-defined, but in my mind there's a lot of overlap between "patterns" and "functions". Any "data" structure can be seen as a "function", e.g. key -> value. Anyway, where are the "data" and "patterns" in lambda calculus? These might be good ideas if they were fleshed out more, but they're demonstrably not universal or necessary.
j
It reads like "from first principles" thinking done by someone without enough background to make a good map of the territory.
🤷 1
d
Maybe you need to be a bit naive to be able to think clearly, before you get mentally trained by exposure to the prevailing anti-state "territory"?
a
I don't think state has anything to do with it. I'd call myself tentatively pro-state, and that doesn't affect my judgment of this model. @Duncan Cragg I suspect you have a somewhat more precise mental model that you've projected onto this description, that fills in the gaps a lot of us are complaining about.
d
Yes that's probably a fair observation!