Hi!
Thanks for looking into my issue. For your information, I didn't use the
REPL (which should permit even more modifications). The program I tested
was:
(define-library (lib-a)
(export set!-x x)
(import (scheme base))
(begin
(define x 12)
(define (set!-x)
(set! x 13))))
(import
(scheme base)
(scheme write)
(rename (lib-a) (x y)))
(display y)
(newline)
(set!-x)
(display y)
(newline)
It prints 12 twice (under chibi-scheme).
Marc
2014-02-03 Taylan Ulrich Bayırlı/Kammer <[email protected]>:
> Marc Nieper-Wißkirchen <[email protected]> writes:
>
> > What is supposed to happen if in the running program a call into the
> > library performs (set! x 13)? I think it is intended that accessing y
> > in the top-level program still yields 12 (at least this is, what
> > chibi-scheme does, with which I am experimenting), and which would
> > allow a number of optimizations at compile-time. [If I understand
> > correctly, it is only forbidden to mutate an imported binding, not an
> > exported one.]
>
> My answer is not authoritative, but I would say that you can safely
> assume the intention to be the sharing of the location, i.e. the change
> should be visible. I see no other reason to forbid the mutation of
> imported bindings, and indeed many systems forbid also the mutation of
> exported variables to help optimization, and making it arguably simpler
> to reason about programs, R6RS too. The problem with that approach is
> that it yields very "static" systems which cannot *re*load libraries
> (modules) at run-time. (Reloading a library is essentially equivalent
> to using `set!' on all its exported bindings.) Given that R7RS-small
> defines no way to reload libraries, a conforming system could just not
> provide a way to do so, and apply the relevant optimizations after
> determining via static analysis that an exported variable cannot
> possibly be mutated. I believe the only way in which a variable can
> possibly be mutated without directly ("lexically") appearing as the
> left-hand operand to a `set!' call is when the variable appears as an
> operand to a pattern variable in a `syntax-rules' template, because this
> means that it might end up being the left-hand to a `set!' call:
>
> ;; Library A
> (define x 0)
> (define-syntax do-to-x
> (syntax-rules ()
> ((_ action)
> (action x))))
>
> ;; Library B, imports A
> (define y 1)
> (define-syntax set-to-y!
> (syntax-rules ()
> ((_ v)
> (set! v y))))
>
> (do-to-x set-to-y!)
>
> ;; `x' needs not even be exported! Only `do-to-x'.
>
> Or perhaps this counts as library B attempting to mutate x after all,
> since the `set!' call originates from library B, so this situation could
> be made to be an error as well, making the static analysis of mutability
> as simple as looking for explicit `set!' calls in the exporting library,
> and nothing else.
>
>
> That being said, I have no idea why Chibi behaves the way you describe,
> maybe my assumption is not as safe as I thought. Maybe it's a special
> behavior of the REPL, in case you did that experiment in the REPL. I
> currently don't have time to try out for myself.
>
> Taylan
>
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
