"KScript is a dynamic language based on the declarative and time-aware dataflow-style execution model of Functional Reactive Programming (FRP), extended with support for loose coupling among program elements and a high degree of program reconfigurability
... the KSWorld environment supports exploratory
application building: a user constructs the appearance interactively with direct manipulation, then attaches and refines
reactive variable definitions to achieve the desired overall behavior."
"The software for today’s personal computing environments
has become so complex that no single person can understand
an entire system: a typical desktop OS and commonly used
application suite amount to over 100 million lines of code.
Our group’s early experiences with personal computing led
us to understand that much of this complexity is “accidental”, rather than inherent ... About 10,000 lines of code were needed to build the framework, the FRP evaluator, the document model and the editor, including the implementation of the special language created for KSWorld."
See also peg.js: http://pegjs.majda.cz/. The theory of parsing and compiling has some really nice concrete applications all over the place. In general, if you want to properly model a specific domain computationally you will almost surely travel through parsers and compilers. Here's a nice talk on the topic: http://www.infoq.com/presentations/tools-language-workbench.
"As I was writing this tutorial I found myself speculating about what happened to metacompiler technology"
I suspect that one part of the answer is that for most non-trivial examples, the parsing part is the easy part and metacompilers don't help with the hard part (type checking/inference, optimization, code generation, etc).
That said, I see terrible broken ad-hoc parsers all over the place that probably could benefit from this.
In Doug Engelbart's 1969 MOAD, he mentioned that the DSLs used in the demo were built with TREE-META, the last gov-funded, unclassified metacompiler, http://en.wikipedia.org/wiki/TREE-META
More background at http://onfoodandcoding.blogspot.com/2013/02/meta-ii-early-me...
Alessandro Warth's OMeta is a modern version of ideas in Meta II, http://tinlizzie.org/ometa/
OMeta is used in KScript and KSworld, from Alan Kay's Viewpoints research, http://www.vpri.org/pdf/tr2013002_KSonward.pdf
"KScript is a dynamic language based on the declarative and time-aware dataflow-style execution model of Functional Reactive Programming (FRP), extended with support for loose coupling among program elements and a high degree of program reconfigurability
... the KSWorld environment supports exploratory application building: a user constructs the appearance interactively with direct manipulation, then attaches and refines reactive variable definitions to achieve the desired overall behavior."
Edit: more on KSworld, http://www.vpri.org/pdf/m2013003_ksapps.pdf
"The software for today’s personal computing environments has become so complex that no single person can understand an entire system: a typical desktop OS and commonly used application suite amount to over 100 million lines of code.
Our group’s early experiences with personal computing led us to understand that much of this complexity is “accidental”, rather than inherent ... About 10,000 lines of code were needed to build the framework, the FRP evaluator, the document model and the editor, including the implementation of the special language created for KSWorld."
See also peg.js: http://pegjs.majda.cz/. The theory of parsing and compiling has some really nice concrete applications all over the place. In general, if you want to properly model a specific domain computationally you will almost surely travel through parsers and compilers. Here's a nice talk on the topic: http://www.infoq.com/presentations/tools-language-workbench.
I've had a lot of fun playing with Parsing Expression Grammars, some of which I've documented at http://pollrobots.blogspot.com/2013/01/parsing-expression-gr...
"As I was writing this tutorial I found myself speculating about what happened to metacompiler technology"
I suspect that one part of the answer is that for most non-trivial examples, the parsing part is the easy part and metacompilers don't help with the hard part (type checking/inference, optimization, code generation, etc).
That said, I see terrible broken ad-hoc parsers all over the place that probably could benefit from this.
In Doug Engelbart's 1969 MOAD, he mentioned that the DSLs used in the demo were built with TREE-META, the last gov-funded, unclassified metacompiler, http://en.wikipedia.org/wiki/TREE-META
Historical email: http://www.ifcx.org/wiki/TREEMETA.html
1974 manual: http://www.chilton-computing.org.uk/acl/literature/manuals/t...
That was a nice interruption to work which was nearly starting over at https://pym.readthedocs.org/ But I really have to write some code.
Saved for later: https://github.com/jalanb/pym/commit/4d5df8fd328d1c71de1a519...