How to xor?
in [Lisp]
|
Prev: Lisp and Web Programming
Next: Koch figures
From: Kent M Pitman on 17 Jul 2005 22:07 "Paul F. Dietz" <dietz(a)dls.net> writes: > M Jared Finder wrote: > > > This disallows the "clever" implementation of length for lists that > > you listed: > > > >> (defmethod length ((x cons)) (+ 1 (length (cdr x)))) > >> (defmethod length ((x null)) 0) > > So don't implement it that way! > > The reason I would like to see functions like LENGTH implemented > as generic functions is not so that this clever (but wrong, > as Kent points out) implementation could be used, but so that > users could add their own sequence types (and, elsewhere, their > own streams, and hash tables, and so on). I don't dispute this. However, I personally think the right way to do this (in CL--different languages have different sensibilities) is to provide a protocol hookup to the sequence class. The problem with allowing different sequence classes without requiring them to be subclasses of sequence is accidentally allowing other things. It's bad enough that NIL is sometimes a non-list and sometimes a list. e.g., consider (string 'nil) vs (coerce nil 'string). It's just plain hard to get this right. Whereas defining your own operators as you like is easier.
From: Marcin 'Qrczak' Kowalczyk on 20 Jul 2005 10:10 Kent M Pitman <pitman(a)nhplace.com> writes: > The reason many operators are not generic is that deciding how to do > them generically is tricky and people disagree on the definition. I > recall the NIL project (JonL White, Jonathan Rees, and Rick Bryan) > ran afoul of a generic definition for LENGTH enough that let us > worry. Consider: > (defmethod length ((x cons)) (+ 1 (length (cdr x)))) > (defmethod length ((x null)) 0) > (defmethod length ((x string)) (array-dimension x 0)) > Now think about > (length '(a b . "foo")) The fault is not in length being generic, but in the definition of length for cons or in the existence of improper lists (it's enough to fix either of them). > The point is that often independent definitions invite what I'll call the > "modularity problem" where definitions look ok in isolation but surprising > effects happen in combination. Similar to what > (+ 1 2 "foo") > might do if we allowed + to be generic. It should be an error: + should work only for numbers, string concatenation is a sufficiently different operation. But it doesn't mean that + shouldn't be generic. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
From: Sam Steingold on 20 Jul 2005 10:50 > * Marcin 'Qrczak' Kowalczyk <depmnx(a)xaz.bet.cy> [2005-07-20 16:10:41 +0200]: > > Kent M Pitman <pitman(a)nhplace.com> writes: > >> The point is that often independent definitions invite what I'll call the >> "modularity problem" where definitions look ok in isolation but surprising >> effects happen in combination. Similar to what >> (+ 1 2 "foo") >> might do if we allowed + to be generic. > > It should be an error: + should work only for numbers, string > concatenation is a sufficiently different operation. But it doesn't > mean that + shouldn't be generic. this is confusing. on one hand, you say that "+ should work only for numbers". since there is no way to create a new kind of numbers, the implementation can implement + as a non-generic function without losing any functionality. on the other hand, you say "it doesn't mean that + shouldn't be generic" what's the point? you cannot add a method anyway! you cannot define a new kind of number! Yeah, you might find it tempting to be able to write (defclass quaternion (number) ...) (defmethod + ((x quaternion) (y number)) ...) But as soon as you do, you need to define also * methods. note that quaternion multiplication is not commutative, and octonions are not even associative, so the usual properties of * that many compilers use will now be broken (unless the compiler can establish argument types). yes, the "demo" or "toy" value of CL would increase if all the functions were generic, but CL is not a "demo" language. CL is the tool for solving _hard_ problems. Why would you want to "overload" + in a large project (where it will confuse people)? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.honestreporting.com> <http://www.jihadwatch.org/> <http://ffii.org/> <http://www.memri.org/> <http://www.dhimmi.com/> Politically Correct Chess: Translucent VS. Transparent.
From: Marcin 'Qrczak' Kowalczyk on 20 Jul 2005 11:05 Sam Steingold <sds(a)gnu.org> writes: >> It should be an error: + should work only for numbers, string >> concatenation is a sufficiently different operation. But it doesn't >> mean that + shouldn't be generic. > > this is confusing. > on one hand, you say that "+ should work only for numbers". > since there is no way to create a new kind of numbers, There should be. > note that quaternion multiplication is not commutative, I don't mean quaternions, but e.g. decimal fixed point numbers for currencies (more efficient than rationals), or lazily computed arbitrary precision approximations of real numbers. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
From: Sam Steingold on 20 Jul 2005 11:57
> * Marcin 'Qrczak' Kowalczyk <depmnx(a)xaz.bet.cy> [2005-07-20 17:05:50 +0200]: > > I don't mean quaternions, but e.g. decimal fixed point numbers for > currencies (more efficient than rationals), neither rationals nor integers (another common advice) are good for currencies. numbers can be multiplied by each other. currencies cannot. what is (* $10 $15)? $$150?! -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.openvotingconsortium.org/> <http://www.dhimmi.com/> <http://www.honestreporting.com> MS Windows: error: the operation completed successfully. |