Re: Partial evaluation in imperative languages.

Charles Fiterman <cef@geodesic.com>
4 Jun 1997 22:51:14 -0400

          From comp.compilers

Related articles
Lots of things are happening with ACM TOPLAS toplas@cs.umd.edu (1997-03-31)
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)
| List of all articles for this month |

From: Charles Fiterman <cef@geodesic.com>
Newsgroups: comp.compilers,comp.lang.functional
Date: 4 Jun 1997 22:51:14 -0400
Organization: Geodesic Systems
References: 97-03-165 97-05-301 97-05-322 97-05-333
Keywords: analysis, optimize

Stefan Monnier <monnier+/news/comp/compilers@tequila.cs.yale.edu> wrote:
>Charles Fiterman <cef@geodesic.com> writes:
>> 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).


The point is not to declare them sacred but to declare them open to
partial evaluation. I've just read the list of op codes and built a table
that table is now open to partial evaluation.


>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.


I think global analysis is another word for partial evaluation. Forcing
this requires those mac run distinctions you didn't like.
--


Post a followup to this message

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