Re: [MIT-Scheme-devel] bug in shadowing caches

[Chris Hanson]

I understand the bug and how to fix it.  I'll take care of it.

On Fri, Aug 20, 2010 at 1:29 PM, Joe Marshall <address@hidden> wrote:
> Hmmm.  Looks like a bug.
>
>
> On Fri, Aug 20, 2010 at 10:00 AM, Taylor R Campbell <address@hidden> wrote:
>>   Date: Fri, 20 Aug 2010 09:10:31 -0700
>>   From: Joe Marshall <address@hidden>
>>
>>   I think the behavior you are seeing is the expected one.
>>
>> If that is the case, then the compiler and the interpreter disagree on
>> the semantics of the language:
>>
>>   ;;; /tmp/lose.scm
>>
>>   (define (reference-barrier x)
>>     (identity-procedure x))
>>
>>   ;;; repl
>>
>>   (let ((environment (extend-top-level-environment (->environment '()))))
>>     (load "/tmp/lose.bin" environment)
>>     ((eval 'reference-barrier environment) 0))
>>   ;Loading "/tmp/lose.bin"... done
>>   ;Value: 0
>>
>>   (let ((environment (extend-top-level-environment (->environment '()))))
>>     (load "/tmp/lose.com" environment)
>>     ((eval 'reference-barrier environment) 0))
>>   ;Loading "/tmp/lose.com"... done
>>   ;Quit!
>>
>> I claim that the interpreter's semantics is the correct semantics.
>> Suppose, for example, that we first separate lose.scm into two forms,
>> a definition form and an assignment form:
>>
>>   ;;; lose0.scm
>>
>>   (define reference-barrier)
>>   (set! reference-barrier (lambda (x) (identity-procedure x)))
>>
>> The compiler and interpreter disagree on the semantics as before.
>> Now suppose we split lose.scm into two files:
>>
>>   ;;; a.scm
>>
>>   (define reference-barrier)
>>
>>   ;;; b.scm
>>
>>   (set! reference-barrier (lambda (x) (identity-procedure x)))
>>
>> In this case, the compiler and interpreter agree -- both behaving like
>> the interpreter on the single lose0 file:
>>
>>   (let ((environment (extend-top-level-environment (->environment '()))))
>>     (load "/tmp/a.bin" environment)
>>     (load "/tmp/b.bin" environment)
>>     ((eval 'reference-barrier environment) 0))
>>   ;Loading "/tmp/a.bin"... done
>>   ;Loading "/tmp/b.bin"... done
>>   ;Value: 0
>>
>>   (let ((environment (extend-top-level-environment (->environment '()))))
>>     (load "/tmp/a.com" environment)
>>     (load "/tmp/b.com" environment)
>>     ((eval 'reference-barrier environment) 0))
>>   ;Loading "/tmp/a.com"... done
>>   ;Loading "/tmp/b.com"... done
>>   ;Value: 0
>>
>> The problem is that there are two distinct bindings, i.e. associations
>> between name and variable, but only a single variable between them,
>> and update_cache_references updates all references to the variable,
>> irrespective of what binding they went through (i.e. what name was
>> used to refer to the variable).  However, after the update, the name
>> IDENTITY-PROCEDURE still refers to the variable created in global.scm
>> -- not to the variable created in the child environment, to which
>> REFERENCE-BARRIER has been bound.  So future references to IDENTITY-
>> PROCEDURE will not be updated like prior references have been.
>>
>
>
>
> --
> ~jrm
>
> _______________________________________________
> MIT-Scheme-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
>