Re: The compilation approach in modern languages

torbenm@diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
18 Feb 2005 22:48:33 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: The compilation approach in modern languages gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-02-13)
Re: The compilation approach in modern languages nmm1@cus.cam.ac.uk (2005-02-16)
Re: The compilation approach in modern languages boldyrev@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2005-02-16)
Re: The compilation approach in modern languages boldyrev+nospam@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2005-02-16)
Re: The compilation approach in modern languages rbates@southwind.net (Rodney M. Bates) (2005-02-16)
Re: The compilation approach in modern languages gneuner2@comcast.net (George Neuner) (2005-02-16)
Re: The compilation approach in modern languages torbenm@diku.dk (2005-02-18)
Re: The compilation approach in modern languages dot@dotat.at (Tony Finch) (2005-02-18)
Re: The compilation approach in modern languages hannah@schlund.de (2005-02-18)
Re: The compilation approach in modern languages boldyrev@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2005-02-18)
Re: The compilation approach in modern languages jle@ural.owlnet.rice.edu (2005-02-20)
Re: The compilation approach in modern languages gneuner2@comcast.net (George Neuner) (2005-02-28)
Re: The compilation approach in modern languages anton@mips.complang.tuwien.ac.at (2005-02-28)
[4 later articles]
| List of all articles for this month |

From: torbenm@diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
Date: 18 Feb 2005 22:48:33 -0500
Organization: Department of Computer Science, University of Copenhagen
References: 05-02-053 05-02-056 05-02-065 05-02-076
Keywords: interpreter, code

"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



Post a followup to this message

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