On Sat, Apr 13, 2013 at 8:29 PM, David Barbour <[email protected]> wrote: > > > On this forum, 'Nile' is sometimes proffered as an example of the power of > equational reasoning, but is a domain specific model. >
Isn't one of the points of idst/COLA/Frank/whatever-it-is-called-today to simplify the development of domain-specific models to such an extent that their casual application becomes conceivable, and indeed even practical, as opposed to designing a new one-size-fits-all language every decade or so? I had another idea the other day that could profit from a domain-specific model: a model for compiler passes. I stumbled upon the nanopass approach [1] to compiler construction some time ago and found that I like it. Then it occurred to me that if one could express the passes in some sort of a domain-specific language, the total compilation pipeline could be assembled from the individual passes in a much more efficient way that would be the case if the passes were written in something like C++. In order to do that, however, no matter what the intermediate values in the pipeline would be (trees? annotated graphs?), the individual passes would have to be analyzable in some way. For example, two passes may or may not interfere with each other, and therefore may or may not be commutative, associative, and/or fusable (in the same respect that, say, Haskell maps over lists are fusable). I can't imagine that C++ code would be analyzable in this way, unless one were to use some severely restricted subset of C++ code. It would be ugly anyway. Composing the passes by fusing the traversals and transformations would decrease the number of memory accesses, speed up the compilation process, and encourage the compiler writer to write more fine-grained passes, in the same sense that deep inlining in modern language implementations encourages the programmer to write small and reusable routines, even higher-order ones, without severe performance penalties. Lowering the barrier to implementing such a problem-specific language seems to make such an approach viable, perhaps even desirable, given how convoluted most "production compilers" seem to be. (If I've just written something that amounts to complete gibberish, please shoot me. I just felt like writing down an idea that occurred to me recently and bouncing it off somebody.) - Gath [1] Kent Dybvig, A nanopass framework for compiler education (2005), http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.72.5578
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
