I'm writing method that it's second argument could be non-sequence
(number, char, symbol). Is it
possible to put this knowledge into the dispatch, i.e. move the if
into a specializer, code as below:
I think clojure had something simigliar called multhimethods.
(defmethod shape ((x integer) y)
(assert (>= x 0))
(if (or (numberp y)
(characterp y)
(symbolp y))
(make-array x :initial-element y)))
bobi
www.linkedin.com/pub/dir/slobodan/blazeski
On Jun 1, 10:20 am, Slobodan Blazeski <·················@gmail.com>
wrote:>
> (defmethod shape ((x integer) y)
> (assert (>= x 0))
> (if (or (numberp y)
> (characterp y)
> (symbolp y))
> (make-array x :initial-element y)))
Why don't you create specific types for your needs?
(deftype positive-integer ()
`(integer 0 *))
(deftype number-character-symbol ()
`(or number character symbol))
(defmethod shape ((x positive-integer) (y number-character-
symbol) ...)
...)
You can even have more detailed specializers in method lambda lists,
which will avoid creating explicit types everytime.
Regards.
On Jun 1, 10:09 am, Volkan YAZICI <·············@gmail.com> wrote:
> On Jun 1, 10:20 am, Slobodan Blazeski <·················@gmail.com>
> wrote:>
>
> > (defmethod shape ((x integer) y)
> > (assert (>= x 0))
> > (if (or (numberp y)
> > (characterp y)
> > (symbolp y))
> > (make-array x :initial-element y)))
>
> Why don't you create specific types for your needs?
>
> (deftype positive-integer ()
> `(integer 0 *))
>
> (deftype number-character-symbol ()
> `(or number character symbol))
>
> (defmethod shape ((x positive-integer) (y number-character-
> symbol) ...)
> ...)
Looks good but it fails with:
(defmethod shape ((x positive-integer) (y number-character-
symbol)))
Error: POSITIVE-INTEGER is not the name of a class
1 (continue) Try finding the class POSITIVE-INTEGER again
2 (abort) Return to level 3.
3 Return to debug level 3.
4 Return to level 2.
5 Return to debug level 2.
6 Return to level 1.
7 Return to debug level 1.
8 Return to level 0.
9 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other
options
>
> You can even have more detailed specializers in method lambda lists,
> which will avoid creating explicit types everytime.
>
Some example would highly appreciated.
bobi
> Regards.
From: Adam Michalik
Subject: Re: How to specialize method on some formula
Date:
Message-ID: <87tz30xqq9.fsf@gmail.com>
Slobodan Blazeski <·················@gmail.com> writes:
> Looks good but it fails with:
> (defmethod shape ((x positive-integer) (y number-character-
> symbol)))
Try:
(defun shape (x y)
(declare (type positive-integer x)
(type number-character-symbol y))
'foo)
(assuming you've already defined those types)
--
Adam Michalik
vel Dodek Dodecki
<dodecki[]gmail>
On Jun 1, 11:12 am, Adam Michalik <·······@gmail.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > Looks good but it fails with:
> > (defmethod shape ((x positive-integer) (y number-character-
> > symbol)))
>
> Try:
>
> (defun shape (x y)
> (declare (type positive-integer x)
> (type number-character-symbol y))
> 'foo)
It must be a method since there is different specializations:
(defmethod shape ((x integer) y)))
(defmethod shape ((x positive-integer) (y vector)))
(defmethod shape ((x positive-integer) (y array))))
cheers
bobi
>
> (assuming you've already defined those types)
> --
> Adam Michalik
> vel Dodek Dodecki
> <dodecki[]gmail>
From: Adam Michalik
Subject: Re: How to specialize method on some formula
Date:
Message-ID: <87fxekxq7x.fsf@gmail.com>
Adam Michalik <·······@gmail.com> writes:
> Try:
>
> (defun shape (x y)
> (declare (type positive-integer x)
> (type number-character-symbol y))
> 'foo)
>
> (assuming you've already defined those types)
Ekhm, I kind of noticed that it isn't really what you wanted to do.
--
Adam Michalik
vel Dodek Dodecki
<dodecki[]gmail>
Volkan YAZICI <·············@gmail.com> writes:
> On Jun 1, 10:20��am, Slobodan Blazeski <·················@gmail.com>
> wrote:>
>
> Why don't you create specific types for your needs?
>
> (deftype positive-integer ()
> `(integer 0 *))
>
> (deftype number-character-symbol ()
> `(or number character symbol))
>
> (defmethod shape ((x positive-integer) (y number-character-
> symbol) ...)
> ...)
>
> You can even have more detailed specializers in method lambda lists,
> which will avoid creating explicit types everytime.
There are differences between classes and types.
CLOS methods dispatch only on classes and EQL specializers, not on
arbitrary types.
So this approach won't work for getting method dispatch.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Raymond Wiker
Subject: Re: How to specialize method on some formula
Date:
Message-ID: <m263ffiyq4.fsf@RAWMBP.local>
Paul Foley <···@below.invalid> (http://public.xdi.org/=pf) writes:
> Volkan YAZICI <·············@gmail.com> writes:
>
>> On Jun 1, 10:20�am, Slobodan Blazeski <·················@gmail.com>
>> wrote:>
>>> (defmethod shape ((x integer) y)
>>> � (assert (>= x 0))
>>> � (if (or (numberp y)
>>> � � � � � (characterp y)
>>> � � � � � (symbolp y))
>>> � � (make-array x :initial-element y)))
>>
>> Why don't you create specific types for your needs?
>>
>> (deftype positive-integer ()
>> `(integer 0 *))
>>
>> (deftype number-character-symbol ()
>> `(or number character symbol))
>>
>> (defmethod shape ((x positive-integer) (y number-character-
>> symbol) ...)
>> ...)
>
> Because method dispatch is based on class, not type...
Think that's incorrect:
(defmethod a ((x float)) (* x x))
(defmethod a ((x integer) (+ x x)))
(a 3)
=> 6
(a 3.0)
=> 9.0
--- not that this example proves anything, but I'm fairly certain that
method dispatch is supposed to work on more than just class instances
:-)
On 1 jun, 15:40, Raymond Wiker <····@RawMBP.local> wrote:
> Paul Foley <····@below.invalid> (http://public.xdi.org/=pf) writes:
>
>
>
> > Volkan YAZICI <·············@gmail.com> writes:
>
> >> On Jun 1, 10:20 am, Slobodan Blazeski <·················@gmail.com>
> >> wrote:>
> >>> (defmethod shape ((x integer) y)
> >>> (assert (>= x 0))
> >>> (if (or (numberp y)
> >>> (characterp y)
> >>> (symbolp y))
> >>> (make-array x :initial-element y)))
>
> >> Why don't you create specific types for your needs?
>
> >> (deftype positive-integer ()
> >> `(integer 0 *))
>
> >> (deftype number-character-symbol ()
> >> `(or number character symbol))
>
> >> (defmethod shape ((x positive-integer) (y number-character-
> >> symbol) ...)
> >> ...)
>
> > Because method dispatch is based on class, not type...
>
> Think that's incorrect:
>
> (defmethod a ((x float)) (* x x))
>
> (defmethod a ((x integer) (+ x x)))
>
> (a 3)
>
> => 6
>
> (a 3.0)
>
> => 9.0
>
> --- not that this example proves anything, but I'm fairly certain that
> method dispatch is supposed to work on more than just class instances
> :-)
Integer is a class according to ANSI:
http://www.lispworks.com/documentation/HyperSpec/Body/t_intege.htm#integer
But not all types have corresponding classes. There is another thread
discussing this, here:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/7f2f647f5a0dfed3/07edd7335b0b8ffd
Raymond Wiker <···@RawMBP.local> writes:
> Paul Foley <···@below.invalid> (http://public.xdi.org/=pf) writes:
>
> > Because method dispatch is based on class, not type...
>
> Think that's incorrect:
>
> (defmethod a ((x float)) (* x x))
>
> (defmethod a ((x integer) (+ x x)))
>
> (a 3)
>
> => 6
>
> (a 3.0)
>
> => 9.0
>
> --- not that this example proves anything, but I'm fairly certain that
> method dispatch is supposed to work on more than just class instances
> :-)
The original assertion is correct. It just happens that INTEGER and
FLOAT are classes as well as types. But not all types (are required to)
have corresponding classes. So, for example you can't write
(defmethod a ((x integer)) (+ x x))
(defmethod a ((x fixnum)) (* 5 x))
and have this work. While INTEGER must be a class, FIXNUM is not
required to be (intentionally so, since one could imagine an
implementation where there might not be any difference between FIXNUMs
and BIGNUMs, both of which are covered by the class INTEGER).
So that limits a bit your ability to define methods on literals. In
fact, there is a similar issue with respect to FLOAT versus
DOUBLE-FLOAT, SINGLE-FLOAT, etc. As another branch of this discussion
notes, some implementations may have additional classes corresponding to
literals, but using such extensions renders code less portable.
--
Thomas A. Russ, USC/Information Sciences Institute
On Jun 1, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Raymond Wiker <····@RawMBP.local> writes:
> > Paul Foley <····@below.invalid> (http://public.xdi.org/=pf) writes:
>
> > > Because method dispatch is based on class, not type...
>
> > Think that's incorrect:
>
> > (defmethod a ((x float)) (* x x))
>
> > (defmethod a ((x integer) (+ x x)))
>
> > (a 3)
>
> > => 6
>
> > (a 3.0)
>
> > => 9.0
>
> > --- not that this example proves anything, but I'm fairly certain that
> > method dispatch is supposed to work on more than just class instances
> > :-)
>
> The original assertion is correct. It just happens that INTEGER and
> FLOAT are classes as well as types. But not all types (are required to)
> have corresponding classes.
So far, so good.
> So, for example you can't write
>
> (defmethod a ((x integer)) (+ x x))
> (defmethod a ((x fixnum)) (* 5 x))
>
> and have this work.
Not true. It is implementation whether this works or not. The
question is whether the implementation has provided a class for the
integer type fixnum. For example, in Allegro CL (this one's 32 bit):
CL-USER(1): (defmethod a ((x integer)) (+ x x))
#<STANDARD-METHOD A (INTEGER)>
CL-USER(2): (defmethod a ((x fixnum)) (* 5 x))
#<STANDARD-METHOD A (FIXNUM)>
CL-USER(3): most-positive-fixnum
536870911
CL-USER(4): (a most-positive-fixnum)
2684354555
CL-USER(5): (a (1+ most-positive-fixnum))
1073741824
CL-USER(6):
While INTEGER must be a class, FIXNUM is not
> required to be (intentionally so, since one could imagine an
> implementation where there might not be any difference between FIXNUMs
> and BIGNUMs, both of which are covered by the class INTEGER).
Um, no. If you look at the definition of the integer type (or version
is here:http://www.franz.com/support/documentation/8.1/ansicl/dictentr/
integer.htm) you'll see that fixnum and bignum form an "exhaustive
partition" of type integer. If you follow the links, you see that
there is no fixnum that is also a bignum.
A more correct reason for no using the fixnum class (perhaps this is
what you meant? :-) is that the exact size of most-positive-fixnum is
itself implementation-dependent, and so a fixnum on one implementation
might be a bignum on another (perhaps evenon different-native-word-
sizes from the same vendor), so besides the program not necessarily
being portable due to the question of existence of the fixnum class,
one cannot know what method will be used even if the implementation
does provide that class.
Duane
On Jun 2, 4:14 am, ·····@franz.com wrote:
> On Jun 1, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
>
>
> > Raymond Wiker <····@RawMBP.local> writes:
> > > Paul Foley <····@below.invalid> (http://public.xdi.org/=pf) writes:
>
> > > > Because method dispatch is based on class, not type...
>
> > > Think that's incorrect:
>
> > > (defmethod a ((x float)) (* x x))
>
> > > (defmethod a ((x integer) (+ x x)))
>
> > > (a 3)
>
> > > => 6
>
> > > (a 3.0)
>
> > > => 9.0
>
> > > --- not that this example proves anything, but I'm fairly certain that
> > > method dispatch is supposed to work on more than just class instances
> > > :-)
>
> > The original assertion is correct. It just happens that INTEGER and
> > FLOAT are classes as well as types. But not all types (are required to)
> > have corresponding classes.
>
> So far, so good.
>
> > So, for example you can't write
>
> > (defmethod a ((x integer)) (+ x x))
> > (defmethod a ((x fixnum)) (* 5 x))
>
> > and have this work.
>
> Not true. It is implementation whether this works or not. The
> question is whether the implementation has provided a class for the
> integer type fixnum. For example, in Allegro CL (this one's 32 bit):
>
> CL-USER(1): (defmethod a ((x integer)) (+ x x))
> #<STANDARD-METHOD A (INTEGER)>
> CL-USER(2): (defmethod a ((x fixnum)) (* 5 x))
> #<STANDARD-METHOD A (FIXNUM)>
> CL-USER(3): most-positive-fixnum
> 536870911
> CL-USER(4): (a most-positive-fixnum)
> 2684354555
> CL-USER(5): (a (1+ most-positive-fixnum))
> 1073741824
> CL-USER(6):
>
> While INTEGER must be a class, FIXNUM is not
>
> > required to be (intentionally so, since one could imagine an
> > implementation where there might not be any difference between FIXNUMs
> > and BIGNUMs, both of which are covered by the class INTEGER).
>
> Um, no. If you look at the definition of the integer type (or version
> is here:http://www.franz.com/support/documentation/8.1/ansicl/dictentr/
> integer.htm) you'll see that fixnum and bignum form an "exhaustive
> partition" of type integer. If you follow the links, you see that
> there is no fixnum that is also a bignum.
>
> A more correct reason for no using the fixnum class (perhaps this is
> what you meant? :-) is that the exact size of most-positive-fixnum is
> itself implementation-dependent, and so a fixnum on one implementation
> might be a bignum on another (perhaps evenon different-native-word-
> sizes from the same vendor), so besides the program not necessarily
> being portable due to the question of existence of the fixnum class,
> one cannot know what method will be used even if the implementation
> does provide that class.
This is a very interesting comment, but I'd say that programs written
to take into account the difference between FIXNUMs and BIGNUMs would
be written assuming that code behaves differently around the MOST-*-
FIXNUM constants. The issue you raise would seem to pop up only when
you need to exchange data between programs written on implementations
using different MOST-*-FIXNUM (and company).
Cheers
--
Marco
·····@franz.com writes:
> On Jun 1, 12:34��pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > While INTEGER must be a class, FIXNUM is not
> > required to be (intentionally so, since one could imagine an
> > implementation where there might not be any difference between FIXNUMs
> > and BIGNUMs, both of which are covered by the class INTEGER).
>
> Um, no. If you look at the definition of the integer type (or version
> is here:http://www.franz.com/support/documentation/8.1/ansicl/dictentr/
> integer.htm) you'll see that fixnum and bignum form an "exhaustive
> partition" of type integer. If you follow the links, you see that
> there is no fixnum that is also a bignum.
Well, I was considering a hypothetical implementation where everything
was a BIGNUM and nothing was a FIXNUM. So even with the exhaustive
partition, nothing prevents a conforming implementation from having the
FIXNUM type be empty. It's of course not clear to me what you would set
most positive fixnum and the related constants to in this case.
But if one decided that for simplicity it was better not to have
separate fixnum and bignum implementations, I don't see where the spec
would prevent one from doing so.
This is, as far as I know, though a purely theoretical possibility. I
don't know of any implementations that have followed this route.
--
Thomas A. Russ, USC/Information Sciences Institute
On Jun 2, 9:55 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> ·····@franz.com writes:
> > On Jun 1, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > > While INTEGER must be a class, FIXNUM is not
> > > required to be (intentionally so, since one could imagine an
> > > implementation where there might not be any difference between FIXNUMs
> > > and BIGNUMs, both of which are covered by the class INTEGER).
>
> > Um, no. If you look at the definition of the integer type (or version
> > is here:http://www.franz.com/support/documentation/8.1/ansicl/dictentr/
> > integer.htm) you'll see that fixnum and bignum form an "exhaustive
> > partition" of type integer. If you follow the links, you see that
> > there is no fixnum that is also a bignum.
>
> Well, I was considering a hypothetical implementation where everything
> was a BIGNUM and nothing was a FIXNUM. So even with the exhaustive
> partition, nothing prevents a conforming implementation from having the
> FIXNUM type be empty. It's of course not clear to me what you would set
> most positive fixnum and the related constants to in this case.
>
> But if one decided that for simplicity it was better not to have
> separate fixnum and bignum implementations, I don't see where the spec
> would prevent one from doing so.
>
> This is, as far as I know, though a purely theoretical possibility. I
> don't know of any implementations that have followed this route.
None that are conforming implementations. See
http://www.franz.com/support/documentation/8.1/ansicl/dictentr/fixnum.htm
and note that fixnum must be at least a supertype of (signed-byte 16).
It was theoretically possible at CLtL1 time (i.e. pre-standard) to
have a fixnum set of -1 and 0, but that got cleaned up by the
standards committee. Note also that according to the definition of
most-positive-fixnum, if you choose too small a set you end up with
_very_ small array dimensions... :-)
Duane
<·····@franz.com> wrote:
+---------------
| ····@sevak.isi.edu (Thomas A. Russ) wrote:
| > But if one decided that for simplicity it was better not to have
| > separate fixnum and bignum implementations, I don't see where the spec
| > would prevent one from doing so.
| >
| > This is, as far as I know, though a purely theoretical possibility.
| > I don't know of any implementations that have followed this route.
|
| None that are conforming implementations. See
| http://www.franz.com/support/documentation/8.1/ansicl/dictentr/fixnum.htm
| and note that fixnum must be at least a supertype of (signed-byte 16).
| ... Note also that according to the definition of most-positive-fixnum,
| if you choose too small a set you end up with _very_ small array
| dimensions... :-)
+---------------
Indeed! It's not only that individual indices of arrays must be
non-negative fixnums:
http://www.franz.com/support/documentation/8.1/ansicl/subsubse/arrayind.htm
but, worse still, ARRAY-TOTAL-SIZE-LIMIT is a fixnum!!
http://www.franz.com/support/documentation/8.1/ansicl/dictentr/array-to.htm
So I'll take rather large fixnums, thank you very much!! ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Pascal J. Bourguignon
Subject: Re: How to specialize method on some formula
Date:
Message-ID: <87ljoafoxn.fsf@galatea.local>
···@sevak.isi.edu (Thomas A. Russ) writes:
> ·····@franz.com writes:
>
>> On Jun 1, 12:34�pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> > While INTEGER must be a class, FIXNUM is not
>> > required to be (intentionally so, since one could imagine an
>> > implementation where there might not be any difference between FIXNUMs
>> > and BIGNUMs, both of which are covered by the class INTEGER).
>>
>> Um, no. If you look at the definition of the integer type (or version
>> is here:http://www.franz.com/support/documentation/8.1/ansicl/dictentr/
>> integer.htm) you'll see that fixnum and bignum form an "exhaustive
>> partition" of type integer. If you follow the links, you see that
>> there is no fixnum that is also a bignum.
>
> Well, I was considering a hypothetical implementation where everything
> was a BIGNUM and nothing was a FIXNUM. So even with the exhaustive
> partition, nothing prevents a conforming implementation from having the
> FIXNUM type be empty. It's of course not clear to me what you would set
> most positive fixnum and the related constants to in this case.
>
> But if one decided that for simplicity it was better not to have
> separate fixnum and bignum implementations, I don't see where the spec
> would prevent one from doing so.
>
> This is, as far as I know, though a purely theoretical possibility. I
> don't know of any implementations that have followed this route.
Seems to me that the minimum size of a fixnum is specified to be
16-bit so if you want only one kind of integers, all your integers
will have to be fixnums. You may have FIXNUM = INTEGER and BIGNUM =
{}, with MOST-POSITIVE-FIXNUM = (expt 2 (expt 2 31)). I'd bet a lot
of CL programs won't like it :-)
--
__Pascal Bourguignon__
On 2 jun, 15:52, ····@informatimago.com (Pascal J. Bourguignon) wrote:
> ····@sevak.isi.edu (Thomas A. Russ) writes:
>
>
>
> > ·····@franz.com writes:
>
> >> On Jun 1, 12:34 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> >> > While INTEGER must be a class, FIXNUM is not
> >> > required to be (intentionally so, since one could imagine an
> >> > implementation where there might not be any difference between FIXNUMs
> >> > and BIGNUMs, both of which are covered by the class INTEGER).
>
> >> Um, no. If you look at the definition of the integer type (or version
> >> is here:http://www.franz.com/support/documentation/8.1/ansicl/dictentr/
> >> integer.htm) you'll see that fixnum and bignum form an "exhaustive
> >> partition" of type integer. If you follow the links, you see that
> >> there is no fixnum that is also a bignum.
>
> > Well, I was considering a hypothetical implementation where everything
> > was a BIGNUM and nothing was a FIXNUM. So even with the exhaustive
> > partition, nothing prevents a conforming implementation from having the
> > FIXNUM type be empty. It's of course not clear to me what you would set
> > most positive fixnum and the related constants to in this case.
>
> > But if one decided that for simplicity it was better not to have
> > separate fixnum and bignum implementations, I don't see where the spec
> > would prevent one from doing so.
>
> > This is, as far as I know, though a purely theoretical possibility. I
> > don't know of any implementations that have followed this route.
>
> Seems to me that the minimum size of a fixnum is specified to be
> 16-bit so if you want only one kind of integers, all your integers
> will have to be fixnums. You may have FIXNUM = INTEGER and BIGNUM =
> {}, with MOST-POSITIVE-FIXNUM = (expt 2 (expt 2 31)). I'd bet a lot
> of CL programs won't like it :-)
Then this implementation will need a special way to represent MOST-
POSITIVE-FIXNUM. and MOST-NEGATIVE-FIXNUM. If these numbers are
represented in the normal way, these alone will occupy all your memory.
On Jun 2, 3:54 pm, gugamilare <··········@gmail.com> wrote:
[...]
> Then this implementation will need a special way to represent MOST-
> POSITIVE-FIXNUM. and MOST-NEGATIVE-FIXNUM. If these numbers are
> represented in the normal way, these alone will occupy all your memory.
Speaking of something somewhat related, I've often wished for special
constants POSITIVE-INFINITY and NEGATIVE-INFINITY, which would be
greater (or less) than every number in REAL, with the obvious results
for arithmetic operations. If you had them, you'd also need something
like NOT-A-NUMBER or INDETERMINATE, but having them is very useful in
a lot of places, and thhey might (or might not, I'm not sure) have the
additional benefit of allowing easier handling of the corresponding
floating-point "numbers".
And it would mean that (MAX) and (MIN) could have sensible values. ;)
Cheers,
Pillsy
On 2 jun, 17:01, Pillsy <·········@gmail.com> wrote:
> And it would mean that (MAX) and (MIN) could have sensible values. ;)
Oh, yes, one of the most strange and beautiful convention in
mathematics would have an analogue result in CL:
sup("empty set") = -inf
inf("empty set") = +inf
(max) => NEGATIVE-INFINITY
(min) => POSITIVE-INFINITY
···@informatimago.com (Pascal J. Bourguignon) writes:
> Seems to me that the minimum size of a fixnum is specified to be
> 16-bit
A subtlety I was not aware of. Sorry about sowing the confusion.
(Especially embarrassing after the rash of you-know-who's threads....)
> so if you want only one kind of integers, all your integers
> will have to be fixnums. You may have FIXNUM = INTEGER and BIGNUM =
> {}, with MOST-POSITIVE-FIXNUM = (expt 2 (expt 2 31)). I'd bet a lot
> of CL programs won't like it :-)
--
Thomas A. Russ, USC/Information Sciences Institute
On Jun 1, 10:20 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> I'm writing method that it's second argument could be non-sequence
> (number, char, symbol). Is it
> possible to put this knowledge into the dispatch, i.e. move the if
> into a specializer, code as below:
> I think clojure had something simigliar called multhimethods.
>
> (defmethod shape ((x integer) y)
> (assert (>= x 0))
> (if (or (numberp y)
> (characterp y)
> (symbolp y))
> (make-array x :initial-element y)))
>
> bobiwww.linkedin.com/pub/dir/slobodan/blazeski
You can do it with method combination:
http://groups.google.com/group/comp.lang.lisp/msg/53752d14920a9c47
Cheers,
Vsevolod
On Jun 1, 1:49 pm, Vsevolod Dyomkin <········@gmail.com> wrote:
> On Jun 1, 10:20 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > I'm writing method that it's second argument could be non-sequence
> > (number, char, symbol). Is it
> > possible to put this knowledge into the dispatch, i.e. move the if
> > into a specializer, code as below:
> > I think clojure had something simigliar called multhimethods.
>
> > (defmethod shape ((x integer) y)
> > (assert (>= x 0))
> > (if (or (numberp y)
> > (characterp y)
> > (symbolp y))
> > (make-array x :initial-element y)))
>
> > bobiwww.linkedin.com/pub/dir/slobodan/blazeski
>
> You can do it with method combination:http://groups.google.com/group/comp.lang.lisp/msg/53752d14920a9c47
Thanks very cool.CLOS looks better the more I'm using it.
cheers
bobi
>
> Cheers,
> Vsevolod
Slobodan Blazeski <·················@gmail.com> writes:
> I'm writing method that it's second argument could be non-sequence
> (number, char, symbol). Is it
> possible to put this knowledge into the dispatch, i.e. move the if
> into a specializer, code as below:
> I think clojure had something simigliar called multhimethods.
Um, I don't know about Clojure, but CLOS most definitely has
multi-methods. But you don't get to use a disjunction to do the
dispatch, so this may not be the best solution to your problem below.
> (defmethod shape ((x integer) y)
> (assert (>= x 0))
> (if (or (numberp y)
> (characterp y)
> (symbolp y))
> (make-array x :initial-element y)))
You could transform this into
(defmethod shape ((x integer) (y number)) ...)
(defmethod shape ((x integer) (y character)) ...)
(defmethod shape ((x integer) (y symbol)) ...)
but then you end up having to repeat the body of the method everywhere.
This would make more sense if you wanted to treat these different
classes of Y differently from each other.
You can use method qualifiers to help with some of the code. In
particular, a :BEFORE method that checks the type assertion would be
useful:
(defmethod shape :before ((x integer) y)
(assert (>= x 0)))
will allow you to move that part of the common code into a general
purpose precondition test.
Now, what you may find useful is to use multi-methods and a default
top-level method to give you dispatch that you want:
(defmethod shape ((x integer) (y T))
(make-array :initial-element y))
and then have additional methods specialized on Y that do different
things.
--
Thomas A. Russ, USC/Information Sciences Institute
On Jun 1, 8:31 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > I'm writing method that it's second argument could be non-sequence
> > (number, char, symbol). Is it
> > possible to put this knowledge into the dispatch, i.e. move the if
> > into a specializer, code as below:
> > I think clojure had something simigliar called multhimethods.
>
> Um, I don't know about Clojure, but CLOS most definitely has
> multi-methods. But you don't get to use a disjunction to do the
> dispatch, so this may not be the best solution to your problem below.
>
> > (defmethod shape ((x integer) y)
> > (assert (>= x 0))
> > (if (or (numberp y)
> > (characterp y)
> > (symbolp y))
> > (make-array x :initial-element y)))
>
> You could transform this into
>
> (defmethod shape ((x integer) (y number)) ...)
> (defmethod shape ((x integer) (y character)) ...)
> (defmethod shape ((x integer) (y symbol)) ...)
>
> but then you end up having to repeat the body of the method everywhere.
> This would make more sense if you wanted to treat these different
> classes of Y differently from each other.
Lisper in me hates duplication but I will settle on this for now.
> You can use method qualifiers to help with some of the code. In
> particular, a :BEFORE method that checks the type assertion would be
> useful:
>
> (defmethod shape :before ((x integer) y)
> (assert (>= x 0)))
>
> will allow you to move that part of the common code into a general
> purpose precondition test.
I was more thinking of writing a macro to avoid duplication:
(defmacro with-shape (type)
`(defmethod shape ((x integer) (y ,type))
(assert (>= x 0))
(make-array :initial-element y)
(with-shape integer)
(with-shape character)
(with-shape symbol)
It doesn't buy me a lot but makes bookkeeping easier.
>
> Now, what you may find useful is to use multi-methods and a default
> top-level method to give you dispatch that you want:
>
> (defmethod shape ((x integer) (y T))
> (make-array :initial-element y))
>
> and then have additional methods specialized on Y that do different
> things.
If above method is present what would prevent someone from sending
hash-table as y
(shape 1 (make-hash-table))
I don't have a specialization for it and I want to signal error at the
moment?
>
> --
> Thomas A. Russ, USC/Information Sciences Institute
From: Pascal J. Bourguignon
Subject: Re: How to specialize method on some formula
Date:
Message-ID: <87my8s2mn0.fsf@galatea.local>
Slobodan Blazeski <·················@gmail.com> writes:
> I'm writing method that it's second argument could be non-sequence
> (number, char, symbol). Is it
> possible to put this knowledge into the dispatch, i.e. move the if
> into a specializer, code as below:
> I think clojure had something simigliar called multhimethods.
>
> (defmethod shape ((x integer) y)
> (assert (>= x 0))
> (if (or (numberp y)
> (characterp y)
> (symbolp y))
> (make-array x :initial-element y)))
(defmethod shape ((x integer) (y t)) (assert (<= 0 x)) nil)
(defmethod shape ((x integer) (y number)) (assert (<= 0 x)) (make-array x :initial-element y))
(defmethod shape ((x integer) (y character)) (assert (<= 0 x)) (make-array x :initial-element y))
(defmethod shape ((x integer) (y symbol)) (assert (<= 0 x)) (make-array x :initial-element y))
--
__Pascal Bourguignon__
On Jun 1, 12:20 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> I'm writing method that it's second argument could be non-sequence
> (number, char, symbol). Is it
> possible to put this knowledge into the dispatch, i.e. move the if
> into a specializer
You might be interested in the paper: "Predicate Dispatching in
the Common Lisp Object System":
ftp://publications.ai.mit.edu/ai-publications/2001/AITR-2001-006.pdf
Greg
Slobodan Blazeski wrote:
> I'm writing method that it's second argument could be non-sequence
> (number, char, symbol). Is it
> possible to put this knowledge into the dispatch, i.e. move the if
> into a specializer, code as below:
Yes, it's possible, but you have to be careful about how you design
this. See http://p-cos.net/documents/filtered-dispatch.pdf for one example.
> I think clojure had something simigliar called multhimethods.
Yes, but it seems a bit too ad hoc.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Slobodan Blazeski schrieb:
> I'm writing method that it's second argument could be non-sequence
> (number, char, symbol). Is it
> possible to put this knowledge into the dispatch, i.e. move the if
> into a specializer, code as below:
> I think clojure had something simigliar called multhimethods.
>
> (defmethod shape ((x integer) y)
> (assert (>= x 0))
> (if (or (numberp y)
> (characterp y)
> (symbolp y))
> (make-array x :initial-element y)))
I guess I would simply do it as Pascal Bourguignon suggested.
Common Lisp also has multimethods.
In Clojure it may look like this:
(defn dispatch [x y]
[(class x)
(or (number? y) (instance? Character y) (symbol? y))])
(defmulti shape dispatch)
(defmethod shape [Integer true] [x y]
(vec (take x (repeat y))))
If you need specific methods for other types of y as well then the OR
could be changed to
(or (number? y) (instance? Character y) (symbol? y) (class y))
which allows you to add
(defmethod shape [Integer String] [x y]
(vec (reverse (str y x))))
(shape 10 'Lisp) ==> [Lisp Lisp Lisp Lisp Lisp Lisp Lisp Lisp Lisp Lisp]
(shape 10 "Lisp") ==> [\0 \1 \p \s \i \L]
Andr�
--