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 <[email protected]> wrote: > Hmmm. Looks like a bug. > > > On Fri, Aug 20, 2010 at 10:00 AM, Taylor R Campbell <[email protected]> > wrote: >> Date: Fri, 20 Aug 2010 09:10:31 -0700 >> From: Joe Marshall <[email protected]> >> >> 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/mit-scheme-devel >
_______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
