[Ecls-list] [Suggestion] Caching expansion of type-specifier
Gabriel Dos Reis
gdr at integrable-solutions.net
Sun Nov 29 19:52:55 UTC 2009
On Sun, Nov 29, 2009 at 1:34 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> 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.
OK. I think similar thing for C++ -- allowing the compiler to evaluate
function calls at compile time (almost like in Lisp when :compile-time)
and I ensured side-effect-freeness by restricting the kind of expressions
one can have in such function definition.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf
I thought similar implementation strategy
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01624.html
could be applied. Never mind, if it is too much work.
>
> 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).
that notion of "side-effect-free" matches my understanding as well.
>
>>> 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.
OK.
-- Gaby
More information about the ecl-devel
mailing list