I&#39;ve done a few tests with BH (both legacy and master). Currently, I&#39;m more cautious about Blackhole&#39;s maturity.<div><br></div><div>- BH &quot;legacy&quot; actually supports (module-compile! &lt;module&gt; to-c: #t) for C output. Then you can produce link files just from the list of produced C files, I&#39;d expect.</div>




<div>But BH master doesn&#39;t support to-c compilation, that&#39;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&#39;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)</div>




<div><br></div><div>- 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&#39;s maturity, since it just usses continuation-passing-style macros and some &quot;essential&quot; macros I myself use in my code.</div>




<div>Reference:</div><div><a href="http://okmij.org/ftp/Scheme/macros.html#syntax-rule-stress-test" target="_blank">http://okmij.org/ftp/Scheme/macros.html#syntax-rule-stress-test</a></div><div><br><div><div>I&#39;d be happy to improve Blackhole&#39;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&#39;s ok). But I can&#39;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&#39;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&#39;ll do it, but I can&#39;t really do that in the near future.</div>


<div><br></div><div>Honestly, I think Blackhole is essential to Gambit&#39;s ecosystem. However, at the moment isn&#39;t as mature and flexible as Gambit with Alexpander, even though I very much miss the module system.</div>




<div><br></div><div>Best regards,</div><div><br></div><div>Álvaro</div><div><br></div><div><br><br><div class="gmail_quote">On Tue, Jan 22, 2013 at 4:39 PM, Mikael <span dir="ltr">&lt;<a href="mailto:mikael.rcv@gmail.com" target="_blank">mikael.rcv@gmail.com</a>&gt;</span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><br><div class="gmail_quote"><div>2013/1/22 Álvaro Castro-Castilla <span dir="ltr">&lt;<a href="mailto:alvaro.castro.castilla@gmail.com" target="_blank">alvaro.castro.castilla@gmail.com</a>&gt;</span><br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div>On Tue, Jan 22, 2013 at 3:12 PM, Mikael <span dir="ltr">&lt;<a href="mailto:mikael.rcv@gmail.com" target="_blank">mikael.rcv@gmail.com</a>&gt;</span> wrote:</div></div><div class="gmail_quote"><div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br><div class="gmail_quote"><div>2013/1/22 Álvaro Castro-Castilla <span dir="ltr">&lt;<a href="mailto:alvaro.castro.castilla@gmail.com" target="_blank">alvaro.castro.castilla@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">










<p>I&#39;ve recalled that the issue happened when trying to compile with ffi code that couldn&#39;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&#39;ll be very happy :-)</p>










</blockquote></div><div>Can you tell how to reproduce this?</div><div><div></div></div></div></blockquote><div><br></div></div><div>I&#39;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:</div>








<div><a href="https://github.com/alvatarc/blackhole/commits/master" target="_blank">https://github.com/alvatarc/blackhole/commits/master</a></div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">








<div class="gmail_quote"><div><br></div><div>I&#39;ll get into tweaking the syntactic branch into good functioning and bringing order to documentation of surface aspects for all BH in a while.</div></div></blockquote><div>








<br></div></div><div>If you plan on doing this, we should coordinate. </div></div></blockquote><div><br></div></div><div>Ok I&#39;ll do this.</div><div><br></div><div>Basically I made almost-all of the documentation that&#39;s out there, and at the time it was made, nonsyntactictower/legacy was the newest one and syntactictower/master was just an idea.</div>






<div><br></div><div>Since then, the combination of documentation on Gambit&#39;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&#39;s all clear.</div>






<div><br></div><div>And apart from this, I&#39;m interested in tweaking syntactictower/master to work as good as nonsyntactictower does, for the things that nonsyntactictower does (i.e., the central stuff).</div><div><br>






</div><div>And last, I&#39;m interested in updating both syntactictower and nonsyntactictower so both have a (srfi ) &#39;package&#39;/&#39;module resolver&#39;, that in that resolver the SRFI:s are identifier _primarily_ by name and that there&#39;s secondarily a &#39;proxy&#39; module by a printed name (&quot;strings&quot; for 13, &quot;list&quot; 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.</div>






<div><br></div><div>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&#39;s why.</div>




<div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div class="gmail_quote"><div>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.</div></div>





</blockquote>


<div><br></div></div><div>Yes it is relevant. Especially the packages part needs some review.</div></div></blockquote><div><br></div></div><div>Yes I agree on that one, that probably is where there&#39;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&#39;t scale well across projects, am curious to see a solution to that that scales better, must be one.</div>






<div><br></div><div>If you have any ideas for how this could be done nicely, please feel free to share.</div><div><br></div><div><br></div><div>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&#39;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.</div>




<div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>The macros part is too scary for me to dive into it ATM.</div></div></blockquote>






<div><br></div></div><div>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&#39;s people around who know this very well though I didn&#39;t stumble on any concise and easy-enough-to-read guide on all the involved macro facilities yet.</div>






<div><br></div><div>Might be a good thing to have before trying to understand the source of a probably-not-over-commented expander.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>Also, what about documentation of these macro facilities in general, as you Alvaro proposed in an email ~2w ago?</div>






<div><div><br></div></div></div></blockquote><div><br></div></div><div>Well, that&#39;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&#39;t have time to do this if I get into BH though!</div>








<div><br></div><div>Best regards,</div><div><br></div><div>Álvaro</div></div>
</blockquote></div></div><br><div>Brgds</div><div><br></div>
</blockquote></div><br></div></div></div>