Tue Sep 23 21:07:09 CEST 2003
--- Joe Armstrong <joe@REDACTED> wrote:
> > Adding a pass to expand ifs to normal cases should
> be simple (there used
> > to be a template parse transform file somewhere -
> under stdlib I think -
> > but I can't find it in the current distribution).
> One part of me says
> implement funs
> by lambda-lifting and transforming into regular
> first-order code
> (and yes I know you have to "cheat" with the odd
> funny atom name :-)
> The other part says make "proper" closures
> (internally) - both
> approaches have advantages and disadvantages.
I seem to recall that older versions of the
preprocessor transformed fun:s into tuples, which
seems to be what you want.
In my own current system, which is not a full
compiler, the working representation is basically
preprocessed code (-E) with a bit of postprocessing to
get rid of some remaining nasty cases:
- records have become tuples
- funs are kept as (Code, [FreeVar])
- funs are added to exports (after mild massaging to
make them exportable)
- repeated variables are converted to explicit guard
- modules are renamed (with indirect calls dynamically
renaming the module to invoke
List comprehensions should be removed at this point
too, but currently are not. Doing so is fairly
straightforward, so it's really just laziness.
Unlike Core Erlang, it's still Erlang. But it's also
easier to work with than full Erlang. (It should be
said some of the above are motivated by the
optimizations I do, rather than generic.)
> IMHO the difficult bit in an implementation is the
> layering - what goes into which layer....
Heh, yes. The basic approach, in my experience, has to
be to first decide what you want to do with each
intermediate language. On each level, some
optimizations become natural while others become vile.
Conversion between the languages gradually reduce to
the chosen target format.
Some zen is required to get this right.
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
More information about the erlang-questions