Re: slowness in guile 1.8

[Ludovic Courtès]

Hi Andy!

Andy Wingo <address@hidden> writes:

> On Fri, 2007-05-25 at 20:12 +0200, Ludovic Courtès wrote:
>> Alas, it breaks the following test in `syntax.test':
>
> I'm not sure what "it" is in this case; I assume you mean the fix to
> module-make-local-var!.

"It" means "the reordering of `eval_car' and `sym2var' in `eval.c'".

>>   (pass-if "binding is created before expression is evaluated"
>>     (= (eval '(begin
>>                 (define foo
>>                   (begin
>>                     (set! foo 1)
>>                     (+ foo 1)))
>>                 foo)
>>              (interaction-environment))
>>        2))
>> 
>> This test case illustrates the fact that _internal_ defines are
>> equivalent to `letrec' (Section 5.2.2); top-level defines should behave
>> similarly for new variables (Section 5.2.1).
>
> I don't know what you are trying to say here; top-level defines do not
> "behave similarly" to letrec. R5RS says in section 5.2.1:
>
>         If <variable> is not bound, however, then the definition will
>         bind <variable> to a new location before performing the
>         assignment, whereas it would be an error to perform a `set!' on
>         an unbound variable.  
>
> The new variable should be created before the assignment, but _not
> necessarily before evaluation of the rhs_.

Oh, right, there's a subtle difference here, so your interpretation may
well be valid, indeed.

> I think the test is bogus.

Actually, no: the test does a `define' _within_ the body of `begin', so
I *think* this qualifies as an internal define, and internal defines are
equivalent to `letrec' (Section 5.2.2).  So the test is equivalent to:

  (letrec ((foo (begin
                  (set! foo 1)
                  (+ foo 1))))
    foo)

And this is valid (and does actually work in all the previously
mentioned implementations except SCM).

IOW, `scm_m_define ()' must be refined to distinguish between internal
defines and top-level defines.

Needs some more thought now...

Thanks!

Ludovic.