Re: How to handle these warnings?

Bruno,

> * Bruno Haible <[email protected]> [2017-07-19 23:00:22 +0200]:
>
>> (declaim (dynamically-modifiable gf1 gf2 gf3))
>
> I don't think this will work right: If you store this information only in
> the GF, then after redefining the GF without (dynamically-modifiable), the
> effect will be lost - which is counter-intuitive. Whereas if you store

Not necessarily.
When _redefining_ GF we can look at the old definition and carry the
slot over to the new one, unless we also see

(declare ((not dynamically-modifiable)))

in the new definition.

> this information on the property list of the symbol or in the undocumented
> variable clos::*dynamically-modifiable-generic-function-names*, the
> semantics will be too complex, i.e. too hard to understand.

Then it will not be possible to change the dynamically-modifiable status
of a GF without redefining it.
I am not sure this is a good idea.
BTW, we might want to also add

(declaim ((not dynamically-modifiable) gf1 gf2 gf3))

>   - the only use of clos::*dynamically-modifiable-generic-function-names*
>     will be for clos-genfun2b.lisp line 856.

or no! please! we can do better:

(letf (((gf-dynamically-modifiable gf) t))
  (remove-method gf old-method))

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://no2bds.org
http://thereligionofpeace.com http://think-israel.org http://memri.org
When C++ is your hammer, everything looks like a thumb.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel