On Thu, 10 Sep 2009 23:12:51 -0500, John Cowan <[email protected]> wrote:
>> How is a procedure call different from a variable reference?
>
> Because of the general observation that top-level variables bound to
> literal procedures are far more likely to be immutable (except for
> redefinition) than other top-level variables. Also because inlining
> procedures is a huge win compared to inlining non-immediate data.
Not necessarily. If you consider a simple OO-style system where a global
value holds a table of operators, inlining that table into procedures
which reference it could be just as much of a win.
I do want implementors and library authors to have the flexibility of
allowing the compiler to inline procedure calls where appropriate.
However, I can't see a good, first-principles argument as to why this
would also not apply to non-calls of procedures or references to
non-procedure-valued variables. Thinking that procedure calls are
"special" goes in the Common Lisp box in my head, and I don't seem to have
a space for it in the Scheme box in my head. Am I thinking about this
wrong?
>> I don't see any problems with your mental model, but I'm having
>> trouble at the point of conclusion. If the module `foo' is already
>> defined, and I either type at the REPL or load a file containing a re-
>> definition of the module, am I altering the existing bindings in that
>> module, or am I creating new syntactic bindings?
>
> Altering. I was careful to use the word "alters" in my description to
> make that clear, but apparently it didn't. But that does not mean the
> alterations are propagated to the importing modules.
OK. Let's assume for the sake of argument that I've got my idiot hat on,
and so I don't understand what "altering" means here. (This is a good
assumption: it is not far from the truth.) I've concocted an example using
a hypothetical R6RS toplevel where libraries can be defined and redefined
interactively. Can you fill in the blanks here?
==> #!r6rs
(library (locative)
(export get-value set-value!)
(import (rnrs base (6)))
(define value #f)
(define value-set #f)
(define get-value
(lambda ()
(if value-set
value
(error #f "value not yet set"))))
(define set-value!
(lambda (v)
(set! value v)
(set! value-set #t)
v)))
==> #!r6rs
(library (foo)
(export a)
(import (rnrs base (6)))
(define a 1))
==> #!r6rs
(library (bar)
(export)
(import (rnrs base (6))
(locative)
(foo))
(set-value! (lambda () a)))
==> #!r6rs
(import (rnrs base (6))
(locative)
(foo)
(bar))
==> ((get-value))
1
==> #!r6rs
(library (foo)
(export a)
(import (rnrs base (6)))
(define a 2))
==> #!r6rs
(import (rnrs base (6))
(locative)
(foo))
==> ((get-value))
??? ; BLANK 1: 1 or 2?
==> #!r6rs
(import (rnrs base (6))
(locative)
(foo)
(bar))
==> ((get-value))
??? ; BLANK 2: 1 or 2?
==> #!r6rs
(library (bar)
(export)
(import (rnrs base (6))
(foo))
(define z ((get-value)))
==> #!r6rs
(import (rnrs base (6))
(locative)
(foo)
(bar))
==> z
??? ; BLANK 3: 1 or 2?
It seems to me that the plausible answers are (1, 1, 1) or (2, 2, 2),
corresponding to library redefinition creating fresh syntactic bindings or
mutating existing bindings respectively. Does your proposed semantics
differ from either of these in a way that can be distinguished by this
test, and if so, how?
(I'm also assuming here that the R6RS rule of "one visit at phase 0"
applies. If you're proposing a change to this rule, the results would
instead be (error, error, error) - but I think that this would be a Bad
Idea.)
> No, just an indication that I'm not binding myself to R6RS specifics
> here. I'd still like Thing One modules to be a subset of Thing Two
> libraries, but only if some adjustments are made between R6RS and Thing
> Two.
I'll save most of what I have to say about this for a later email, but in
principle and practice I don't think it's a good idea to have two
different module systems, even if one is a super- or sub-set of the other.
I also believe that the Thing Two library system should build upon the
R6RS; any adjustments will have to be compatible with the spirit of the
R6RS, such that an implementation may sensibly provide interoperability
between Thing Two libraries and R6RS libraries. (This leaves open the
possibility of Thing Two adding additional points of unspecification
compared to the R6RS; implementations wishing to provide this
interoperability would have to choose R6RS semantics in those cases.)
--
Brian Mastenbrook
[email protected]
http://brian.mastenbrook.net/
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
