Hi Alvaro,<div><br></div><div>(Two Q:s for you at the bottom.)<br><div><br></div><div><div class="gmail_quote">2013/1/25 Álvaro Castro-Castilla <span dir="ltr"><<a href="mailto:alvaro.castro.castilla@gmail.com" target="_blank">alvaro.castro.castilla@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I write about the 2 latest emails here:<br>
<br>
* Separate module-systems compilation:<br>
That's it. I think that is the best solution. I already did a proof of<br>
concept in the past for scheme spheres and it works well: some modules<br>
are expanded with one expander and some with other. The result is<br>
taken by Gambit seamlessly.<br>
In my experience, people don't mix define-macros and syntax-rules. For<br>
those cases where you *NEED* define-macros (like processing names of<br>
identifiers) a second pass could be offered, but is another story.<br>
One simple expander per module is a modular and simple solution I'm<br>
totally in for.<br></blockquote><div><br></div><div>Yeah.</div><div><br></div><div>By this do you mean that you think the idea I proposed in the email ~17hrs ago is a good direction for the development?</div><div><br></div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Lightweight-portable implementation of BH:<br>
You can see some of the techniques I talk about here:<br>
<a href="https://www.youtube.com/watch?v=Q7c0rU9Lv28" target="_blank">https://www.youtube.com/watch?v=Q7c0rU9Lv28</a><br>
<br>
The point is that if you have an implementation that is lightweight<br>
and pluggable enough, you can use it for remote REPLs of any kind<br>
(mobile debugging, web servers, hot code swapping in webservers -which<br>
can be done with termite-), like the example of the video.<br>
<br>
Why I so much like Alexpander is because it does exactly that: it is<br>
less than 1KLOC and works with any scheme system. The only issue with<br>
being portable is that you don't have that nice error reporting,<br>
apparently (and that you don't use the non-portable facilities that<br>
could make it faster and more compact). But BH doesn't need to be<br>
portable across scheme implementations so this is our chance to make a<br>
BH with these features.<br>
<br>
This is why I insist so much on the separation of concerns and the<br>
lightest possible BH.<br>
I've been thinking about possible ways of making BH just a text<br>
processor (like Alexpander currently is), and I believe is possible.<br>
The only issue is that probably you need to output more than one file.<br>
Simply knowing which symbols to prepend with which namespace prefix,<br>
you already have a simple module system that can have the same<br>
encapsulation properties than BH, if you mix that with macro expansion<br>
then you have all you need.<br>
<br>
The only thing I'm trying to figure out is how to make this #namespace<br>
be prepended to macros names, as they need to be part of the module<br>
system as well, but that could be handled by the macro expander (which<br>
goes hand in hand with this module system).<br>
<br>
Really, what I have now working at Scheme Spheres and works pretty<br>
well (waaaaay faster macro expansion than BH) gives me this:<br>
- full expansion of syntax-rules in a first pass<br>
- expansion of define-macro's in a second pass<br>
- module system in the Gambit style<br>
- fully embeddable in any system that I want to not just eval scheme<br>
code, but process its macros<br>
<br>
What does it need to achieve all we need from Blackhole and be<br>
superior due to the portability and embeddability?<br>
- module system that incorporates the macros<br>
- better error reporting for macros<br>
<br>
In summary, a solution like I'm proposing would have the following features:<br>
<br>
- embedabbility: could be embedded in a web browser (with a javascript<br>
backend), in a web server for hot code swapping and testing, live<br>
coding (see <a href="http://toplap.org/" target="_blank">http://toplap.org/</a> for some examples of this world, and<br>
let me tell you that one of the most interesting apps for live coding<br>
is currently running on Racket), remote debugging and coding of<br>
Android devices. And many others options that this would open the<br>
doors to.<br>
- composability: a separation of concerns would make it easy for<br>
people to make small apps that glue together a workflow, very much in<br>
the Unix style. Also, this would be more welcoming for people to<br>
contribute to new "utilities". For instance, we now should worry just<br>
about the essential utilities (macros, modules and maybe packages),<br>
but all the niceties that we find in other ecosystems can be built on<br>
top of these 3 (and I'm talking about gem/sids, bundler/sbundle,<br>
testing, literate programming, automatization). And these utilities<br>
could be used by people who don't want to use BH at all!<br>
- control: simplicity and respecting the "Gambit ways" (like just<br>
producing a Scheme output and delegate to Gambit), will allow for<br>
*full* control of how you want your code to live. </blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I mean, with BH we<br>
lost control of things like dynamically loading object files by need,<br></blockquote><div><br></div><div>What was this about, can you describe the use case and problem?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


or just compiling everything in one C file for MAX performance<br>
(avoiding trampolines).<br></blockquote><div> </div><div>I believe BH has a feature for this, it's something like that it can take all the modules at least in the same dir and make only one module file out of them.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, that is my proposal, and I believe it is actually much simpler<br>
than original Blackhole and would solve more problems.<br></blockquote><div><br></div><div>Yes, it looks like it will be something like this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Best regards,<br>
<br>
Álvaro<br>
</blockquote></div><br></div><div><br></div><div><br></div><div><div>So basically the Scheme environment-specific code (like production of ##namespace codes, inserting code into the Scheme environment, doing compile-file) should be split apart from as much of the module system 'core' as possible.</div>

<div><br></div><div>Maybe, I'll start drafting some kind of API for all this stuff soon.</div><div><br></div><div> * Would be happy if you could give spontaneous feedback on the API draft I sent you yesterday, for interface between package management/module loader and module system.</div>

<div><br></div><div><br></div><div>I'm not clear on what kind of requirements that a live coding environment or alike could have.</div><div><br></div><div>Really, this BH now will be made primarily for Gambit, and support for generation toward other systems will be a bit like a bonus. I believe something like a-set-of-modules => a Scheme code image suitable for feeding Scheme2JS with, is completely realistic.</div>

<div><br></div><div><br></div><div> * Alvaro: When do you believe your document on use and advanced use of syntax-rules will be ready?</div></div><div><br></div><div><br></div><div>I'm a but curious on how line number info should be managed through this expansion process. I know Gambit has an internal format for it already, hopefully we can just hook onto that.</div>

<div><br></div><div>All the macro expanders will need to traverse the input Scheme structure atop a DSL that deals with this format.</div><div><br></div><div><br></div><div><br></div><div>Really, if the DSL:s involved are just well documented, and all the involved modules can be loaded as ordinary BH modules for anyone who wants to use them, then I believe we've got a high degree of plugability and reusability and dynamicity in all kinds of directions already there.</div>

<div><br></div><div>So, BH was monolithic in these respects, perhaps it could have been designed like this but it was not. Hopefully by just doing this we get all those godo qualities.</div><div><br></div><div>Brgds,</div>

<div>Mikael</div><div><br></div></div>