From: <gd...@re...> - 2000-05-24 18:27:35
|
clocc.lisp does a #+cmu(pushnew 'compile pcl::*defmethod-times*) but this causes an error with CMUCL when compiling a file that contains ------ (defstruct foo bar) (defmethod make-load-form ((obj foo) &optional env) (make-load-form-saving-slots obj :environment env)) ------ Byte Compiling Top-Level Form: Converted MAKE-FOO. Compiling DEFSTRUCT FOO: Error in KERNEL:%COERCE-TO-FUNCTION: the function FOO-BAR is undefined. Restarts: 0: [ABORT] Return to Top-Level. ------ It also causes warnings to be given about undefined variables when using constructions like (let (foo) (defmethod (...) foo occurs here)) I'm not sure if pcl::*defgeneric-times* or pcl::*defclass-times* are OK, I have a vague memory of having problems redefining generic functions when they contained 'compile. Is it necessary to add 'compile to these symbols? -- Gareth Jones |
From: Sam S. <sd...@gn...> - 2000-05-24 20:09:29
|
>>>> In message <m2b...@gd...> >>>> On the subject of "pcl::*defmethod-times*" >>>> Sent on Wed May 24 13:22:56 EDT 2000 >>>> Honorable Gareth Jones <gd...@re...> writes: >> clocc.lisp does a #+cmu(pushnew 'compile pcl::*defmethod-times*) but >> this causes an error with CMUCL when compiling a file that contains >> >> ------ >> (defstruct foo >> bar) look at any files in cllib: you will see that all defstructs are surrounded by an `eval-when': that's because of CMUCL's strict interpretation of the standard. just surround your defstruct with eval-when and you will be okay. >> (defmethod make-load-form ((obj foo) &optional env) >> (make-load-form-saving-slots obj :environment env)) >> ------ >> >> I'm not sure if pcl::*defgeneric-times* or pcl::*defclass-times* are >> OK, I have a vague memory of having problems redefining generic >> functions when they contained 'compile. Is it necessary to add >> 'compile to these symbols? this allowed me to avoid some `eval-when'. this is a trade-off: unless every defstruct, defclass and defgeneric lives in it's own file, CMUCL will force some `eval-when' upon you. -- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. MS: Brain off-line, please wait. |
From: <gd...@re...> - 2000-05-26 10:34:31
|
Sam Steingold <sd...@gn...> writes: >>> I'm not sure if pcl::*defgeneric-times* or pcl::*defclass-times* are >>> OK, I have a vague memory of having problems redefining generic >>> functions when they contained 'compile. Is it necessary to add >>> 'compile to these symbols? > > this allowed me to avoid some `eval-when'. > this is a trade-off: unless every defstruct, defclass and defgeneric > lives in it's own file, CMUCL will force some `eval-when' upon you. I understand that *defclass-times* and *defgeneric-times* can avoid some spurious warnings, but I don't see what use adding 'compile to *defmethod-times* is. From my reading of the Hyperspec (specifically, the entry for defmethod and the CLOS-MACRO-COMPILATION issue writeup) and the pcl source code, it seems that adding 'compile causes CMUCL to violate the ANSI specification by adding the method to the generic function at compile time. -- Gareth Jones |
From: Sam S. <sd...@gn...> - 2000-05-26 16:14:43
|
>>>> In message <m2a...@gd...> >>>> On the subject of "Re: pcl::*defmethod-times*" >>>> Sent on Fri May 26 05:46:43 EDT 2000 >>>> Honorable Gareth Jones <gd...@re...> writes: >> >> I understand that *defclass-times* and *defgeneric-times* can avoid >> some spurious warnings, but I don't see what use adding 'compile to >> *defmethod-times* is. From my reading of the Hyperspec >> (specifically, the entry for defmethod and the >> CLOS-MACRO-COMPILATION issue writeup) and the pcl source code, it >> seems that adding 'compile causes CMUCL to violate the ANSI >> specification by adding the method to the generic function at >> compile time. without 'compile, I get an error compiling ---- (defgeneric foo ....) (defmethod foo ....) ---- -- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. A year spent in artificial intelligence is enough to make one believe in God. |
From: Marco A. <ma...@cs...> - 2000-05-27 17:32:54
|
> Reply-To: sd...@gn... > Mail-Copies-To: never > From: Sam Steingold <sd...@gn...> > Date: 26 May 2000 12:11:02 -0400 > Sender: clo...@li... > X-Mailman-Version: 1.1 > Precedence: bulk > List-Id: <clocc-list.lists.sourceforge.net> > X-BeenThere: clo...@li... > Content-Type: text > Content-Length: 1236 > > >>>> In message <m2a...@gd...> > >>>> On the subject of "Re: pcl::*defmethod-times*" > >>>> Sent on Fri May 26 05:46:43 EDT 2000 > >>>> Honorable Gareth Jones <gd...@re...> writes: > >> > >> I understand that *defclass-times* and *defgeneric-times* can avoid > >> some spurious warnings, but I don't see what use adding 'compile to > >> *defmethod-times* is. From my reading of the Hyperspec > >> (specifically, the entry for defmethod and the > >> CLOS-MACRO-COMPILATION issue writeup) and the pcl source code, it > >> seems that adding 'compile causes CMUCL to violate the ANSI > >> specification by adding the method to the generic function at > >> compile time. > > without 'compile, I get an error compiling > > ---- > (defgeneric foo ....) > > (defmethod foo ....) > ---- Yep. Same here. Marco -- Marco Antoniotti ============================================================= NYU CAT Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA |
From: <gd...@re...> - 2000-05-28 09:59:29
|
Sam Steingold <sd...@gn...> writes: >>>>> In message <m2a...@gd...> >>>>> On the subject of "Re: pcl::*defmethod-times*" >>>>> Sent on Fri May 26 05:46:43 EDT 2000 >>>>> Honorable Gareth Jones <gd...@re...> writes: >>> >>> I understand that *defclass-times* and *defgeneric-times* can avoid >>> some spurious warnings, but I don't see what use adding 'compile to >>> *defmethod-times* is. From my reading of the Hyperspec >>> (specifically, the entry for defmethod and the >>> CLOS-MACRO-COMPILATION issue writeup) and the pcl source code, it >>> seems that adding 'compile causes CMUCL to violate the ANSI >>> specification by adding the method to the generic function at >>> compile time. > > without 'compile, I get an error compiling > > ---- > (defgeneric foo ....) > > (defmethod foo ....) > ---- Without 'compile on what? I get a warning if *defgeneric-times* doesn't have 'compile, but no error. Omitting 'compile from *defmethod-times* doesn't even produce a warning. Omitting 'compile from all three produces undefined type (from defclass) and undefined function (from defgeneric) warnings at compile time, but loads without problems. I am using ----- (defclass foo () ()) (defgeneric baz (obj env)) (defmethod baz ((obj foo) env) (print obj)) ----- I still maintain that adding 'compile to *defmethod-times* violates the ANSI standard. This is using CMUCL 2.4.19, but I don't think that the PCL code has changed recently (it's not even in the CVS module). What error do you get? -- Gareth Jones |