Dimitris Vyzovitis wrote:
...
One of the problems I have with these systems (including the modules produced by the orignal portable syntax-case) is that they produce mutable bindings for module/library exported identifiers.
Note that R6RS library bindings are immutable.
Ideally, the module system shouldn't expand to core scheme, but rather to gambit's core forms.
Sounds like the start of a master's thesis to me! ;^)
-KenD
Afficher les réponses par date
On Tue, 18 Mar 2008, Ken Dickey wrote:
Dimitris Vyzovitis wrote:
...
One of the problems I have with these systems (including the modules produced by the orignal portable syntax-case) is that they produce mutable bindings for module/library exported identifiers.
Note that R6RS library bindings are immutable.
Are they? I wasn't refering to apparent immutability (as in client code can't set! them), but to real immutability in the generated code. For instance, in ghuloum's libraries you get something like this: http://bazaar.launchpad.net/~aghuloum/r6rs-libraries/r6rs-libraries.dev/anno...
notice that it is littered with (define foo #f) ... (set! foo <real-foo>)
-- vyzo
On Mar 18, 2008, at 12:25 PM, Ken Dickey wrote:
Dimitris Vyzovitis wrote:
...
One of the problems I have with these systems (including the modules produced by the orignal portable syntax-case) is that they produce mutable bindings for module/library exported identifiers.
Note that R6RS library bindings are immutable.
Yes, but as your next comment might imply, either the module implementation needs to change or Gambit's compiler implementation needs to change so that the compiler can exploit that information.
I ran into a similar problem recently when hacking on the Meroon object system (which uses define-macro): Macros needed to be written so that (a) expressions passed as arguments are evaluated in the environment where the macro appears, e.g.,
(declare (safe) (not block) (not standard-bindings)(not extended- bindings)),
while (b) the code inserted by the macro is compiled in the environment in place when the Meroon macro is defined, e.g.,
(declare (not safe)(block)(standard-bindings)(extended-bindings) (fixnum)).
So can these module systems extend the idea of "hygiene" to include Gambit's compilation environment? (Aziz and Andre, are you listening?)
Ideally, the module system shouldn't expand to core scheme, but rather to gambit's core forms.
Sounds like the start of a master's thesis to me! ;^)
Brad
On Mar 18, 2008, at 1:50 PM, Bradley Lucier wrote:
I ran into a similar problem recently when hacking on the Meroon object system (which uses define-macro): Macros needed to be written so that (a) expressions passed as arguments are evaluated in the environment where the macro appears, e.g.,
(declare (safe) (not block) (not standard-bindings)(not extended- bindings)),
while (b) the code inserted by the macro is compiled in the environment in place when the Meroon macro is defined, e.g.,
(declare (not safe)(block)(standard-bindings)(extended-bindings) (fixnum)).
So can these module systems extend the idea of "hygiene" to include Gambit's compilation environment? (Aziz and Andre, are you listening?)
I suppose that, given R6RS semantics, about the only compilation "environment" options that need to be considered are code generation options:
([not] safe) ([not] inline) ([not] inline-primitives primitive…) (inlining-limit n) ([not] lambda-lift) ([not] constant-fold) ([not] run-time-bindings var…) (mostly-number-type primitive…)
I suppose that
(standard-bindings) (extended-bindings) (block)
are implied by R6RS semantics, no?
Brad
-
Bradley Lucier -
Dimitris Vyzovitis -
Ken Dickey