[r6rs-discuss] [Formal] Disallow redefinitions macros/variables

From: Abdulaziz Ghuloum <aghuloum>
Date: Mon Mar 26 19:50:55 2007

On Mar 26, 2007, at 3:03 PM, AndrevanTonder wrote:

> - I suspect that it may make certain optimizations
> (such as detecting possibilities for inlining or direct
> substitution) more difficult.

Let's divide the internal definitions into three categories:

1. (never) Definitions that the compiler can prove not to return twice.
2. (may) Definitions that the compiler cannot prove not to return
twice.
3. (always) Definitions that the compiler can prove to always return
twice.

The code produced for the first category is the same whether you require
the check or not since the compiler can omit the check without violating
the restriction.

The third category is not very interesting. I don't think it happens in
practice (unless you're stress-testing a compiler).

The second category is where things differ the most. You're
suggesting that
the compiler must ensure that the evaluation of these definitions not to
return twice. What this means is:
1. the compiler has to insert additional runtime checks in order to
stop you
from returning twice (which you almost always never do in practice).
So,
you end up paying for a useless feature.
2. Definitions which the compiler cannot decide if they return once
are not
exactly good candidates for inlining or direct substitution.
"Inlineable"
definitions are usually things that can be folded to constants,
variables
(obeying letrec* restrictions), lambda expressions, and simple things
like
it. Even a call to (list 1) cannot be copy-propagated in general
regardless
of the additional restrictions.

So, I don't see how outlawing multiple returns gains you anything as
far as
optimizations are concerned. I'm shortsighted btw :-)

> It is no longer sufficient
> to detect set! statements to determine mutability.
> Mutability detection becomes undecidable.

This has always been the case for letrec and is also the case for
letrec*.
This is actually how the semantics of letrec and letrec* are defined: by
using assignments and imposing the letrec/letrec* restriction.
Disallowing
the implicit assignment requires one to invent a different way of
specifying
the semantics of letrec/letrec*. Any ideas on how that would be done?

Aziz,,,
Received on Mon Mar 26 2007 - 19:50:18 UTC