> provide classes and methods which assist in building the state machine definition
Now you shift the complexity to a language which is potentially bloated and less suitable to express domain level concepts in a concise way. We've see a lot of OO-architectures which try to recover flexibility by providing complex meta-level mechanisms. For a state-machine one would implement kind of an interpreter over an OO-data model - or a code generator from that oo-model -> greenspunning.
> It was something which could be done better by simply making proper use of the idioms and capabilities of our host platform, and ignoring the syntax entirely
For Lisp this would be natural. One can easily hide an implementation behind a domain-level descriptive representation of the problem. The distance between both is very small. It's actually what I would try to approach: working on a descriptive level with domain concepts and hiding the implementation.
> Creating an entirely new language just to slim things down a bit is rarely appropriate for a single project.
That depends on the 'single project' and its size. Larger applications usually contain a multitude of such tailored notations and machineries to implement them.
> The caveat here of course is that, with Lisp, there's no difference between macros and API
The API consists of exported and documented macros.
> Layering things is an important part of how we think and sticking to common concepts in a given layer are a useful tradeoff.
Sure. If you look at the Common Lisp Object System, it was originally an extension to Common Lisp to implement an object system with classes, functions, methods, inheritance, etc.
The original implementation was in several layers:
The lowest level was a layer of objects. CLOS implemented in terms of itself. Like the definition of a class for classes. It's a bit unusual, since it is an implementation in itself.
The next layer was a layer of extensible functions and classes. Like creating classes by calling functions.
The developer layer is a level of macros where, for example, classes are specified via macros. The macros assemble the necessary language constructs - like how to descriptively define classes in a convenient notation.
The layers are documented and the lower layers are collections of protocols over classes and functions.
This layered language approach in Lisp is described in the book 'The Art of the Meta-Object Protocol', short AMOP.
Now you shift the complexity to a language which is potentially bloated and less suitable to express domain level concepts in a concise way. We've see a lot of OO-architectures which try to recover flexibility by providing complex meta-level mechanisms. For a state-machine one would implement kind of an interpreter over an OO-data model - or a code generator from that oo-model -> greenspunning.
> It was something which could be done better by simply making proper use of the idioms and capabilities of our host platform, and ignoring the syntax entirely
For Lisp this would be natural. One can easily hide an implementation behind a domain-level descriptive representation of the problem. The distance between both is very small. It's actually what I would try to approach: working on a descriptive level with domain concepts and hiding the implementation.
> Creating an entirely new language just to slim things down a bit is rarely appropriate for a single project.
That depends on the 'single project' and its size. Larger applications usually contain a multitude of such tailored notations and machineries to implement them.
> The caveat here of course is that, with Lisp, there's no difference between macros and API
The API consists of exported and documented macros.
> Layering things is an important part of how we think and sticking to common concepts in a given layer are a useful tradeoff.
Sure. If you look at the Common Lisp Object System, it was originally an extension to Common Lisp to implement an object system with classes, functions, methods, inheritance, etc.
The original implementation was in several layers:
The lowest level was a layer of objects. CLOS implemented in terms of itself. Like the definition of a class for classes. It's a bit unusual, since it is an implementation in itself.
The next layer was a layer of extensible functions and classes. Like creating classes by calling functions.
The developer layer is a level of macros where, for example, classes are specified via macros. The macros assemble the necessary language constructs - like how to descriptively define classes in a convenient notation.
The layers are documented and the lower layers are collections of protocols over classes and functions.
This layered language approach in Lisp is described in the book 'The Art of the Meta-Object Protocol', short AMOP.
https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...