<div dir="ltr">Hi Razvan,<br><div class="gmail_extra"><br><div class="gmail_quote">2013/12/9 Răzvan Rotaru <span dir="ltr"><<a href="mailto:razvan.rotaru@gmail.com" target="_blank">razvan.rotaru@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Hi,<br><br>Congratulations, and a big thank you. This is great news. I remember looking over scheme implementations some time ago, and not being sure whether gambit is actually still alive or not (besides bugfixing). Whether there's a community around it. Whether somebody is till actively working on it and/or supporting it. In the mean time I have learned the answer, and I've also found out that things are moving towards multi-core and multi-platform (speak: javascript). This is great.<br>


<br></div>If I am allowed, I would like to criticize the lack of a "community adopted" module system, which I think can have a big (positive) influence on the community. My oppinion is that newcomers want to get started quickly. And they have stuff to do. They want to tackle the big questions later, and get stuff done now. Rick Hickey did put it very nicely: default matters. I can't but agree.<br>


If Black Hole is good enough, I can't but suggest to give it a "pseudo standard" status and include it in the distribution (or recommend it as a standard module system). And make sure it's handling libraries at least at convenient as maven (i.e. auto download and dependency resolution).<br>

</div></div></blockquote><div><br></div><div>Sure Black Hole works as a pseudo standard.</div><div><br></div><div>However please note that with benefit, any module system specific stuff can be contained inside a cond-expand file in each module file, and thus one and the same module package (repository etc.) can be made to deliver for Vanilla Gambit and any module system out of the box concurrently, without modification.</div>

<div><br></div><div>(99% of modules use little to no macros in all cases, so module system specific stuff can this way generally really be located to a cond-expand)</div><div><br></div><div>Also however re pseudo standard, please note that Black Hole's present implementation does not deliver.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>It is incredibly important to have an easy quickstart, and have libraries at your fingertips, and get stuff quickly done. This is actually the secret recipe of Java (even if they discovered it in the second decade, and the core technology still sucks big time, even now). As much as I hate to wake a sleeping dragon, I must say that gambit has to make more bold moves and decisions and focus on gathering a community around it, if it intends to be practical.<br>


<br></div><div>Thanks, and don't kill the critique.<br></div><div>Razvan<br></div><div><br><br></div><div><br></div>I'm not sure if and how I can help. If there are ideas out there, I'm open to suggestions.<br>

</div></blockquote><div><br></div><div>Because you asked, here's one thing:</div><div><br></div><div><div>The public availability of a document per the following is essential in the design and implementation of a module system, and the current lack of it makes a key constraint in the same:</div>

</div><div><br></div><div>If you have some serious spare time to spend, then, carefully go through the main marco systems out there (define-macro without or with alias macros, syntax-rules, syntactic closures, syntax-case) and write a document that describes their respective</div>

<div><ul><li>motivation, function and strengths</li><li>forms</li><li>examples of use that illustrate any intricacies like how corner case uses play out<br></li><li>exactly deterministically the mechanism of expanding them, with exactly what state and logics are needed for this and at what points (for example, a syntactic tower)</li>

<li>how the respective one plays out</li><ul><li>conceptually and implementationally with the other systems and</li><li>with typical module system functionality such as identifier handling including namespaces</li></ul><li>

any particular features or fundamentals that are required from the underlying Scheme implementation<br></li></ul></div><div>Write it so illustrative and clear that anyone could implement a full featured expander for a given system, and properly understand the prospects or issues about a hybrid expander (i.e. one supporting more than one macro system).<br>

</div><div><br></div><div>Doing this, you'll help the entire Scheme community a great deal for the short and long term per the above.</div><div><br></div><div>as the documents in circulation currently are</div><div><ul>

<li>the original papers which are purely academic,</li><li>some sample implementations such as Alexpander which don't do the job of documentation and have in themselves little or no educational value,</li><li>and some partial specialized documentation that don't provide an overview and also not a complete picture.</li>

</ul></div><div>Feel free to share any thoughts on this.<br></div><div><br></div><div>Best regards,</div><div>Mikael</div><div><br></div></div></div></div>