<br><br><div class="gmail_quote">2011/7/29 Carl Eastlund <span dir="ltr"><<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Fri, Jul 29, 2011 at 12:44 PM, Maurizio Giordano<br>
<div class="im"><<a href="mailto:maurizio.giorda@gmail.com">maurizio.giorda@gmail.com</a>> wrote:<br>
</div><div class="im">> On Fri, 2011-07-29 at 12:20 -0400, Carl Eastlund wrote:<br>
>><br>
</div><div class="im">>> There is one module called "multiset", but all of its definitions are<br>
>> executed twice because your program uses them in two different phases:<br>
>> once at run-time and once at compile-time. That means<br>
>> there are two different mset types with two different constructors and<br>
>> two different mset? predicates. Call the run-time versions mset.1 and<br>
>> mset?.1, and the compile-time versions mset.2 and mset?.2. Similarly,<br>
>> you have print-type.1 and print-type.2 at run-time and compile-time.<br>
>><br>
>> Your custom reader produces an mset.1 value. Your macro calls<br>
>> print-type.2 which checks mset?.2, and mset?.2 produces #false when<br>
>> given an mset.1 value. The code your macro produces, however, calls<br>
>> print-type.1, which checks mset?.1, and that produces #true (I'm using<br>
>> the new long-form names of #f and #t for readability). So no<br>
>> information is being lost -- it's just that there are two versions of<br>
>> everything running around, and they cannot be mixed and matched.<br>
> Now it is perfectly clear to me.<br>
> thanks a lot.<br>
>><br>
>><br>
</div><div><div></div><div class="h5">>> Are you sure you want to put mset values in as literal syntax? That<br>
>> leads to all sorts of odd behavior -- for instance, the contents of<br>
>> those msets will need to be syntax at compile-time if they are to<br>
>> contain expressions, but non-syntax at run-time if they are to contain<br>
>> useful values. The expansion system will not do this plumbing for<br>
>> you. You'll get a lot more "bang for your buck" if you instead just<br>
>> use a match expander as both a pattern to recognize msets and a<br>
>> constructor to build them. This avoids all issues of crossing phase<br>
>> boundaries, because the compile-time code acts entirely by recognizing<br>
>> identifier bindings, and does not have to know about the<br>
>> representation of msets at all.<br>
> The "templates" I generate at compile-time in the macro are some sort of<br>
> a syntax tree:<br>
><br>
> An example:<br>
> the macro (three) inputs: < (1 x), 2 > x 3<br>
> will generate an hash like this:<br>
><br>
> #hash ((mset . #hash((list . #hash((integer . 1)<br>
> (symbol . x)))<br>
> (symbol . x)))<br>
> (symbol . x)<br>
> (integer . 3))<br>
><br>
> By using this nested hashtable, the "inject-code" function will<br>
> produce a (recursive) pattern matchers code to be included in the lambda<br>
> code generated by the macro. Symbols in the input are not evaluated,<br>
> they will are considered identifiers to be bound (and unified)<br>
> during the pattern matching.<br>
><br>
> Therefore, I think I am not using the mset values at compile-time.<br>
> I simply parse the macro inputs to generate a sort of syntax tree<br>
> (i.e. the hashtable).<br>
<br>
</div></div>You are not using them as outputs, but you are using them as inputs.<br>
Even that is problematic, exactly as you have seen. I suggest writing<br>
a macro using only standard syntax objects containing lists, strings,<br>
symbols, and numbers for both input and output if at all possible.<br></blockquote><div> </div><div>... unfortunately i need the macro to accept as input a "mset", ricognize it, and parse recursively the inner mset elements (that can be list, numbers, or </div>
<div>even other msets).</div><div>The hashtable the macro produces at compile time is like </div><div>an Abstract Syntax Tree of the macro inputs. </div><div>In my new language implementation the mset</div><div>is a fundamental data structure, I cannot rely only on standard</div>
<div>syntax objects like lists, strings, etc.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This will save a lot of trouble. Using hash tables in syntax objects<br>
can work, but even that brings up some tricky issues. I find it is<br>
almost always better to consume and produce code that refers to or<br>
produces complex data types, rather than code actually represented as<br>
complex data types.<br></blockquote><div>Maybe a way could be to generate the hash by making the macro parsing/processing the list of input syntaxes, rathen than the</div><div>inputs themselves. I mean, I can traverse the "syntax" representation</div>
<div>of each input and get the information I need. Maybe it will be more complex,</div><div>but it could work.... I don't know.</div><div><br></div><div>Another way could be to define a new "match" form, starting from</div>
<div>the one provided by racket. The new "match" should apply also to msets</div><div>and ... have other peculiar behaviours (???). Also this way is long.</div><div>I will decide which solution to follow.</div><div>
Thank you, Carl.</div><div>If you have any idea, it is welcome.</div><div><br></div><div>Cheers,</div><div>Maurizio.</div><div><br></div><div><br></div><div>PS. Sorry if I was not able to give more details... my implementation is composed of large-code modules... I am available to send the complete </div>
<div>code to everyone who is interested in collaborating to the project.</div><div>long and </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--Carl<br>
</font></blockquote></div><br>