It's a shame though that we don't represent them as such in the current state of affairs but choose to implement them separately in every language. Can we have a fast, universal, feature complete parser generator that is natively supported in our mainstream languages?
For instance, think adding an ANTLR grammar into a .NET project and then be able to just do `var ipAddress = ip"127.0.0.1";` and get full editor support with that.
Pretty sure that if you want anything more than syntax highlighting, you'll need way more than just grammar.
At the end of the day, I guess it might just boil down to surrounding tooling.
> The Programming Languages Zoo is a collection of miniature programming languages which demonstrates various concepts and techniques used in programming language design and implementation. It is a good starting point for those who would like to implement their own programming language, or just learn how it is done.
What the blog author is describing, on the other hand, is a small language for teaching the use and application of certain programming techniques.
It's a very promising idea, one that I may try to bring to life for something tricky, like monads or maybe Rust's ownership system.
They already exist: the Racket student languages. My first year CS course was built on them [1]. Really well-made and -run course.
One thing both of these have in common is that they are slightly different from mainstream ideas (e.g. C, Python, JSON, XML). Not so different it becomes alien, but different enough to make you approach it with a different state of mind.
* datafun - attempt to extend datalog to more generic computation. http://www.rntz.net/datafun/ I liked simillar exploration of computing with latices with the concept of propagators: http://web.mit.edu/~axch/www/art.pdf
* dhall - configuration language that has user defined functions, but is total :) https://github.com/dhall-lang/dhall-lang
* the gamma - a visualization/data query language : http://tomasp.net/blog/2017/thegamma-getting-started/
I do wonder why the author believes you need a separate language for this. Why not a DSL, or even a regular library in your popular language of choice (Scala, Haskell, JS, etc.).
Is that a reasonable approach too? Or is some part of the toy language approach lost without perfect domain-specific syntax, or because of parts of your host language leaking in?
I think the reasoning behind implementing these small languages on their own would be twofold: one, unless you're very careful, you end up with lots of context and approach and style inherited from your host language. You can write non-rubyish Ruby, but only to a degree...and anyone using it who's moderately familiar with the language is likely to break your artificial constraints. And for many of the programming concepts perhaps best demonstrated in isolation, they're divergent enough to be hard to implement well in a 'traditional' host language.
Libraries sometimes cannot do what new languages can, or can only mimic it in a very very cumbersome way, I think this is why the author advocates for separate languages, rather than libraries.
The other thing that a separate language allows is for the author to remove every distraction that a host lanauge might have, and really streamline and emphasise the concepts they’re trying to show, and those concepts only.
But instead it's almost the opposite. Bentley's original use of the little language term was about optimizing the languages for specific tasks. Not about building them around explaining a single concept
I really like the diagram they use to split up the languages + paradigms[1]
[0]https://en.wikipedia.org/wiki/Concepts,_Techniques,_and_Mode...
[1]https://www.info.ucl.ac.be/~pvr/paradigmsDIAGRAMeng108.jpg
> XL features programmer-reconfigurable syntax and semantics. Compiler plug-ins can be used to add new features to the language. A base set of plug-ins implements a relatively standard imperative language. Programmers can write their own plug-ins to implement application-specific notations, which can then be used as readily as built-in language features.
> XL is defined at four different levels: XL0 defines how an input text is transformed into a parse tree. XL1 defines a base language with features comparable to C++. XL2 defines the standard library, which includes common data types and operators. XLR defines a dynamic runtime for XL based on XL0.
> XL has no primitive types nor keywords. All useful operators and data types, like integers or addition, are defined in the standard library (XL2). XL1 is portable between different execution environments. There is no such guarantee for XL2: if a particular CPU does not implement floating-point multiplication, the corresponding operator definition may be missing from the standard library, and using a floating-point multiply may result in a compile-time error.
Frankly, I'm not sure if this is much different from implementing a language with a parser generator, but apparently the ‘semantics plugins’ are written in a version of the language itself, instead of something like the eternal C[++].
(Really, many of the books in that series do this. The Reasoned Schemer for logic programming, The Little Prover for ACL2-style first-order logic.)
http://vesta.informatik.rwth-aachen.de/ftp/pub/mirror/ctan/b...
