Re: Partial evaluation in imperative languages.

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

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