[Ecls-list] [Suggestion] Caching expansion of type-specifier

[Juan Jose Garcia-Ripoll]

On Sun, Nov 29, 2009 at 8:19 PM, Gabriel Dos Reis
<gdr at integrable-solutions.net> wrote:
> Let me explain what I understood by what the caching would do.
> If a deftype is expanded for the first time, and it is know to be of the
> restricted form above, then remember its expansion.

The problem is that I would not know how to beging characterizing what
is ok and what is not ok. DEFTYPE forms can get pretty hairy, include
list concatenation, merging, etc. This is what I meant by "clever":
pushing in the core (this could not be in the compiler) the
infrastructure for analyzing DEFTYPE forms and determining which ones
are safe to cache.

My point was also that maybe it is useless to perform that analysis
when other implementations are now really ignoring it completely. SBCL
for instance does not care and assumes all DEFTYPE forms will always
return the same values when given the same arguments (this is what I
meant by "side-effect-free": it does not care about the context in
which it is run, no global state, etc).

>> But there are other concerns. For instance the cost of caching. ECL
>> does not do recursive expansion of DEFTYPE types right now.
>
> I understand that analysis; would you still come to the same conclusion
> if ECL did full walk in TYPEP?

No. I would then cache the type expansion just like SBCL does.

In any case what this thread also suggests [scrabbling in notebook] is
that it may make sense to do eager and recursive expansion of DEFTYPE
forms and cache that.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com