bug#11988: eval-case redefinition?

bug#11988: eval-case redefinition?

[Daniel Llorens]

This looks like a bug (v2.0.6).

I was cleaning up an old script which goes like this:

(define (eval-case ...)
  ...
  val)

(define var (eval-case ...))

This worked from the REPL, but when loading the file with (load "script"), var was always #<unspecified>. It turns out that (my) eval-case is never executed in this case.

So I look around to find that eval-case is something that has been replaced by eval-when and is now deprecated.

But no matter what eval-case is, it is bad that the redefinition is being ignored silently.

Regards,

	Daniel

bug#11988: eval-case redefinition?

[Ludovic Courtès]

Hi,

Sorry for the delay.

Daniel Llorens <daniel.llorens@bluewin.ch> skribis:

> I was cleaning up an old script which goes like this:
>
> (define (eval-case ...)  ...  val)
>
> (define var (eval-case ...))
>
> This worked from the REPL, but when loading the file with (load
> "script"), var was always #<unspecified>. It turns out that (my)
> eval-case is never executed in this case.

It turns out that ‘eval-case’ is a macro, and it gets macro-expanded in
the RHS of ‘define var’ above.

This is the same situation as:

--8<---------------cut here---------------start------------->8---
(define-syntax-rule (foo x) (- x))
(define (foo x) x)

(pk 'foo (foo 42))  ; prints -42
--8<---------------cut here---------------end--------------->8---

“Expansion process” in R6RS seems to suggest that this is a bug:

  For the right-hand side of the definition of a variable, ex-
  pansion is deferred until after all of the definitions have
  been seen. Consequently, each keyword and variable refer-
  ence within the right-hand side resolves to the local bind-
  ing, if any.

Hmmm...  Thoughts?

Ludo’.

bug#11988: eval-case redefinition?

[Andy Wingo]

On Thu 19 Jul 2012 15:22, Daniel Llorens <daniel.llorens@bluewin.ch> writes:

> I was cleaning up an old script which goes like this:
>
> (define (eval-case ...)
>   ...
>   val)
>
> (define var (eval-case ...))
>
> This worked from the REPL, but when loading the file with (load
> "script"), var was always #<unspecified>. It turns out that (my)
> eval-case is never executed in this case.

I wonder if this is related to bug 13865.

I tried a script with these contents:

  (define (eval-case val)
    val)

  (define var (eval-case 2))

And I can reproduce the bug with stable-2.0.  `master' seems to have the
right behavior however.  If I had to guess I would think that this was
fixed by the following commit on `master':

    commit 19ef14f9b8b73c04acbbfa6bd993908171bc69f7
    Author: Andy Wingo <wingo@pobox.com>
    Date:   Fri Nov 4 19:37:04 2011 +0100

    defined identifiers scoped in the current module
    
    * ice-9/psyntax.scm (chi-top-sequence): Wrap defined identifiers with
      the current module.  Fixes http://savannah.gnu.org/bugs/?31472.

Or one of the commits around it that has to do with toplevel bindings.
Tough to tell, as that code is significantly different in master as
compared to stable-2.0.

Andy
-- 
http://wingolog.org/

bug#11988: eval-case redefinition?

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Daniel Llorens <daniel.llorens@bluewin.ch> skribis:
>
>> I was cleaning up an old script which goes like this:
>>
>> (define (eval-case ...)  ...  val)
>>
>> (define var (eval-case ...))
>>
>> This worked from the REPL, but when loading the file with (load
>> "script"), var was always #<unspecified>. It turns out that (my)
>> eval-case is never executed in this case.
>
> It turns out that ‘eval-case’ is a macro, and it gets macro-expanded in
> the RHS of ‘define var’ above.

This bug is now fixed on the stable-2.0 branch.

  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=8de355d08e25a877326489c4b0eb09d313c548dc

I'm closing the bug now.  Feel free to reopen if you think there's still
a problem.

    Thanks!
      Mark