On Tue, 18 Mar 2008 13:50:02 -0400, Bradley Lucier lucier@math.purdue.edu wrote:
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.
True. The expander has to communicate that information to the compiler somehow. The way psyntax is structured allows for providing this information on a per compiler basis by customizing the way the output is generated. The language of the output of the expander can be customized in many ways in psyntax.
1. For some forms, there is a simple flag that allows you to select how one piece of core syntax is expanded. Take lambda and case- lambda for example. One implementation can select not to generate any case-lambdas, consequently, case-lambdas will be expanded to a lambda with a dispatch code based on the number of arguments. Another implementation can select not to generate any lambdas, and in that case, all lambdas are converted to a one-clause case-lambda forms in the output. Whether the underlying implementation supports letrec, letrec*, and so on can be customized this way. [look at psyntax.config.ss (1)]
2. References to primitive procedure can be customized so that it looks like "cons", "#%cons", "##sys#cons", or whatever the underlying implementation wants it to look. The out-of-the-box expander just outputs "cons" because it's the lowest common denominator between all the targeted R5RS implementations but it's by no means a limitation of the expander. As a matter of fact, you can get away with not generating an s-expression output at all and by generating whatever the compiler accepts as input directly from the expander by customizing how the "build-*" procedures work. [look at psyntax.builders.ss (2)]
As far as the immutability of the library exports, there is a hook for how the output of the run-time components of the library should be generated (see build-library-letrec* in psyntax.builders.ss). In ikarus, I generate this library-letrec* form that looks like:
(library-letrec* ([local-name exported-name expression] ...) body)
A portable implementation would generate:
(letrec* ([local-name expression] ...) (begin (set! exported-name local-name) ... body))
A gambit-specific generator would add the declarations that you mentioned in your message (e.g., (safe) (standard-bindings) ...) and shape the output to look in a way that the gambit compiler likes.
I hope that no one hacks/forks the core of the expander (i.e., psyntax.expand.ss and psyntax.library-manager.ss) since newer versions of these come out all the time and you don't want to repatch your modified version any time a new version is released. If there is any limitation in the core of the expander (e.g., if these are things that you wish you could customize but neither psyntax.config.ss nor psyntax.builders.ss provides the hooks), then I would be happy to fix it.
Aziz,,,
[1] http://bazaar.launchpad.net/~aghuloum/ikarus/ikarus.dev/annotate/ aghuloum%40cs.indiana.edu-20080318044924-uvf4daqro1sj8gvx? file_id=psyntax.config.ss-20071009125425-0emiakw98pjacfzu-2
[2] http://bazaar.launchpad.net/~aghuloum/ikarus/ikarus.dev/annotate/ aghuloum%40cs.indiana.edu-20080318044924-uvf4daqro1sj8gvx? file_id=psyntax.builders.ss-20071009125425-0emiakw98pjacfzu-1