[gambit-list] As far as the renaming scheme goes, ...
Abdulaziz Ghuloum
aghuloum at cs.indiana.edu
Wed Mar 19 00:05:23 EDT 2008
On Tue, 18 Mar 2008 13:50:02 -0400, Bradley Lucier
<lucier at 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
More information about the Gambit-list
mailing list