Re: How to handle these warnings?

[Bruno H. <br...@cl...>]

[from clisp-list to clisp-devel]
Sam,

I mostly agree.

> >   1) What should the syntax for this declaration look like?
> >      (Extension of DEFGENERIC? Separate declaration macro? ...)
> 
> (defgeneric gf (...)
>   (declare (dynamically-modifiable))
>   ...)

Agree. The user will have to write

  (defgeneric gf (...)
    (declare #+clisp (dynamically-modifiable))
    ...)

because other implementations would choke on this declaration specifier ([1]
says "other declaration specifiers are not permitted").

> >   2) Where should the information be stored?
> >      (In the generic-function object? On the symbol's property list? ...)
> 
> generic-function object slot $dynamically-modifiable.

Yep. Looks good. If someone redefines the GF, with a DEFGENERIC form
without (dynamically-modifiable), it will warn about dynamic modifications.

> (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
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.

In summary, I would vote for
  - the DEFGENERIC syntax,
  - store the info in a slot in the GF,
  - don't offer DECLAIM support for it,
  - the only use of clos::*dynamically-modifiable-generic-function-names*
    will be for clos-genfun2b.lisp line 856.

Bruno

[1] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defgeneric.html