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?)
Thanks a lot.
Afficher les réponses par date
Hi,
As far as I know in gambit use a internal structure to annotate code file & location. It will be passed to expand hook as "source" object. While alexpander(the one I got from Dumping Ground) simply don't annotate its expanded result with given content. Thus the error location doesn't work.
Blackhole has related code solve the same problem in expr.scm
Thanks Meng
Thanks Meng
On Wed, Dec 19, 2012 at 7:56 PM, Á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?)
Thanks a lot.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
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
Great, very useful information. I have it integrated and works well and fast. I was transforming all ((lambda (x) ...) val) from macro expansiono into (let ((x val)) ...) Of course this was "making up" lets where there shouldn't. I will deactivate this.
On Thu, Jan 3, 2013 at 8:43 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
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
-
Marc Feeley -
Meng Zhang -
Álvaro Castro-Castilla