Hi,
In the past I've used Blackhole, the bundled syntax-case implementation and Alexpander. Each one has its own advantages and disadvantages:
blackhole - A: it works well, and not only syntax-rules, but also sc-macro-transformer and er-macro-transformer - D: forces you to use its module system. I think this is a mistake, since is not standard, but anyway it has some current limitations for my work that I tried to fix in my own branch but stem from deep parts of blackhole that would require a deep understanding and rewrite. I tried that already and spent a fair amount of time working with Per these issues and decided to drop it.
syntax-case - A: installed with Gambit, easy to setup, supports syntax-case? (I guess so, but haven't tried this last point as I don't really care at the moment) - D: incompatible with DSSSL and other Gambit functionality. I really don't understand why the bundled implementation doesn't support it...
Alexpander - A: it is supposed to support DSSSL and be nicer to Gambit - D: I still get errors related to define-macros, even if they are not mixed with define-syntax macros. Taking into account that some of my macros work with both blackhole and syntax-case but not with alexpander, I assume this implementation is less mature/stable.
The point is: is there any stable, good implementation of R5RS syntax-rules that is fully-compatible and nice to all of Gambit's functionality?
I believe this should be a basic feature of the Gambit ecosystem, but maybe I'm missing something. Any help, ideas or opinions?
Best regards,
Álvaro Castro-Castilla
Afficher les réponses par date
2012/11/15 Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com
Hi,
In the past I've used Blackhole, the bundled syntax-case implementation and Alexpander. Each one has its own advantages and disadvantages:
blackhole
- A: it works well, and not only syntax-rules, but also
sc-macro-transformer and er-macro-transformer
- D: forces you to use its module system. I think this is a mistake, since
is not standard, but anyway it has some current limitations for my work that I tried to fix in my own branch but stem from deep parts of blackhole that would require a deep understanding and rewrite. I tried that already and spent a fair amount of time working with Per these issues and decided to drop it.
..
The point is: is there any stable, good implementation of R5RS syntax-rules that is fully-compatible and nice to all of Gambit's functionality?
Beyond Black Hole, nope.
I believe this should be a basic feature of the Gambit ecosystem, but maybe I'm missing something. Any help, ideas or opinions?
There's space for an even better working Black Hole and perhaps for some more hooks in Gambit for module system functionality.
Best regards,
Álvaro Castro-Castilla
Perhaps it can be looked with benefit on like this:
While the great majority of Scheme's language spec is "The Answer"-grade (you get what I mean - the grade where it's like wow that must really be the way to do it; obviously there's others too, some documented and others yet to be found),
The macro systems developed, well, ever, for Scheme, don't come close to that grade of quality.
Basically define-macro is nice and effective but has a narrow limit for how much you can abstract on it. Syntax-rules comes with power from the fact that it's purely functional, but it's a limited purpose tool and it's obvious there's more to be made. Syntactic closures and syntax-case are extremely powerful but come with API:s that are completely unsuitable for debugging and increase the complexity of the Scheme language and the complexity of the Scheme environment many-fold, and this way *completely* and fundamentally non-Schemy. It's not simple anywhere, at the level of concept it's like biting yourself in your own tail.
Luckily though, Scheme doesn't stand and fall with the perfection of its macro system, practically the macros are only used for limited rewriting purposes, so given its perfection in Scheme's other areas, it's fine there's diversity and limits about the macros.
Gambit nicely takes the position of kind of not caring about any of this stuff at all, focusing on executing Scheme with clarity and excellence, and implements a define-macro expander as it provides an enormous benefit at almost no cost, 10 lines of sourcecode perhaps, and if not else, it's used all across Gambit's own sources.
Black Hole is the best attempt for Gambit at uniting the algorithms and designs of define-macro, syntax-rules and syntactic closures, which are contradictory with each others as well as in themselves imperfect.
If the macro expansion you're looking for cannot be made with the current version of Black Hole and you feel it would be of a general value to have the support you have on your mind, probably the easiest thing for both you and everyone, would be that you decipher Black Hole from bottom up, and reimplement it from scratch (now that you concluded there's no easier way), perhaps with a twist, with the particular aspects you want now in it.
This way you'd have the opportunity to get really experienced in the more and less subtle aspects of different types of Scheme macro expansion, and into an excellent position for documenting and commenting your module system/Black Hole, and spreading the knowledge of how this stuff works and fits together.
Per put approx six man months into Black Hole. This was a very giving adventure in computer science for him, and brought a depth and specificity of understanding he could not have anticipated.
With him as conclusions he got an understanding of algorithmic limits within syntactic closures that I still feel I have not really understood from him, I'd be highly interested in getting this someday.
Probably given that his code is there and you also can ask him some things, you could get to where he got within approx six weeks.
It will very most probably be more than worth it, and you'll have the full satisfaction of having done it yourself!
Handling of modularized code is essential for incremental development in Gambit, so it is well spent time in all cases, that the understanding, software and conversation on this topic is expanded.
(Regarding Black Hole I feel its source could be better commented, and its concepts and details and their limits much better documented, I mean currently there's almost nil of that. Being aware that it does deliver for all the purposes I have though, I'll work with making the 'new version' (syntactictower version) spin better generally in the time to come; over the last ~5 years I used the legacy branch and it works extremely well. Matters unrelated to macro expansion are what is pulling me to upgrade.)
If not else I hope this email encouraged good conversation. :-)
Brgds, Mikael
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
From: Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com
[...]
Alexpander
- A: it is supposed to support DSSSL and be nicer to Gambit
- D: I still get errors related to define-macros, even if they are not mixed with define-syntax macros. Taking into account that some of my macros work with both blackhole and syntax-case but not with alexpander, I assume this implementation is less mature/stable.
I think it is not a maturity/stability issue: Alexpander renames some variables and does not implements its own version of define-macro; so I think some problems are unavoidable if you want to mix code that use Alexpander and code that use Gambit's define-macro. Separate compilation is you friend here.
There is an newer version of the original Alexpander that is much less invasive in renaming variables, I planned to patch it with the DSSSL extension, but I am not sure it is worth the effort. I wondered if there is a way to be sure that Gambit's macroexpander runs *before* Alexpander, but I am not even sure that it could make sense.
I started hacking the original Alexpander for three reason:
1. using R5RS libraries
2. DSSSL compatibility (but I conclueded that it's not so important, thanks to ##define and ##lambda) 3. code size/compilation speed (much better than psyntax)
and it served me quite well.
The point is: is there any stable, good implementation of R5RS syntax-rules that is fully-compatible and nice to all of Gambit's functionality?
I don't think so. Maybe it will be here in the future if Gambit will adopt R7RS, either as a simple syntax-rule expander (similar to Alexpander) for the small language either as a more complete low-level system for the large language.
--marco
Thanks for your replies. Some months ago, there was a very interesting propopsal by Per, which was motivated by the conversations Mikael and I had with him regarding Blackhole. His position was that with a simple addition to Gambit's code, benefits for the define-macro system would be huge, effectively achieving hygiene. But it must be done in My issues with blackhole were not related to macro systems, but issues with finer compilation workflow control.
Marc, how hard would be to implement this? (by you or someone with no prior knowledge of Gambit's internals)
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2012-March/005815.htm...
On Thu, Nov 15, 2012 at 10:28 AM, Marco Benelli mbenelli@yahoo.com wrote:
From: Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com
[...]
Alexpander
- A: it is supposed to support DSSSL and be nicer to Gambit
- D: I still get errors related to define-macros, even if they are not
mixed with define-syntax macros. Taking into account that some of my macros work with both blackhole and syntax-case but not with alexpander, I assume this implementation is less mature/stable.
I think it is not a maturity/stability issue: Alexpander renames some variables and does not implements its own version of define-macro; so I think some problems are unavoidable if you want to mix code that use Alexpander and code that use Gambit's define-macro. Separate compilation is you friend here.
There is an newer version of the original Alexpander that is much less invasive in renaming variables, I planned to patch it with the DSSSL extension, but I am not sure it is worth the effort. I wondered if there is a way to be sure that Gambit's macroexpander runs *before* Alexpander, but I am not even sure that it could make sense.
I started hacking the original Alexpander for three reason:
using R5RS libraries
DSSSL compatibility (but I conclueded that it's not so important,
thanks to ##define and ##lambda) 3. code size/compilation speed (much better than psyntax)
and it served me quite well.
The point is: is there any stable, good implementation of R5RS
syntax-rules that is fully-compatible and nice to all of Gambit's functionality?
I don't think so. Maybe it will be here in the future if Gambit will adopt R7RS, either as a simple syntax-rule expander (similar to Alexpander) for the small language either as a more complete low-level system for the large language.
--marco
On 2012-11-15, at 5:07 AM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Thanks for your replies. Some months ago, there was a very interesting propopsal by Per, which was motivated by the conversations Mikael and I had with him regarding Blackhole. His position was that with a simple addition to Gambit's code, benefits for the define-macro system would be huge, effectively achieving hygiene. But it must be done in My issues with blackhole were not related to macro systems, but issues with finer compilation workflow control.
Marc, how hard would be to implement this? (by you or someone with no prior knowledge of Gambit's internals)
It is not clear to me what are all of the implications of the aliasing forms proposed. I'm worried that the auto-aliasing will generate new names for variables which will confuse the user when debugging the code. That's one of the problems with Gambit's implementation of syntax-case.
Marc