Re: The compilation approach in modern languages

"Rodney M. Bates" <rbates@southwind.net> writes:


> Tony Finch wrote:
> > "Rodney M. Bates" <rbates@southwind.net> wrote:
> >
> >>The one exception is the functional languages, where functions can be,
> >>in effect, manipulated at runtime and then evaluated. ---
>
> > That is not true for most modern functional programming languages
> > (i.e. ones not descended from lisp) which are designed to be compiled
> > to native code.
>
> I would expect many implementations to do some runtime partial
> evaluation when a curried function is partially applied. Does
> it never happen?


The closest thing to runtime PE for partial applications that I'm
aware of in non-experimental applications is the full laziness
transformation. This (at comile time) extracts subexpressions that
depend only on the first argument of a curried function, so the
evaluation of these can be shared between different applications of
the closure.


No code is actually built at runtime, though.


> I am sure this is sometimes more than an efficiency issue. Seems
> like it could affect termination, for example.


It can if you eagerly evaluate expressions that may be nonterminating.
But the full laziness transformation is applied to lazy languages, so
the evaluation of an expression is postponed until the first use of
its value.


A less mainstream language is MetaML, which does do runtime code
generation on partial applcations, if these are typed so the first
argument has an earlier binding time than the latter. The generated
code is for a virtual machine, which AFAIK is interpreted. Several
functional languages running on virtual machines also have support for
runtime code generation, but this is done explicitly rather than
implicitly on partial applications. And unlike MetaML, you don't get
type safety on generated code.


                Torben

Return to the comp.compilers page.
Search the comp.compilers archives again.