OMeta is a project from VPRI (Alan Kay), by Alessandro Warth (he introduced recursion support for PEG parsers). If you read through the lens of VPRI (along with other projects such as Cola by Ian Piumarta), it is a radical perspective on language design – where you give a way for users to customize the language syntax, effectively abstracting the syntax out of the language.
Looking at it this evening I was reminded of one of my frustrations with OMeta: each variant emits action code in the substrate language it was written in. This means that calling OMeta a ‘language’ is extremely confusing. It doesn’t hermetically seal itself off from the underlying substrate like you expect a language to do. Its compiler is really more like a macroexpansion phase.
There’s nothing wrong with this. But it bears highlighting up front. The different implementations aren’t exact ports: a program for one won’t work with another.
Ok, there is one thing wrong with this. Using the facilities of the underlying language at runtime in this manner opens up the question of just how much of OMeta’s power is coming from the HLL below it. I notice nobody’s built an OMeta in C. Perhaps doing so will help answer this question.
OMeta is more a way to write reconfigurable parsers than a language – there are many PEG parsing libraries in C, including one by Ian Piumarta http://piumarta.com/software/peg/. OMeta is a type of PEG with a language/format for describing extensible grammars. The semantics of the language defined by the grammar are orthogonal/out of scope for OMeta. But because OMeta is meant to be dynamic (as opposed to compiled, like lex/yacc) you’ll need an implementation of OMeta for the language you’ll use to implement your language semantics (or at least the AST building phase).
Yeah, it’s an improvement. One thing that made me link to META II is that its rules and interpreter are simple enough for bootstrapper use. It was designed for 1960’s hardware with original paper describing it in detail taking 11 pages. ;) My idea was that it would be extended into something a bit cleaner to start with its interpreter + I/O or embedded in a Scheme/imperative language like nineties’ as a macro language. You could port Ohm’s benefits to something like that if the implementation was simple enough. Looks like a lot of JavaScript in its Github, though. Alternatively, implement simple stuff like Mu, a LISP, and/or META II to implement Ohm in that to work from Ohm forward.
OMeta is a project from VPRI (Alan Kay), by Alessandro Warth (he introduced recursion support for PEG parsers). If you read through the lens of VPRI (along with other projects such as Cola by Ian Piumarta), it is a radical perspective on language design – where you give a way for users to customize the language syntax, effectively abstracting the syntax out of the language.
Oldest of the meta languages is META II which has turorial here:
http://www.bayfronttechnologies.com/metaii.html
Wikipedia describes a lot of variants of Ometa:
https://en.m.wikipedia.org/wiki/OMeta
Looking at it this evening I was reminded of one of my frustrations with OMeta: each variant emits action code in the substrate language it was written in. This means that calling OMeta a ‘language’ is extremely confusing. It doesn’t hermetically seal itself off from the underlying substrate like you expect a language to do. Its compiler is really more like a macroexpansion phase.
There’s nothing wrong with this. But it bears highlighting up front. The different implementations aren’t exact ports: a program for one won’t work with another.
Ok, there is one thing wrong with this. Using the facilities of the underlying language at runtime in this manner opens up the question of just how much of OMeta’s power is coming from the HLL below it. I notice nobody’s built an OMeta in C. Perhaps doing so will help answer this question.
OMeta is more a way to write reconfigurable parsers than a language – there are many PEG parsing libraries in C, including one by Ian Piumarta http://piumarta.com/software/peg/. OMeta is a type of PEG with a language/format for describing extensible grammars. The semantics of the language defined by the grammar are orthogonal/out of scope for OMeta. But because OMeta is meant to be dynamic (as opposed to compiled, like lex/yacc) you’ll need an implementation of OMeta for the language you’ll use to implement your language semantics (or at least the AST building phase).
Looks like the successor to OMeta II is Ohm, where the semantics are at least cordoned off from the parser. That makes things much nicer.
Yeah, it’s an improvement. One thing that made me link to META II is that its rules and interpreter are simple enough for bootstrapper use. It was designed for 1960’s hardware with original paper describing it in detail taking 11 pages. ;) My idea was that it would be extended into something a bit cleaner to start with its interpreter + I/O or embedded in a Scheme/imperative language like nineties’ as a macro language. You could port Ohm’s benefits to something like that if the implementation was simple enough. Looks like a lot of JavaScript in its Github, though. Alternatively, implement simple stuff like Mu, a LISP, and/or META II to implement Ohm in that to work from Ohm forward.