Related articles |
---|
Lots of things are happening with ACM TOPLAS toplas@cs.umd.edu (1997-03-31) |
Partial evaluation vs flow-graph analysis fabre@gr.osf.org (Christian Fabre) (1997-05-22) |
Re: Partial evaluation vs flow-graph analysis mossin@diku.dk (1997-05-25) |
Re: Partial evaluation vs flow-graph analysis thorn@spamblock.lalla.irisa.fr (Tommy Thorn) (1997-05-27) |
Partial evaluation in imperative languages. cef@geodesic.com (Charles Fiterman) (1997-05-30) |
Re: Partial evaluation in imperative languages. monnier+/news/comp/compilers@tequila.cs.yale.edu (Stefan Monnier) (1997-05-31) |
Re: Partial evaluation in imperative languages. cliffc@risc.sps.mot.com (Cliff Click) (1997-06-02) |
Re: Partial evaluation in imperative languages. cef@geodesic.com (Charles Fiterman) (1997-06-04) |
Re: Partial evaluation in imperative languages. volanski@irisa.fr (1997-06-10) |
From: | Stefan Monnier <monnier+/news/comp/compilers@tequila.cs.yale.edu> |
Newsgroups: | comp.compilers,comp.lang.functional |
Date: | 31 May 1997 23:52:39 -0400 |
Organization: | Compilers Central |
References: | 97-03-165 97-05-254 97-05-275 97-05-301 97-05-322 |
Keywords: | analysis, optimize |
Charles Fiterman <cef@geodesic.com> writes:
> I think for partial evaluation to be useful in an imperative language
> there must be language constructs to support it.
Seems sensible to me also. And not only for imperative languages.
> frozen variable-list;
> The following variables are frozen, they have reached their final state.
I'd rather see something like a "freeze" operation that can be applied to a
variable. Still, checking its validity can be tricky (seems about as hard as
infering "freeze" operations automatically). Moreover, if the check cannot be
done (or isn't done), trusting the programmer might introduce unsafety (just
like any other kind of cast, it seems).
> pure
Yes. Also useful for semantically pure functions that nonetheless use
destructive assignments (splay-tree access comes to mind).
> mac
[...]
> run
These seem kind of hackish to me. What you really want is not "do this
when I compile the stuff", but "please compute that in advance". The
point is that the "in advance" can be at compile-time, at link-time,
at run-time (with run-time code-generation for instance), ...
> I regard strong typing as partial evaluation of the type system in
> such a way that no errors may occur at run time. But there are many
> times we don't want errors at run time. I don't ever want to hear
> "Is there a programmer aboard the aircraft? I'm getting the message
> 'zero divide error'"
I agree that languages should provide a way for the programmer to
differentiate between exceptions that can happen and exceptions that
should not happen no matter what (i.e. errors; such as array-bounds
violation). This latter can be used a lot more agressively by the
compiler since it doesn't have any precise semantic (apart from :
"please crash soon enough"). The "best" way to handle this is by
propagating the possible handlers everywhere and checking whether some
exception might be handled (in this last case, it should be treated as
a real error). One more global analysis.
Stefan
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.