Designing a Programming Language: I
ducklang.org
ducklang.org
For this article in particular, I disagreed with the first two parts:
1. Premise: Simplifying assumption: There are two kinds of languages, static and dynamic. Somehow, it's just good to know this, and nothing is said of which of these the Duck language fall into.
2. Syntax: Wait, no.
There is an implicit premise here, being that if you make a language, it's probably going to be a general-purpose one with expectable control-flow structures, and because of that, what we care about is how those control-flow structures look, i.e. should there be curly braces around blocks and such.
A premise I would prefer is: When you make a language, you want to solve a problem. Imagine a language being an overgrown library. You don't start a tutorial in making libraries about how a good library interface looks like. You start by saying what problem you want to solve.
Another premise I would prefer is: Most problems are domain-specific, so most language-shaped solutions to problems are DSLs.
index, value := with
i := 0
count := len(haystack)
loop
while i < count else not_found
elem := haystack[i]
if is_special(elem) then continue
if match(elem, needle) then break found(elem)
// could also have been
// while not match(elem, needle) else found(elem)
// until match(elem, needle) then found(elem)
always
i = i + 1
on not_found
-1, _
on found(result)
i, result // "i" is in scope here, but not "elem"
...
I mean, if you are making a new language, that's your chance to not stick with the old and tried stuff but try something more adventurous, like this loop device from Knuth's old paper.
The syntax debate is usually something like, "what does this buy us and do we have the budget for it" and imo that loop syntax is not sufficiently general (it cannot express recursion, for example) nor does it make code easier to read (you now have what's essentially a few if/else blocks split across four different code blocks, I would reject this if I saw it in a code review to make the loop simpler), and it doesn't really prevent a user from making mistakes.
Extremely generic control flow constructs have also been shunned a bit. There's a lot of "call/cc considered harmful" content on the internet from a few years back, and I predict we'll see the same thing about new-fangled control flow constructs like algebraic effects.
while cond1
stmts1
elif cond2
stmts2
elif cond3
stmts3
while a > b
a := a - b
elif b > a
b := b - a
And yes, you can express all of that with either "while true: ..." with early breaks/returns or with "while <OR'ing lots of Boolean flags>: ..." with post-processing those flags to determines why the loop has ended... but why not have explicitly named, limited continuations? IMO it would simplify dealing with "there maybe many reasons why the loop ended" kinds of iterations. Putting every loop into its own (anonymous) function that returns an ad-hoc sum type doesn't sound like a much better solution to me, to be fair.
Basically, syntax might be your last thought, but that doesn't mean you should neglect it.
Imagine you're going to write a book, and before you think of the subject, you're rabbit-holing whether or not to use the Oxford comma. This is literally the significance of syntax. Of course, it matters. But not as much as what your book is about.
[edit] There was a recent example of a constant-time C-like programming language: https://news.ycombinator.com/item?id=33308037
Oh, but there are SO many!
These two super-categories I am very fond of:
- Query languages
- Infrastructure specification languages
Here are some concrete examples:
GraphQL: An API query language: https://graphql.org/
jq: A JSON command-line processor: https://stedolan.github.io/jq/
HCL: A DSL for expressing Terraform assets: https://developer.hashicorp.com/terraform/cdktf/concepts/hcl...
Troll: A DSL for expressing dice roll simulations: http://hjemmesider.diku.dk/~torbenm/Troll/
fvg: Functional Vector Graphics: https://github.com/lemmih/fvg
Kleenex: Optimal regex-based stream processor: https://kleenexlang.org/
Futhark: High-performance purely functional data-parallel array programming: https://futhark-lang.org/
> And when should they be libraries instead?
A friend recently told me that DSLs (stand-alone) and eDSLs (embedded in an existing language) have the main difference that DSLs are overgrown configuration files, and eDSLs are overgrown libraries.
I'd say: When you want to call your DSL from more than one programming environment, it is good to have an abstract representation that transcends one particular syntax-tree definition. A library is good until then.
The only design here might be the verbatim copy of a compiler architecture which is explained over and over. And some people might call architecture "design" and "programming language" a syntax compiler.
</rant>
However, I often wonder why it’s left out. I think charitably, I can assume that authors want to present the mechanical implementations and development of a language and it’s developer experience. To do do so, they just use typical (and often simplified) strictly imperative or strictly functional semantics hoping the audience has an implicit understanding of what the PL constructs ‘mean’. Or, I can assume with a lot less charity, that programming language semantics (particularly novel or niche semantics) are hard to understand and explain and the authors are not competent to talk about it so they just don’t bother or consider it.
Where do you find yourself falling in explaining the lack of semantics in these types of tutorials on PL design?
Some common resources which I already identified are the talk simple made easy[1] or the famous everything is an X[2] which was here in HN a few days ago. Also a common problem I see, is that many scholars and intellectual people confuse what the meaning of "semantic" is. For example they might mistake "semantic" with "meaning" and do not understand as semantic problem collapsing two different variables in a single variable (e.g. the classic "0 means unlimited" like some old C programs did).
If you do find a resource, just let me know, but I hope there is more on the topic beyond using a regular math model, just for the sake of uniformity, and try to make everything "as easy as possible" based on a gut feeling.
[1] https://m.youtube.com/watch?v=SxdOUGdseq4&t=1250s [2] https://lukeplant.me.uk/blog/posts/everything-is-an-x-patter...
Question: does anyone know of resources that discuss the rest of programming language design?
- designing a standard library
- building tooling like debuggers and package managers
- interfacing with other languages
- managing and growing a community
- evolving the language over time as it grows
- integrating with IDEs and building language server support
- how to communicate the language to others so they understand the value proposition.
- how to choose the right set of features to support. How to discern a good set from a bad set, how to make the language stand out and unique.
- also maybe issues of how to stay motivated and focused. It takes years to build a language, how does one stay committed to it over that time?
I understand why there might not be many resources that cover these angles, as not many language projects get past the parser stage, but I’m still curious what others have found.
https://dl.acm.org/topic/conference-collections/hopl?sortBy=...
Sorted by most downloaded, the first page of results includes the history of Erlang, Haskell, C, C++, Smalltalk, Fortran, AppleScript, Lisp, Pascal, Prolog..
Many of the papers are written by the people who designed, developed, and maintained the programming language, its ecosystem and community.
What I find fascinating are their retrospective thoughts on what didn't work well, regrets of what turned out to be bad design decisions. The authors also often reflect on how far programming in general has evolved, what aspects and features have become expected, like package manager, etc.
In any substantial language, the "lexer" and "parser" represent less than 1% of the work of implementing the language. In the Ecstasy (xtclang) project, writing the lexer and parser (and then bootstrapping them both in the Ecstasy language) took less than 4 person weeks, out of 750+ (and counting) person weeks spent implementing the language.
* The compiler.
* The type system.
* The core library.
Maybe that felt too much like writing a book, she the author opted for brevity. :-P
I don't believe it can respond to a request live, but it can dynamically request a cert for any new domain and have it presumably in seconds, so I don't think it's out of the realm of possibility. This would only be for a subdomain of a parent domain you already own and can prove via an ACME challenge.