clike

For everyone here who mentioned building wrappers around llvm-c or llvm c++ api: there is a nice tool for automating this job (and many other similar things), it's called "Clang". Or, more specifically, cindex. It's easy to use Python + cindex to parse LLVM headers and spit out nice wrapper library for your language of choice. And example of this approach: https://github.com/combinatorylogic/clike/blob/master/llvm-w...

I tried "amplifying" C with Lisp-like syntax macros. Looks like there is a lot of potential on this route: https://github.com/combinatorylogic/clike

The repo looks to be here: https://github.com/combinatorylogic/clike Because you have a functional and also imperative language (pfront?) that your compiler is written in, you avoid memory churn by ensuring "visitor nodes are chained together", is that right? So pass fusion for compiling clike does away with the destructive matching and rebuilding of untransformed subexpressions by linking pointers back to the original.

There must have been some papers on it, but I lost a track. Will try to dig out something. Meanwhile, you can take a look a my implementation of such a mix: https://github.com/combinatorylogic/mbase/tree/master/src/l/... An example of a grammar built on top of it: https://github.com/combinatorylogic/clike/blob/master/clike/... - see the `binary` nodes there, they're translated into Pratt while all the others are Packrat.

Take a look at some of the languages with quasiquotation-based metaprogramming: Template Haskell, Converge, Nemerle. I did quite a bit of exploration in this area too, here is one of the examples: https://github.com/combinatorylogic/clike

Again... A compiler or an interpreter written in C is not the same as implementing a language on top of C, fusing it into all the existing infrastructure. You did not understand what static metaprogramming is, what is an extensible language, and yet you're talking about my poor understanding. And, by the way, I fixed an inferior C. Any inferior language can be made superior by adding a tiny bit of compile-time Turing-completeness and a bit of compile-time reflection: https://github.com/combinatorylogic/clike Made it equally powerful to Scheme, Forth, Nemerle, TH, C++ and the other proper meta-languages.

> Compare that with Lisp approach, in which code is data. It's not any different. It does not matter if your `(,a ,b) is compiled into (list a b), or your ` \a\ = \b\` is compiled into make_binary('=',a,b) - both are constructors, essentially. Take a look at what I'm doing with just a quasiquotation here: https://github.com/combinatorylogic/clike

Nice implementation, I like how the toplevel lifting is done. I was exploring similar things from a slightly different angle (using PEG natural extensibility): https://github.com/combinatorylogic/clike

I still don't understand what's the problem here. User must be aware of the order of a choice and insert his language extension accordingly. Paying some attention to what you're doing never hurts anyway, and it's hardly a blocking issue barring PEG adoption. I normally do this sort of things by providing a number of extension points in the grammar, in the beginning, middle and the end of a semantic entity, instead of simply concatenating grammars (e.g., see such extension points here: https://github.com/combinatorylogic/clike/blob/master/clike/... )

Ruby eDSLs are not that interesting - they still force you to stick to the Ruby syntax, which can be counterproductive. The best way of implementing eDSLs is to extend the syntax of your core language, which is very easy for the languages based on PEG. See https://github.com/combinatorylogic/mbase and https://github.com/combinatorylogic/clike for example of this approach.