headers
Raymond Toy | 1 Dec 2008 16:50
Picon
Favicon

Re: When slots :type are used

>>>>> "Nicolas" == Nicolas Neuss <neuss <at> math.uni-karlsruhe.de> writes:

    Nicolas> Raymond Toy <toy.raymond <at> gmail.com> 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
Permalink | Reply | 0 comments |
headers
Raymond Toy | 1 Dec 2008 19:15
Picon
Favicon

Re: When slots :type are used

>>>>> "dvl" == Didier Verna <didier.verna <at> gmail.com> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Madhu | 3 Dec 2008 01:28

Re: When slots :type are used


* Raymond Toy <492DC8F8.1070004 <at> gmail.com> :
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 ??
(Continue reading)

Permalink | Reply | 7 comments |
headers
Raymond Toy | 3 Dec 2008 02:23
Picon

Re: When slots :type are used

Madhu wrote:
> * Raymond Toy <492DC8F8.1070004 <at> gmail.com> :
> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Madhu | 3 Dec 2008 03:24

Re: When slots :type are used

* Raymond Toy <4935DFA1.8000503 <at> gmail.com> :
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.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Didier Verna | 3 Dec 2008 08:29
X-Face
Face
Picon
Gravatar

Re: When slots :type are used

Madhu <enometh <at> meer.net> wrote:

> * Raymond Toy <492DC8F8.1070004 <at> gmail.com> :
> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Raymond Toy | 4 Dec 2008 15:22
Picon
Favicon

Re: When slots :type are used

>>>>> "dvl" == Didier Verna <didier.verna <at> gmail.com> 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
Permalink | Reply | 1 comment |
headers
Raymond Toy | 4 Dec 2008 15:27
Picon
Favicon

Re: When slots :type are used

>>>>> "Madhu" == Madhu  <enometh <at> meer.net> writes:

    Madhu> * Raymond Toy <4935DFA1.8000503 <at> gmail.com> :
    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))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Madhu | 5 Dec 2008 01:20
Picon

Re: When slots :type are used


  |From: Raymond Toy <raymond.toy <at> ericsson.com>
  |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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Didier Verna | 8 Dec 2008 17:06
X-Face
Face
Picon
Gravatar

More fun with slot type checking


       Hi !

I'm continuing my experiments with slot type checking, on structures
this time. Consider this:

(defstruct mystruct (slot "foo" :type single-float))

Regardless of the optimize settings, I will get an error every time I
try to create a mystruct object; so it seems that CMU-CL performs
structure slot type checking all the time.

However, in the following case:

(defstruct mystruct (slot "foo" :type fixnum))

I *never* get an error. I find this a bit inconsistent. Here's a wild
guess that might explain this behavior: if it goes like in SBCL, fixnums
are represented in structs in raw form, with their tag, so the
consequence is that there is no need for any type checking[1] to
guarantee that the slot can be accessed (read and written) properly,
even with something else than a fixnum.

That would be different with single-float's if they use a specialized
representation in structs, in which case you have to be more cautious
when accessing the slot.

Comments ?

Footnotes:
(Continue reading)

Permalink | Reply | 2 comments |

Gmane