In relation with the conversation below on the use of Black Hole, here's a reflection on Gambit w Black Hole:<br><br>That the Scheme environment (i.e. Gambit) and the module system (i.e. Black Hole) are completely separate, appears to be a good abstraction to me.<br>

<br>Even if for instance R7RS introduces modules at the level of the language spec, still having that part of the language performed by a separate module system tool appears like a good idea to me.<br><br>(Disclaimer: I didn't study how R7RS does modules, and I'm in no way an expert on module system implementation)<br>


<br>This as there's so many things a module system could be set up to do - for instance, access module source code data in various ways such as retrieve packages from a remote host using who-knows what method to ensure that the respective package is up to date.<br>

     Also I would guess that there are details about how the code expansion is done that the R7RS spec leaves open to the individual module system implementation to decide.<br>     Also as a sidenote, a module system brings a lot of complexity with it that you're best off distributing to code that's completely outside of the Scheme implementation's code, so you can develop, debug and study the both completely in separate from each other.<br>

<br>So while it's a realistic goal to make a 'perfect' Scheme implementation (in the sense that it that covers 'all' usecases and could be used for years and years with only very minor code updates), making a module system that's 'perfect' in this same sense is probably impossible.<br>

<br>Thus there could easily be the need for multiple module systems for a Scheme implementation.<br><br>So, I'd suppose the solution to the issue Per pointed out below about that it's hard to integrate a module system into Gambit in a reasonable way, is to make documentation and tools for the respective module system, that keeps it super-clear how the user uses the module system (import of modules, compilation etc.), and what parts of Gambit should not be used anymore by the user except for as part of intentionally breaking into the module system's setup during module system debugging or alike, now that the user has chosen to use the module system.<br>

     Obviously a module system could also block access to the Gambit features that should no longer be used i.e. (load), (include), possibly the -exe argument etc., or overload them with corresponding features from the module system.<br>

     The solution to the issue is not to make a single module system inside Gambit that's hardwired to it and that's it.<br><br>In all cases this is what I perceive as the proper path of development, based on seeing Gambit and Black Hole currently - how they interact and the outcome from this interaction.<br>

<br>Corrections, thoughts or suggestions are welcome. For instance, what ways do you see in which Gambit could be made even more suitable for implementing a module system atop of it?<br><br>Kind regards,<br>Mikael<br><br>

<div class="gmail_quote">2011/6/8 Per Eckerdal <span dir="ltr"><<a href="mailto:per.eckerdal@gmail.com">per.eckerdal@gmail.com</a>></span><br><div>.. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div><div><div>Hehe.. The stuff you have been experiencing is a large reason to why I have pretty much given up working on Black Hole, it is so hard to integrate it into Gambit in a reasonable way.</div><div><br></div><div>

It kindof works for me personally, for instance because I know that the warning messages you see are from Gambit and not BH, but there are so many small things that don't make sense unless you know the inner workings of BH (debugging from the REPL and attempting to access the hygienically renamed variables is a mess), and I haven't been able to get around it.<br>

</div></div></div></blockquote></div><br><br>