POLL: about arguments of invariable type to methods

Suppose you have a generic function func (arg1 arg2). Suppose
further that in your application, the dispatch might occur on arg1, but
arg2 will always be of the same type.

How do you guys behave in that situation ? Please select one or several
options below. All choices must be properly justified.

* Option 1 (well, I do nothing special):
(defmethod func ((arg1 type1) arg2) ...)
(defmethod func ((arg1 type2) arg2) ...)
etc.

* Option 2:
(defmethod func ((arg1 type1) (arg2 theonlytype)) ...)
(defmethod func ((arg1 type2) (arg2 theonlytype)) ...)
etc.

* Option 3:
(defmethod func ((arg1 type1) arg2) (declare (type theonlytype arg2)) ...)
(defmethod func ((arg1 type2) arg2) (declare (type theonlytype arg2)) ...)
etc.

* Option 4:
It depends.

* Option 5:
/ insert whatever you like here /

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

On Fri, 22 Aug 2008 17:35:55 +0200, Didier Verna wrote:

> Suppose you have a generic function func (arg1 arg2). Suppose further
> that in your application, the dispatch might occur on arg1, but arg2
> will always be of the same type.
>
> How do you guys behave in that situation ? Please select one or several
> options below. All choices must be properly justified.

Mostly 1.

Justification: This is the simplest solution, and I see no reason do to
otherwise (but please enlighten me if you feel that is necessary :-)
What would be the benefit of 2 or 3?

Tamas

In article <mux4p5d9i5g.fsf@uzeb.lrde.epita.fr>,
Didier Verna <didier@lrde.epita.fr> wrote:

> Suppose you have a generic function func (arg1 arg2). Suppose
> further that in your application, the dispatch might occur on arg1, but
> arg2 will always be of the same type.
>
> How do you guys behave in that situation ? Please select one or several
> options below. All choices must be properly justified.
>
> * Option 1 (well, I do nothing special):
> (defmethod func ((arg1 type1) arg2) ...)
> (defmethod func ((arg1 type2) arg2) ...)
> etc.
>
> * Option 2:
> (defmethod func ((arg1 type1) (arg2 theonlytype)) ...)
> (defmethod func ((arg1 type2) (arg2 theonlytype)) ...)
> etc.
>
> * Option 3:
> (defmethod func ((arg1 type1) arg2) (declare (type theonlytype arg2)) ...)
> (defmethod func ((arg1 type2) arg2) (declare (type theonlytype arg2)) ...)
> etc.
>
> * Option 4:
> It depends.
>
> * Option 5:
> / insert whatever you like here /

If I want runtime type checking, I'm using 2. If I don't care, then 1.

--
http://lispm.dyndns.org/

Didier Verna wrote:
> Suppose you have a generic function func (arg1 arg2). Suppose
> further that in your application, the dispatch might occur on arg1, but
> arg2 will always be of the same type.
>
> How do you guys behave in that situation ? Please select one or several
> options below. All choices must be properly justified.
>
>
> * Option 5:

The thought/concern/question does not arise. This only seems like Option
#1. Conveniently, this is a non-opting option so requires no
justification. It does however implicitly require you to justify how on
earth you ever ended up thinking about such a thing and for the love of
god please don't say "performance".

Your options are:

1. Just trying to kill off the Xah thread
2. Just trying to ask a question dumber than "Does Lisp have a stutter?"
3. Other_______________________.

kenny

Rainer Joswig wrote:
> In article <mux4p5d9i5g.fsf@uzeb.lrde.epita.fr>,
> Didier Verna <didier@lrde.epita.fr> wrote:
>
>> Suppose you have a generic function func (arg1 arg2). Suppose
>> further that in your application, the dispatch might occur on arg1, but
>> arg2 will always be of the same type.
>>
>> How do you guys behave in that situation ? Please select one or several
>> options below. All choices must be properly justified.
>>
>> * Option 1 (well, I do nothing special):
>> (defmethod func ((arg1 type1) arg2) ...)
>> (defmethod func ((arg1 type2) arg2) ...)
>> etc.
>>
>> * Option 2:
>> (defmethod func ((arg1 type1) (arg2 theonlytype)) ...)
>> (defmethod func ((arg1 type2) (arg2 theonlytype)) ...)
>> etc.
>>
>> * Option 3:
>> (defmethod func ((arg1 type1) arg2) (declare (type theonlytype arg2)) ...)
>> (defmethod func ((arg1 type2) arg2) (declare (type theonlytype arg2)) ...)
>> etc.
>>
>> * Option 4:
>> It depends.
>>
>> * Option 5:
>> / insert whatever you like here /
>
> If I want runtime type checking, I'm using 2. If I don't care, then 1.

Same here. Because of the additional type check, option 2 probably
incurs a (minor) performance overhead. Therefore, most of the time, I
typically specialize as few arguments as possible, although the runtime
type check is actually a very good reason as well.

Option 3, I don't like. I think type declarations should only be used
where performance is really important, and that doesn't seem to mesh
well with generic functions.

This is a case where I think there is something missing in CLOS,
actually. The CLOS MOP has this (very badly worded) case where
slot-value-using-class shouldn't be specialized on its second argument.
There is an option missing in the defgeneric form which allows you to
announce this. For example, :argument-precedence-order could be allowed
to declare a subset of the required arguments, which would mean that
unmentioned parameters must not be specialized in methods for that
generic function. I think that would be a useful extension.



Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

In article <6h895lFjrri1U1@mid.individual.net>,
Pascal Costanza <pc@p-cos.net> wrote:

> Rainer Joswig wrote:
> > In article <mux4p5d9i5g.fsf@uzeb.lrde.epita.fr>,
> > Didier Verna <didier@lrde.epita.fr> wrote:
> >
> >> Suppose you have a generic function func (arg1 arg2). Suppose
> >> further that in your application, the dispatch might occur on arg1, but
> >> arg2 will always be of the same type.
> >>
> >> How do you guys behave in that situation ? Please select one or several
> >> options below. All choices must be properly justified.
> >>
> >> * Option 1 (well, I do nothing special):
> >> (defmethod func ((arg1 type1) arg2) ...)
> >> (defmethod func ((arg1 type2) arg2) ...)
> >> etc.
> >>
> >> * Option 2:
> >> (defmethod func ((arg1 type1) (arg2 theonlytype)) ...)
> >> (defmethod func ((arg1 type2) (arg2 theonlytype)) ...)
> >> etc.
> >>
> >> * Option 3:
> >> (defmethod func ((arg1 type1) arg2) (declare (type theonlytype arg2)) ...)
> >> (defmethod func ((arg1 type2) arg2) (declare (type theonlytype arg2)) ...)
> >> etc.
> >>
> >> * Option 4:
> >> It depends.
> >>
> >> * Option 5:
> >> / insert whatever you like here /
> >
> > If I want runtime type checking, I'm using 2. If I don't care, then 1.
>
> Same here. Because of the additional type check, option 2 probably
> incurs a (minor) performance overhead. Therefore, most of the time, I
> typically specialize as few arguments as possible, although the runtime
> type check is actually a very good reason as well.

It's also kind of a 'gate'. Within the method the value
of the parameter is of the class described (unless there
is some assignment or some other magic). I think the compiler
can take advantage of it.

It also helps during debugging. If one always passes objects
via normal parameters (without type check / method dispatch), then a runtime
type error may happen deep in the program (with a long stack backtrace).
If the classes are mentioned in the parameter list, the right method
will be called or a missing method will be reported early.

> Option 3, I don't like. I think type declarations should only be used
> where performance is really important, and that doesn't seem to mesh
> well with generic functions.
>
> This is a case where I think there is something missing in CLOS,
> actually. The CLOS MOP has this (very badly worded) case where
> slot-value-using-class shouldn't be specialized on its second argument.
> There is an option missing in the defgeneric form which allows you to
> announce this. For example, :argument-precedence-order could be allowed
> to declare a subset of the required arguments, which would mean that
> unmentioned parameters must not be specialized in methods for that
> generic function. I think that would be a useful extension.
>
>
>
> Pascal

--
http://lispm.dyndns.org/

Rainer Joswig wrote:
> In article <6h895lFjrri1U1@mid.individual.net>,
> Pascal Costanza <pc@p-cos.net> wrote:
>
>> Rainer Joswig wrote:
>>> In article <mux4p5d9i5g.fsf@uzeb.lrde.epita.fr>,
>>> Didier Verna <didier@lrde.epita.fr> wrote:
>>>
>>>> Suppose you have a generic function func (arg1 arg2). Suppose
>>>> further that in your application, the dispatch might occur on arg1, but
>>>> arg2 will always be of the same type.
>>>>
>>>> How do you guys behave in that situation ? Please select one or several
>>>> options below. All choices must be properly justified.
>>>>
>>>> * Option 1 (well, I do nothing special):
>>>> (defmethod func ((arg1 type1) arg2) ...)
>>>> (defmethod func ((arg1 type2) arg2) ...)
>>>> etc.
>>>>
>>>> * Option 2:
>>>> (defmethod func ((arg1 type1) (arg2 theonlytype)) ...)
>>>> (defmethod func ((arg1 type2) (arg2 theonlytype)) ...)
>>>> etc.
>>>>
>>>> * Option 3:
>>>> (defmethod func ((arg1 type1) arg2) (declare (type theonlytype arg2)) ...)
>>>> (defmethod func ((arg1 type2) arg2) (declare (type theonlytype arg2)) ...)
>>>> etc.
>>>>
>>>> * Option 4:
>>>> It depends.
>>>>
>>>> * Option 5:
>>>> / insert whatever you like here /
>>> If I want runtime type checking, I'm using 2. If I don't care, then 1.
>> Same here. Because of the additional type check, option 2 probably
>> incurs a (minor) performance overhead. Therefore, most of the time, I
>> typically specialize as few arguments as possible, although the runtime
>> type check is actually a very good reason as well.
>
> It's also kind of a 'gate'. Within the method the value
> of the parameter is of the class described (unless there
> is some assignment or some other magic). I think the compiler
> can take advantage of it.
>
> It also helps during debugging. If one always passes objects
> via normal parameters (without type check / method dispatch), then a runtime
> type error may happen deep in the program (with a long stack backtrace).
> If the classes are mentioned in the parameter list, the right method
> will be called or a missing method will be reported early.

True, that's a very good argument for option 2.


Pascal


--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Rainer Joswig <joswig@lisp.de> wrote:

> It's also kind of a 'gate'. Within the method the value of the
> parameter is of the class described (unless there is some assignment
> or some other magic). I think the compiler can take advantage of it.

But just like with a declaration, right ?

> It also helps during debugging. If one always passes objects via
> normal parameters (without type check / method dispatch), then a
> runtime type error may happen deep in the program (with a long stack
> backtrace). If the classes are mentioned in the parameter list, the
> right method will be called or a missing method will be reported
> early.

Same here: but just like with a declaration, right ?

I'm often oscillating between writing things the simple/shortest way
(without type decl) because declarations clutter the code and are a
nuisance to readability (and sometimes to maintainability as well, when
performance is not an issue), and telling the compiler everything I
know, exactly for the reason you mention above. But there, I would
rather use type decls.

So I guess the real question is the differences there are in using
either type decls or specializers when you compile with different
debug/optimize qualities.

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

Didier Verna <didier@lrde.epita.fr> writes:

> Rainer Joswig <joswig@lisp.de> wrote:
>
> > It's also kind of a 'gate'. Within the method the value of the
> > parameter is of the class described (unless there is some assignment
> > or some other magic). I think the compiler can take advantage of it.
>
> But just like with a declaration, right ?

No, like CHECK-TYPE.

-T.

In article <muxwsi899gt.fsf@uzeb.lrde.epita.fr>,
Didier Verna <didier@lrde.epita.fr> wrote:

> Rainer Joswig <joswig@lisp.de> wrote:
>
> > It's also kind of a 'gate'. Within the method the value of the
> > parameter is of the class described (unless there is some assignment
> > or some other magic). I think the compiler can take advantage of it.
>
> But just like with a declaration, right ?
>
> > It also helps during debugging. If one always passes objects via
> > normal parameters (without type check / method dispatch), then a
> > runtime type error may happen deep in the program (with a long stack
> > backtrace). If the classes are mentioned in the parameter list, the
> > right method will be called or a missing method will be reported
> > early.
>
> Same here: but just like with a declaration, right ?

No.

* declarations can be safely ignored by a Common Lisp implementation.
ANSI Common Lisp does not require an implementation to do
anything with (declare (type ...)).

* ANSI CL does not really say what a compiler has to do if
it looks at these declarations.

* A compiler may just use the declarations to create
specialized code - not more.

* Doing runtime type checks based on type declarations
is not that usual. SBCL will do it. Many others won't.

It would be more comparable to a use of CHECK-TYPE.

>
> I'm often oscillating between writing things the simple/shortest way
> (without type decl) because declarations clutter the code and are a
> nuisance to readability (and sometimes to maintainability as well, when
> performance is not an issue), and telling the compiler everything I
> know, exactly for the reason you mention above. But there, I would
> rather use type decls.

Type declarations are somehow internal to functions.

Using method parameter lists to describe the expected
classes of arguments is visible from the outside.
One can just check the available methods or print a
method. Based on generic functions there is the
idea of a 'protocol'.


CL-USER 6 > (defun foo (a) (declare (fixnum a)) a)
FOO

CL-USER 7 > (compile *)
FOO
NIL
NIL

CL-USER 8 > #'foo
#<Function FOO 4060010A2C>

You see only a function.




CL-USER 9 > (defmethod bar ((a fixnum)) a)
#<STANDARD-METHOD BAR NIL (FIXNUM) 4020005A6B>


The method shows for what classes it is defined.

>
> So I guess the real question is the differences there are in using
> either type decls or specializers when you compile with different
> debug/optimize qualities.

--
http://lispm.dyndns.org/