2013/1/22 Álvaro Castro-Castilla
<alvaro.castro.castilla@gmail.com>
2013/1/22 Álvaro Castro-Castilla
<alvaro.castro.castilla@gmail.com>
I've recalled that the issue happened when trying to compile with ffi code that couldn't be linked with native libs and loaded, ie depends on libraries for another platform. I believe this is true for BH old branch as well unless the code expansion doesnt load code in the interpreter (I doubt it). Please correct me if you can fix that, I'll be very happy :-)
Can you tell how to reproduce this?
I'll be able to tell you when I come back to BH. At the moment I use my own system with Alexpander. But you can take a look at my branch:
I'll get into tweaking the syntactic branch into good functioning and bringing order to documentation of surface aspects for all BH in a while.
If you plan on doing this, we should coordinate.
Ok I'll do this.
Basically I made almost-all of the documentation that's out there, and at the time it was made, nonsyntactictower/legacy was the newest one and syntactictower/master was just an idea.
Since then, the combination of documentation on Gambit's wiki + the BH manuals uploaded there + the readme shown on the Github repo page kind of got a bit out of sync with each other, and I just want to bring order to that so it's all clear.
And apart from this, I'm interested in tweaking syntactictower/master to work as good as nonsyntactictower does, for the things that nonsyntactictower does (i.e., the central stuff).
And last, I'm interested in updating both syntactictower and nonsyntactictower so both have a (srfi ) 'package'/'module resolver', that in that resolver the SRFI:s are identifier _primarily_ by name and that there's secondarily a 'proxy' module by a printed name ("strings" for 13, "list" for 0 etc.) that re-exports the primary module. This is, I believe, the primary cause for compatibility issues for code projects using BH, between the two branches currently.
And last, I may want to make the requirement in syntactictower of all symbols used in code being defined, optional through a configuration option. :) We already know how to do this. Can be a PITA to have a requirement of code being perfect sometimes that's why.
Re BH internals, documentation and adding comments, and perhaps even reimplementation of some bit just in case needed for high code clarity, I guess would be completely relevant.
Yes it is relevant. Especially the packages part needs some review.
Yes I agree on that one, that probably is where there's most space for actual improvement, the design there is not cemented. For instance currently I believe package names and available packages are hardcoded in a user-global file, obviously that can't scale well across projects, am curious to see a solution to that that scales better, must be one.
If you have any ideas for how this could be done nicely, please feel free to share.
As for the central functionality (the import form, dependency loading and calculation, actual code expansion including coloring and expansion of define-macro and SC) I believe it's all in a very good form already in the syntactic/master repo and that just needs some minor tweaking like firing it up, see if anything clearly misbehaves like exceptions etc., and if so fix it.
The macros part is too scary for me to dive into it ATM.
Hehe ok, also of course it would be good to have a specification of what the macro expander *really does* (in terms of exact macro forms), supposedly there's people around who know this very well though I didn't stumble on any concise and easy-enough-to-read guide on all the involved macro facilities yet.
Might be a good thing to have before trying to understand the source of a probably-not-over-commented expander.
Also, what about documentation of these macro facilities in general, as you Alvaro proposed in an email ~2w ago?
Well, that's a completely different topic: I planned on writing about techniques for developing syntax-rules macros, but not about implementation details or any other gory details. Just some practical tutorial. I don't have time to do this if I get into BH though!
Best regards,
Álvaro