On 2012-12-19, at 6:56 AM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Hi,
I've managed to get Alexpander in a quite usable state, I'm happy with it. It's fast and stable, and I managed to make keywords work, so I can use functions defined with ##define in DSSSL extensions, and namespaces for modules (I couldn't do these with psyntax). I also can mix low-level macros, in a second stage, which is good enough, since these are mostly used for very specific stuff related to FFI code generation and compilation helpers. High-level syntax is done in syntax-rules in my code.
What I see as a main issue with Alexpander, however, are code locations of errors. Specially, those related to LET and other basic forms which are expanded to fundamental lambdas. That turns the code around all the time making it more difficult to locate the original source of the error.
The basic compilation process involves generating intermediate files, expanded with Alexpander and then compiling them with Gambit.
I believe that if this is improved (at least avoiding alexpander expansion of let/let*/letrec forms), the resulting syntax system is satisfactory. It could even be made to be compatible with Blackhole's module system, alghouth my alternative allows me the finer control for cross-compilation (Android) that I couldn't achieve in Blackhole after some time hacking it.
Any ideas for improving this? I've tried hacking Alexpander removing the redefinitions and making them stubs, but no luck. I'll dive further into Alexpander if I don't find any other solution. What are the consecuences of expanding let/let*/letrec, etc, to lambdas besides code locations? (am I missing any optimizations or some structure used by Gambit for better code generation?)
The Gambit compiler's internal representation handles all the "let" forms using a call to a lambda-expression. So you will get exactly the same optimizations down the line whether you use (let ((x X)) ...) or ((lambda (x) ...) X).
Marc