[gambit-list] Black Hole and C source
mikael.rcv at gmail.com
Tue Jan 22 10:39:17 EST 2013
2013/1/22 Álvaro Castro-Castilla <alvaro.castro.castilla at gmail.com>
> On Tue, Jan 22, 2013 at 3:12 PM, Mikael <mikael.rcv at gmail.com> wrote:
>> 2013/1/22 Álvaro Castro-Castilla <alvaro.castro.castilla at 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
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
> 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
> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list