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

[Tobias C. Rittweiler]

Juan Jose Garcia-Ripoll writes:

> On Sun, Nov 29, 2009 at 7:20 PM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
> > Well, I'm not sure how frequent are those exotic cases, and why
> > they should weight more than the common cases.
>
> No, well, the question is not whether they should weight more, but
> whether they do count at all. If they count at all, then caching is
> impossible.
>
> "Clever" caching is not an option. How does one determine when caching
> is possible? I would say that determining when a DEFTYPE function is
> candidate for caching is an NP-complete problem by itself.
>
> The problem with DEFTYPE is that it is defined to be a rather generic
> function without constraints on side effects. If we eliminate the
> possibility of side effects and dictate that the number of times that
> DEFTYPE is invoked is completely arbitrary and unspecified, then it is
> ok with caching. I would say that this is the spirit of the
> specification, though.

I'm revisiting the code in SBCL, and what I'd like is that derived type
specifiers with an &environment parameter are not cached. I think that's
the spirit of the specification because otherwise the existence of that
parameter in deftype lambda lists would be pretty moot. And it's
something you can easily discriminate on.

  -T.