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

Gabriel Dos Reis gdr at integrable-solutions.net
Sun Nov 29 18:20:59 UTC 2009


On Sun, Nov 29, 2009 at 12:10 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> On Sun, Nov 29, 2009 at 7:00 PM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>> On Sun, Nov 29, 2009 at 10:29 AM, Juan Jose Garcia-Ripoll
>> <juanjose.garciaripoll at googlemail.com> wrote:
>>> How can ECL decide to cache a DEFTYPE form? I mean, the following is
>>> utterly absurd, but it may well happen:
>>>
>>> (deftype foo () (declare (special *foo-expansion*)) *foo-expansion*)
>>
>> Could not ECL keep a cache of a conservatively approximated side-effect
>> free deftypes?  For example, any reference to a special variable or non
>> constant could qualify for non-side-effect free.
>>
>> Even the general thing could be very complicated, there are some
>> low-hanging fruits to have...
>
> The problem is more general: right now we do not have an
> infrastructure to tell functions that have side effects from functions
> that do not. Even SBCL has this problem right now: it caches without
> caring much about the type itself
> * (defvar *foo-expansion* 'integer)
>
> *FOO-EXPANSION*
> * (deftype foo () *foo-expansion*)
> FOO
> * (subtypep 'fixnum 'foo)
> T
> T
> * (setf *foo-expansion* 'string)
> STRING
> * (subtypep 'fixnum 'foo)
> T
> T

Well, I'm not sure how frequent are those exotic cases, and why
they should weight more than the common cases.

But I also appreciate that you want to get everything right.
However, I suspect ECL and cache 'simple' enough deftype, no?
I mean those constructed from the standard specifiers and involving
only parameters and know standard constants.

-- Gaby




More information about the ecl-devel mailing list