[cmucl-help] Re: When slots :type are used
On Tue, Jan 13, 2009 at 10:47 AM, Didier Verna wrote: > Well, SBCL at least does, with (speed 0) and (safety 3). FWIW, the logic used by SBCL is that of safe code: runtime checks are guaranteed when both the class definition and the slot access are in SAFETY 3 code. Other policy settings don't play a role. Cheers, -- Nikodemus
[cmucl-help] Re: When slots :type are used
Madhu wrote: > * Raymond Toy : > Wrote on Wed, 10 Dec 2008 11:21:08 -0500: > > |> "dvl" == Didier Verna writes: > > | dvl> But doing so by making (setf (slot-value))'s behavior > | dvl> different (shall I say inconsistent?) depending on the > | dvl> context feels somewhat weird to > | > | Raymond> Yes, I think it's inconsistent. > | > | dvl> me. I guess you concern is performance here; but then, we can > | dvl> play with the optimize declaration. > > The other concern was compatibility with other lisps which do not signal > an error when the type declaration is wrong. Well, SBCL at least does, with (speed 0) and (safety 3). > This particular typecheck is not mandated by any spec, and lisps tend > to let it pass. Yup. ACL doesn't perform any kind of typechecking whatsoever. > | Perhaps not the best solution, but I have made an internal change so > | that pcl::*use-slot-type-p* will be honored (at runtime). Hence, > | type checking will be done accordingly. > > Thanks, I have no problems setting pcl::*use-slot-types-p* when > compiling code with incorrect typespecs but thinking out aloud [on > behalf of the devil] perhaps the default behaviour should be a warning Why would you prefer it to be a warning [on behalf of the angel ;-)] ? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
[cmucl-help] Re: When slots :type are used
* Raymond Toy : Wrote on Wed, 10 Dec 2008 11:21:08 -0500: |> "dvl" == Didier Verna writes: | dvl> But doing so by making (setf (slot-value))'s behavior | dvl> different (shall I say inconsistent?) depending on the | dvl> context feels somewhat weird to | | Raymond> Yes, I think it's inconsistent. | | dvl> me. I guess you concern is performance here; but then, we can | dvl> play with the optimize declaration. The other concern was compatibility with other lisps which do not signal an error when the type declaration is wrong. This particular typecheck is not mandated by any spec, and lisps tend to let it pass. | Perhaps not the best solution, but I have made an internal change so | that pcl::*use-slot-type-p* will be honored (at runtime). Hence, type | checking will be done accordingly. Thanks, I have no problems setting pcl::*use-slot-types-p* when compiling code with incorrect typespecs but thinking out aloud [on behalf of the devil] perhaps the default behaviour should be a warning -- Madhu Crosspost & Followup-To: nntp+news.gmane.org:gmane.lisp.cmucl.devel may be incorrectly set by my newsreader
[cmucl-help] Re: When slots :type are used
> "Raymond" == Raymond Toy <[EMAIL PROTECTED]> writes: > "dvl" == Didier Verna <[EMAIL PROTECTED]> writes: dvl> But doing so by making (setf (slot-value))'s behavior different (shall dvl> I say inconsistent?) depending on the context feels somewhat weird to Raymond> Yes, I think it's inconsistent. dvl> me. I guess you concern is performance here; but then, we can play with dvl> the optimize declaration. Raymond> Unfortunately, that doesn't help. The function that I changed is Raymond> called from the (setf slot-value) method, so any optimize declarations Raymond> won't change that. Perhaps not the best solution, but I have made an internal change so that pcl::*use-slot-type-p* will be honored (at runtime). Hence, type checking will be done accordingly. Ray
[cmucl-help] Re: When slots :type are used
|From: Raymond Toy <[EMAIL PROTECTED]> |Date: Thu, 04 Dec 2008 09:27:29 -0500 | |(defclass foo2 () | ((slot :type single-float :initform 1.2f0) | (slot2))) | |(defclass bar () | ((a :type fixnum :initform 0))) | |(defparameter *o* (make-instance 'foo2)) | |(defmethod setslot ((obj bar) val) | (setf (slot-value *o* 'slot) val) | (setf (slot-value obj 'a) val)) | | |Compile up the previous code. Then (setf (slot-value (make-instance |'foo2) 'slot) "string") signals an error. | |But (setslot (make-instance 'bar) 99) doesn't signal an error even |though we're assigning a fixnum to a slot of type single-float. |Hence, the change I made doesn't apply to slot-value in methods. (I |guess slot-value in methods takes a different path.) Yes, actually I believe this was also the motivating reason for making this change in the first place: (see didier's original message) viz. that setf slot-value was not triggering an error while setslot was. , So it was clear there were two different code paths, and you added an explicit check-type to one of them. |I don't know PCL well enough to know exactly how methods get called or |which ones are run. -- Regards Madhu
[cmucl-help] Re: When slots :type are used
> "Madhu" == Madhu <[EMAIL PROTECTED]> writes: Madhu> * Raymond Toy <[EMAIL PROTECTED]> : Madhu> Wrote on Tue, 02 Dec 2008 20:23:45 -0500: Madhu> |> It may also have been a tradeoff, [since it is not being done in the Madhu> |> compiler] and you want to have at least one path available to the Madhu> |> programmer to set a slot value that avoids overhead of a type check. Madhu> | Madhu> | I've implemented this already. It basically does a check-type for (setf Madhu> | slot-value) for standard objects. This doesn't change what happens when Madhu> | slot-value is used in a method. Madhu> I'm not sure this is a good idea. (But I have not measured the cost of Madhu> the change, NOTE: I'm not objecting to the change) I did a quick test with: (defclass foo2 () ((slot :type single-float :initform 1.2f0) (slot2))) (defclass bar () ((a :type fixnum :initform 0))) (defparameter *o* (make-instance 'foo2)) (defmethod setslot ((obj bar) val) (setf (slot-value *o* 'slot) val) (setf (slot-value obj 'a) val)) Compile up the previous code. Then (setf (slot-value (make-instance 'foo2) 'slot) "string") signals an error. But (setslot (make-instance 'bar) 99) doesn't signal an error even though we're assigning a fixnum to a slot of type single-float. Hence, the change I made doesn't apply to slot-value in methods. (I guess slot-value in methods takes a different path.) I don't know PCL well enough to know exactly how methods get called or which ones are run. Ray
[cmucl-help] Re: When slots :type are used
> "dvl" == Didier Verna <[EMAIL PROTECTED]> writes: dvl> But doing so by making (setf (slot-value))'s behavior different (shall dvl> I say inconsistent?) depending on the context feels somewhat weird to Yes, I think it's inconsistent. dvl> me. I guess you concern is performance here; but then, we can play with dvl> the optimize declaration. Unfortunately, that doesn't help. The function that I changed is called from the (setf slot-value) method, so any optimize declarations won't change that. (But see other message in this thread.) Ray
[cmucl-help] Re: When slots :type are used
Madhu <[EMAIL PROTECTED]> wrote: > * Raymond Toy <[EMAIL PROTECTED]> : > Wrote on Wed, 26 Nov 2008 17:08:56 -0500: > > | Didier Verna wrote: > > |> Section "2.23.2 Slot Type Checking" continues to puzzle me, > |> especially the fact that you have to be within *methods* for the > |> :type slot option to be taken in consideration when writing something > > Which section is this? I couldnt grep for this in the spec or mopspec. In the CMU-CL user manual, not the HyperSpec. I should have been more specific ;-) > | Most likely because no got around to doing it. Plus the most > | interesting/most common case is probably in a method. > | > | I'll see what I can do, but I know very little about the pcl > | implementation. > > It may also have been a tradeoff, [since it is not being done in the > compiler] and you want to have at least one path available to the > programmer to set a slot value that avoids overhead of a type check. But doing so by making (setf (slot-value))'s behavior different (shall I say inconsistent?) depending on the context feels somewhat weird to me. I guess you concern is performance here; but then, we can play with the optimize declaration. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
[cmucl-help] Re: When slots :type are used
* Raymond Toy <[EMAIL PROTECTED]> : Wrote on Tue, 02 Dec 2008 20:23:45 -0500: |> It may also have been a tradeoff, [since it is not being done in the |> compiler] and you want to have at least one path available to the |> programmer to set a slot value that avoids overhead of a type check. | | I've implemented this already. It basically does a check-type for (setf | slot-value) for standard objects. This doesn't change what happens when | slot-value is used in a method. I'm not sure this is a good idea. (But I have not measured the cost of the change, NOTE: I'm not objecting to the change) | I don't follow why there should be a path that avoids the type check | overhead. Performance. If this is implemented in the compiler I can probably set optimize levels to avoid an unnecessary runtime check-type from being inserted. Implementing it the way you impacts all calls regardless of whether slot has a type declared or *use-slot-types-p* is nil --- even though the functional result is the same. Needless to say those applications which do a a large number of (common) setf slot-values through this code path will be put through the few extra instructions. :) | I'm not sure, but it wouldn't surprise me some compiled methods behave | strangely if the slot doesn't have the specified type. (Untested, | though.) -- Madhu
[cmucl-help] Re: When slots :type are used
Madhu wrote: > * Raymond Toy <[EMAIL PROTECTED]> : > Wrote on Wed, 26 Nov 2008 17:08:56 -0500: > > | Didier Verna wrote: > > |> Section "2.23.2 Slot Type Checking" continues to puzzle me, > |> especially the fact that you have to be within *methods* for the > |> :type slot option to be taken in consideration when writing something > > Which section is this? I couldnt grep for this in the spec or mopspec. > Yeah, this confused me too. Sec 2.23.2 is referring to the CMUCL User's Manual. > > |> to a slot. For instance, with: > |> > |> (defclass foo () > |> ((a :type fixnum))) > |> > |> (defvar *object* (make-instance 'foo)) > |> (setf (slot-value *object* 'a) 3.5);; this works like a charm > |> > |> > |> but: > |> > |> (defmethod setslot ((foo foo) val) > |> (setf (slot-value foo 'a) val)) > |> > |> (setslot *object* 3.5) ;; triggers a type error > |> > |> > |> Can somebody provide a rationale for this ?? > |> > |> > |> > | Most likely because no got around to doing it. Plus the most > | interesting/most common case is probably in a method. > | > | I'll see what I can do, but I know very little about the pcl > | implementation. > > It may also have been a tradeoff, [since it is not being done in the > compiler] and you want to have at least one path available to the > programmer to set a slot value that avoids overhead of a type check. I've implemented this already. It basically does a check-type for (setf slot-value) for standard objects. This doesn't change what happens when slot-value is used in a method. I don't follow why there should be a path that avoids the type check overhead. I'm not sure, but it wouldn't surprise me some compiled methods behave strangely if the slot doesn't have the specified type. (Untested, though.) Ray
[cmucl-help] Re: When slots :type are used
* Raymond Toy <[EMAIL PROTECTED]> : Wrote on Wed, 26 Nov 2008 17:08:56 -0500: | Didier Verna wrote: |> Section "2.23.2 Slot Type Checking" continues to puzzle me, |> especially the fact that you have to be within *methods* for the |> :type slot option to be taken in consideration when writing something Which section is this? I couldnt grep for this in the spec or mopspec. |> to a slot. For instance, with: |> |> (defclass foo () |> ((a :type fixnum))) |> |> (defvar *object* (make-instance 'foo)) |> (setf (slot-value *object* 'a) 3.5);; this works like a charm |> |> |> but: |> |> (defmethod setslot ((foo foo) val) |> (setf (slot-value foo 'a) val)) |> |> (setslot *object* 3.5) ;; triggers a type error |> |> |> Can somebody provide a rationale for this ?? |> |> |> | Most likely because no got around to doing it. Plus the most | interesting/most common case is probably in a method. | | I'll see what I can do, but I know very little about the pcl | implementation. It may also have been a tradeoff, [since it is not being done in the compiler] and you want to have at least one path available to the programmer to set a slot value that avoids overhead of a type check. -- Madhu
[cmucl-help] Re: When slots :type are used
> "dvl" == Didier Verna <[EMAIL PROTECTED]> writes: dvl>Hi again, dvl> Section "2.23.2 Slot Type Checking" continues to puzzle me, especially dvl> the fact that you have to be within *methods* for the :type slot option dvl> to be taken in consideration when writing something to a slot. For dvl> instance, with: dvl> (defclass foo () dvl> ((a :type fixnum))) dvl> (defvar *object* (make-instance 'foo)) dvl> (setf (slot-value *object* 'a) 3.5);; this works like a charm I think I have this fixed now: (defclass foo () ((a :type fixnum))) (defclass bar () ((a :type fixnum :initform 0))) (make-instance 'foo) -> signals error because a isn't initialized with a fixnum (defvar *object* (make-instance 'bar)) (setf (slot-value *object* 'a) 3.5) -> signals error I will need to run some tests and stuff, but if all goes well, it will be included soon (but probably not in time for the Dec snapshot). Ray
[cmucl-help] Re: When slots :type are used
> "Nicolas" == Nicolas Neuss <[EMAIL PROTECTED]> writes: Nicolas> Raymond Toy <[EMAIL PROTECTED]> writes: >>> (defmethod setslot ((foo foo) val) >>> (setf (slot-value foo 'a) val)) >>> >>> (setslot *object* 3.5) ;; triggers a type error >>> >>> Can somebody provide a rationale for this ?? >>> >> Most likely because no got around to doing it. Plus the most >> interesting/most common case is probably in a method. Nicolas> Wasn't this introduced by Gerd Moellmann's PCL improvements? I remember Yes, Gerd made these changes. Ray
[cmucl-help] Re: When slots :type are used
Raymond Toy <[EMAIL PROTECTED]> writes: >> (defmethod setslot ((foo foo) val) >> (setf (slot-value foo 'a) val)) >> >> (setslot *object* 3.5) ;; triggers a type error >> >> Can somebody provide a rationale for this ?? >> > Most likely because no got around to doing it. Plus the most > interesting/most common case is probably in a method. Wasn't this introduced by Gerd Moellmann's PCL improvements? I remember that one of the characteristics of that change was that slot access inside a defmethod was treated specially and compiled to much faster code. (In an ideal world, this would have been an improvement of the compiler, but this was probably too hard to do.) Nicolas
[cmucl-help] Re: When slots :type are used
Didier Verna wrote: >Hi again, > > Section "2.23.2 Slot Type Checking" continues to puzzle me, especially > the fact that you have to be within *methods* for the :type slot option > to be taken in consideration when writing something to a slot. For > instance, with: > > (defclass foo () > ((a :type fixnum))) > > (defvar *object* (make-instance 'foo)) > (setf (slot-value *object* 'a) 3.5);; this works like a charm > > > but: > > (defmethod setslot ((foo foo) val) > (setf (slot-value foo 'a) val)) > > (setslot *object* 3.5) ;; triggers a type error > > > Can somebody provide a rationale for this ?? > > > Most likely because no got around to doing it. Plus the most interesting/most common case is probably in a method. I'll see what I can do, but I know very little about the pcl implementation. Ray
