Re: [Sbcl-devel] exporting merge-tail-calls from sb-ext, what about semantics

[F. <fa...@gm...>]

I really like the proposal, but together with it "we" need to document
what tail calls we merge and what we don't.

For instance, I doubt we properly merge special variable frames:
   (defun foo (*x*) .... (foo (1- *x*)) ...)
Note that MzScheme does properly merge them, though they call special
variables "parameters" and implement them as "properties" on a
continuation.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
He who refuses to do arithmetic is doomed to talk nonsense.
        -- John McCarthy, in his webpage on Progress and Sustainability

On 13/03/2008, Nikodemus Siivola <nik...@ra...> wrote:
> I think SB-C::MERGE-TAIL-CALLS would make a good candidate for
>  exporting from SB-EXT even as it is, but...
>
>  I was wondering if we should define it like this:
>
>   0: never
>   1: default
>   2: maybe (high debug policy may inhibit tail calls)
>   3: always (overrides any debug policy)
>
>  An optimization policy 3 having a semantically significant effect has
>  prior art in SAFETY, and as Scheme people have shown tail calls are
>  not just an implementation detail.
>
>  In practical terms this would mean that MERGE-TAIL-CALLS 3 would
>  prohibit various debug optimizations.
>
>  Any thoughts re exporting MERGE-TAIL-CALLS or the possible semantic tweak?
>
>  Cheers,
>
>   -- Nikodemus