Re: [Scheme-reports] Identifiers imported "by reference or value"?

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 <taylanbayirli@x>:

Marc Nieper-Wißkirchen <marc.nieper@x> 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