[gambit-list] Black Hole and C source

Álvaro Castro-Castilla alvaro.castro.castilla at gmail.com
Tue Jan 22 19:47:58 EST 2013


I've done a few tests with BH (both legacy and master). Currently, I'm more
cautious about Blackhole's maturity.

- BH "legacy" actually supports (module-compile! <module> to-c: #t) for C
output. Then you can produce link files just from the list of produced C
files, I'd expect.
But BH master doesn't support to-c compilation, that's some functionality
that I tried to implement (in my github fork) that fails with FFI code as I
explained before. If there is some solution for this I'd be the happiest
possible and earn back some of my lost hair in my head. I have an idea of
how it could be fixed, but... (next point)

- Both legacy and master branches fail to pass the syntax-rules stress test
designed by Oleg Kiselyov. While at this level, macrology might look like
alchemy for deities, is humanly useful and I trust this code in judging BH
macro system's maturity, since it just usses continuation-passing-style
macros and some "essential" macros I myself use in my code.
Reference:
http://okmij.org/ftp/Scheme/macros.html#syntax-rule-stress-test

I'd be happy to improve Blackhole's master branch in all the aspects like
packages, modules and compilation (I have my own ideas that differ a bit
from what have been talked here, but that's ok). But I can't devote the
time to understand and fix the macro system at the moment. When this part
is working flawlessly (ie. passes this stress test) I'll switch to BH from
Alexpander (or Psyntax, which also passes the test) and contribute to its
maintenance. If I find the time and energy to tackle the whole macro
system, I'll do it, but I can't really do that in the near future.

Honestly, I think Blackhole is essential to Gambit's ecosystem. However, at
the moment isn't as mature and flexible as Gambit with Alexpander, even
though I very much miss the module system.

Best regards,

Álvaro



On Tue, Jan 22, 2013 at 4:39 PM, Mikael <mikael.rcv at gmail.com> wrote:

>
>
> 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:
>> https://github.com/alvatarc/blackhole/commits/master
>>
>>
>>> 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
>>
>
> Brgds
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130123/b7f9270e/attachment.htm>


More information about the Gambit-list mailing list