Previously: Part 1, Part 2, Part 3, Part 4.
Didn't get to do anything today, so this is just gonna be an open question. One of the other goals I'm curious to try for this language is to have every value be serializable. I'm not sure how this'll work for functions, and especially continuations. Most of the other tricky ones can be expressed in terms of functions. Functions may be able to be expressible as their definition together with their environment, so maybe that'll work. Continuations seem much trickier. Still gotta think on that.
Previously: Part 1, Part 2, Part 3.
I added a primitive parser with support for strings and added symbols for true, false, null, undefined.
Toy implementation at https://github.com/athingperday/schwelle-lang.
Turns out that we need one more "aspect" to a type. Not just eval, which tells you how to evaluate a value of the given type, but in order for expressions to work, we need some kind of application aspect. Which I'll call "call". I'll also call an expression a "pair" more in line with other lisps.
I've decided to code-name the language Schwelle (the German word for "threshold"), and I've created a toy implementation at https://github.com/athingperday/schwelle-lang.
In Designing a Programming Language for Funsies (Part 1), I talked about going extreme. Well, my goal is to make the core of the language so small and stupid-easy to implement, and there can be a whole standard library or whatever that's written in the language itself so that it's as portable as possible. I'm gonna walk you through my thought process.
We start with the basic premise of the language. At any given step in the computation, you have a "frame". A frame contains the following information:
The premise of this language is to have first-class frame-manipulation. This comes in the form of what I call xframes (or transframes for long -- since it transforms a frame -- a portmanteau -- it's clever -- get it?).
Let's talk about types. It'd be cool if types could be defined independently of the evaluation apparatus above. All that's really needed is for a type to be able to specify how it should be evaluated. Almost like each type is a "plugin" to the language itself. Most types (like numbers or strings) just store data and don't actually need to be evaluated. The ones that matter are going to be types like an expression, or a symbol. I'm yet undecided on whether the unevaluatable things should all evaluate to an "error" type if they ever end up trying to be directly evaluated, or whether they should evaluate to themselves.
We'll also want types themselves to be first-class, but we'll worry about that later.
Regardless, where we end up following that line of thought, is that types carry the data of how they should be evaluated. So, roughly speaking, the language in which we're implementating our language will represent a type as an object with an "eval" function. The evaluation apparatus then will call the evaluand's type's eval function on the current frame, and output a new frame, which will then be the next frame to be evaluated. And that's the whole of the evaluation apparatus!
Next time, I'll give some sample code.
I've had in my head for a while an idea for a programming language inspired by John Shutt's Kernel. But, I go even further than merely first-class macros and environments. I give you: first-class (well, there really isn't a word for this, so I guess for now I'll call them) transframes (or xframes for short). Basically, first-class operators that can modify the evaluation-stack.
I've done some work on this in the past, making an interpreter and such, but I'll be rebuilding it, so I can document my thought process as I go. It's gonna be inefficient as heck, but I'm curious to see where is leads.