<div class="gmail_quote">n Sun, May 6, 2012 at 6:13 AM, Luís Oliveira <span dir="ltr"><<a href="mailto:luismbo@gmail.com" target="_blank">luismbo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Sat, May 5, 2012 at 4:40 PM, Liam Healy <<a href="mailto:lnp@healy.washington.dc.us" target="_blank">lnp@healy.washington.dc.us</a>> wrote:<br>
> However, this comment got me to thinking that there are a lot of<br>
> (unnecessary) round trips through parse-type/unparse-type.  It seems to me<br>
> that they could be eliminated or reduced.  Perhaps as a design philosophy,<br>
> we should only have parsed types internally, and then we won't need<br>
> unparse-type at all?   Changing this would be a lot of work, I realize.<br>
<br>
</div>What makes you say there are a lot round-trips through parse- and<br>
unparse-type? Grepping the source we code, we can find two usages of<br>
unparse-type: (1) the make-load-form method for foreign-type and (2)<br>
some foreign-array-type code.<br>
<br>
(2) shouldn't be there and it's got a FIXME nearby. (1) is why<br>
unparse-type was introduced. Instances of foreign-type can end up in<br>
fasls after various macros and compiler macros kick in and so we need<br>
a way to serialize them.<br>
<br>
Cheers,<br>
<span><font color="#888888"><br>
--<br>
Luís Oliveira<br>
<a href="http://r42.eu/%7Eluis/" target="_blank">http://r42.eu/~luis/</a><br>
</font></span></blockquote></div><br>Ah, OK, not round trips, forget what I said about unparse-type.  My sense is there's repeated reparsing.  If a type was always parsed when read, and the parsed form is stored, would that save some reparsing?   So the type slot in foreign-struct-slot would not need to be parsed each time it's used.<br>

<br>Thanks, <br>Liam<br>