On Mon, 2011-07-25 at 20:17 -0400, John Zabroski wrote: > On Mon, Jul 25, 2011 at 4:08 AM, Alan Kay <[email protected]> wrote: > > > So when people started talking in the 60s about "POL"s in research (Problem > > Oriented Languages -- what are called DSLs today) this seemed like a very > > good idea to most people (provided that you could get them to be efficient > > enough). This led partly to Ted Steele's idea of an "UNCOL" (Universal > > Computer Oriented Language) which was a relatively low-level target for > > higher level languages whose back-end could be optimized just once for each > > cpu. Historically, C wound up filling this role about 10 years later for > > people who wanted a universal target with an optimizer attached. > > > > Overall, I would say that the biggest difficulties -- in general -- are > > still the result of not knowing how to design each and every level of > > software well enough. > > > > > Yet, it is well known that source-to-source compilation techniques are not > really good for optimization, as documented in Kennedy and Allen's text on > dependence-based graph optimizing compilers. They summarize their huge > mistakes in source-to-source experiments by noting the semantic information > thrown away from stage-to-stage, such as structural information, could be > kept and re-used to implement optimizations like explicit vectorization. [1]
This reminded me of a Lambda the Ultimate post from a while back, which I believe is this one http://lambda-the-ultimate.org/node/3220 It discusses a 2-phase compilation technique: the first phase is a non-destructive annotation of the high-level code, which finds as many invariants, equalities, etc. as it can in the code and makes a note of them. The second phase tries to make the most optimal transformations it can, using various heuristics, based on the fully annotated tree. By doing two passes, this prevents a lot of information being thrown away by greedy optimisations. My own thoughts WRT to this are to maintain such annotations in a self-hosting system as part of the reflection/introspection information, and doing it for both lower-level translation (compilation) and higher-level/sideways translation (source-to-source translation), where in the latter case the heuristics aren't optimisations but style hints, such that. For example, "myJavascriptFunction.asPython()" would give Python code equivalent to myJavascriptFunction, and the heuristics would make it as "pythonic" as possible. This of course doesn't solve the issue of lost information, but it does tackle it in a limited way. It wouldn't solve migrating a codebase from one language to another (although it may help), but it makes a decent attempt at "write-only" translations (eg. compilation). Thanks, Chris Warburton _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
