Looks like the only necessary primitive is something like ##namespace-resolve<div>which takes an symbol as the argument and return a full current-namespace#symbol</div><div>as the result. Then we can build the whole &quot;alias&quot; based system with it.</div>
<div><br></div><div>Does gambit have it internal?</div><div><br></div><div>Meng</div><div><br><div class="gmail_quote">On Tue, Mar 27, 2012 at 12:31 AM, Per Eckerdal <span dir="ltr">&lt;<a href="mailto:per.eckerdal@gmail.com">per.eckerdal@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>Hi,</div><div class="im">
                 
                <p style="color:#a0a0a8">On Monday 26 March 2012 at 18:10, Alex Queiroz wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
                    On Mon, Mar 26, 2012 at 6:01 PM, Marijn &lt;<a href="mailto:hkBst@gentoo.org" target="_blank">hkBst@gentoo.org</a>&gt; wrote:<span><div><div><blockquote type="cite"><div><div><br></div><div>I would be interested in knowing how this proposal compares with</div>
<div>implementing a low-level hygienic macro system such as syntactic</div><div>closures or explicit renaming macros. Actually now that I said that</div><div>this proposal sounds very much like a (partial?) implementation of</div>
<div>explicit renaming macros on top of the defmacro system. Doesn&#39;t the</div><div>paper you referenced mention something like that as well?</div></div></blockquote><div><br></div><div>I would rather have syntactic closures as well.</div>
</div></div></span></blockquote></div><div>Syntactic closures are much more complex, both conceptually and in practise to implement. The purpose of the designed outlined in this proposal is to not require to augment the language with a highly complex new identifier type that is distinct from symbols.</div>
<div><br></div><div>With this proposal, no new data type is required. You can write macros that only accept pure s-expressions (as they are parsed) as input, and only return pure s-expressions (that are pretty-printable without losing information, so it&#39;s easy to understand exactly what the return value means)</div>
<div class="im"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div>The paper contribution</div><div>seems to be focused on the fact that it&#39;s possible to write hygienic</div>
<div>macros on top of unhygienic macros and symbol macros, which is what</div><div>Common Lisp has. Besides it says that a code walker is not needed, but</div><div>that is not a necessity if the macro system would be integrated in</div>
<div>Gambit.</div></div></div></span></blockquote></div><div>It is true that the paper is written in that context. I believe its ideas are more broadly applicable than what the paper describes.
                </div><div><br></div><div>Cheers,</div><div><br></div><div>Per</div>
            <br>_______________________________________________<br>
Gambit-list mailing list<br>
<a href="mailto:Gambit-list@iro.umontreal.ca">Gambit-list@iro.umontreal.ca</a><br>
<a href="https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list" target="_blank">https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Zhang Meng<br>School of Software Engineering, Tongji University<br>MP: +86 151-2103-2798<br>
</div>