greg@vis.UUCP (09/20/90)
I agree that ``its better to have 90 functions operating on one data structure than 90 functions operating on 90 data structures'', and lists are a great data structure, but its even better to have 90 functions able to operate interchangeably with a variety of related data structures. For example, Scheme's generic arithmetic operators work with several numeric types. This is much better than implementing only one overly-general numeric type, e.g. rationals. Unfortunately, Scheme does not have generic sequence operators. I don't think it should add them, though; rather, it should replace the generic arithmetic operators with type-specific ones and provide a generic dispatch mechanism (e.g., OO messaging system) to solve the general problem. BTW, has anyone else find that Scheme's generic operators actually make adding new numeric types more difficult? Someone commented recently that some particular language wasn't really Scheme (or maybe not LISP) because it used vectors for forms. I've always wondered why vectors are not on a more equal footing with lists. It seems like pure prejudice to me. Why is (+ 2 2) O.K. but #(+ 2 2) is not? When can we start commenting on the IEEE Scheme draft and where should we send our comments? Can we submit such comments with EMAIL? Same questions for the ISO efforts. Forever scheme'ing, _Greg J. Greg Davidson Virtual Infinity Systems +1 (619) 452-8059 6231 Branting St; San Diego, CA 92122 USA greg@vis.com ucbvax--| telesoft--| vis!greg@nosc.mil decvax--+---ucsd----+--vis vis!greg@ucsd.edu ihnp4--| nosc----|
markf@zurich.ai.mit.edu (Mark Friedman) (09/20/90)
In article <9009200822.AA02949@vis.> greg@vis.UUCP writes: [Scheme] should replace the generic arithmetic operators with type-specific ones and provide a generic dispatch mechanism (e.g., OO messaging system) to solve the general problem. BTW, has anyone else find that Scheme's generic operators actually make adding new numeric types more difficult? What is difficult or not general about the following: (set! + (lambda addends (if (my-new-numeric-types? addends) (apply my-new-numeric-type+ addends) (apply + addends)))) With macros you could abstract the mechanism with something like: (define-macro (add-new-numeric-type type-name) (let ((symbol-append (lambda (sym1 sym2) (string->symbol (string-append (symbol->string sym1) (symbol->string sym2)))))) (let ((type-predicate-name (symbol-append type-name '?)) (addition-proc-name (symbol-append type-name '+)) (multiplication-proc-name (symbol-append type-name '*)) ...) `(begin (set! + (lambda addends (if (,type-predicate-name addends) (apply ,addition-proc-name addends) (apply + addends)))) (set! * ...) ...)))) He (greg@vis.UUCP) also writes: I've always wondered why vectors are not on a more equal footing with lists. It seems like pure prejudice to me. Why is (+ 2 2) O.K. but #(+ 2 2) is not? They are both O.K. It happens that most interpretors use an evaluator that treats a list as denoting a combination and applies the car of the list to the cdr. It doesn't have to be this way and I don't think that there is anything in the scheme standards that legislates this behavior. -Mark -- Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu
markf@zurich.ai.mit.edu (Mark Friedman) (09/21/90)
As Thomas Breuel corrected me, my example for generic dispatch of
(set! + (lambda addends
(if (my-new-numeric-types? addends)
(apply my-new-numeric-type+ addends)
(apply + addends))))
ought to have been:
(let ((old-+ +))
(set! + (lambda addends
(if (my-new-numeric-types? addends)
(apply my-new-numeric-type+ addends)
(apply old-+ addends)))))
-Mark
--
Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139
markf@zurich.ai.mit.edupeter@ficc.ferranti.com (Peter da Silva) (09/22/90)
In article <MARKF.90Sep21115255@montreux.ai.mit.edu> markf@zurich.ai.mit.edu writes: > As Thomas Breuel corrected me, my example for generic dispatch of > (set! + ... (apply + addends)))) > ought to have been: > (let ((old-+ +)) > (set! + ... (apply old-+ addends))))) Amusing aside... in Forth a new definition is undefined until complete, so you can do a ": + something if ... else + then ;" and have it work... Back to the point, your example needs more work. What if you're adding objects of the old and the new numeric types? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
mark@parc.xerox.com (Mark Weiser) (09/23/90)
In article <MARKF.90Sep21115255@montreux.ai.mit.edu> markf@zurich.ai.mit.edu (Mark Friedman) writes: > (let ((old-+ +)) > (set! + (lambda addends > (if (my-new-numeric-types? addends) > (apply my-new-numeric-type+ addends) > (apply old-+ addends))))) >-Mark And what happens in this case if two (or more) different people are doing this (in a large project, say), each has their own notion of my-new-numeric-types, etc. etc. -mark -- Spoken: Mark Weiser ARPA: weiser@xerox.com Phone: +1-415-494-4406
markf@zurich.ai.mit.edu (Mark Friedman) (09/24/90)
In article <Q++51MC@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: In article <MARKF.90Sep21115255@montreux.ai.mit.edu> markf@zurich.ai.mit.edu writes: > As Thomas Breuel corrected me, my example for generic dispatch of > (set! + ... (apply + addends)))) > ought to have been: > (let ((old-+ +)) > (set! + ... (apply old-+ addends))))) Back to the point, your example needs more work. What if you're adding objects of the old and the new numeric types? Of course it needs more work! I was just showing a simple example of a Scheme approach to genericity. If your needs are more complex the mechanism will be more complex. The basic approach of explicit type checking and redefinition is, I think, still valid. -Mark -- Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu
markf@zurich.ai.mit.edu (Mark Friedman) (09/24/90)
In article <539@roo.UUCP> mark@parc.xerox.com (Mark Weiser) writes: In article <MARKF.90Sep21115255@montreux.ai.mit.edu> markf@zurich.ai.mit.edu (Mark Friedman) writes: > (let ((old-+ +)) > (set! + (lambda addends > (if (my-new-numeric-types? addends) > (apply my-new-numeric-type+ addends) > (apply old-+ addends))))) >-Mark And what happens in this case if two (or more) different people are doing this (in a large project, say), each has their own notion of my-new-numeric-types, etc. etc. They have to talk to each other :-) -Mark -- Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu
mark@parc.xerox.com (Mark Weiser) (09/25/90)
In article <MARKF.90Sep24113028@montreux.ai.mit.edu> markf@zurich.ai.mit.edu (Mark Friedman) writes: >In article <539@roo.UUCP> mark@parc.xerox.com (Mark Weiser) writes: > And what happens in this case if two (or more) different people > are doing this (in a large project, say), each has their own notion > of my-new-numeric-types, etc. etc. >They have to talk to each other :-) Not funny, and only incompletely true. They not only have to talk to each other, but they have to each change their code when they discover each other. Suppose there are three, or six, of these people. That is a lot of people who all have to talk, and change their code, everytime one of them has a new type to add. It is this sort of thing that a good OO language avoids, and that using an OO style within a non-OO language can't avoid. Scheme loses. -mark -- Spoken: Mark Weiser ARPA: weiser@xerox.com Phone: +1-415-494-4406
markf@zurich.ai.mit.edu (Mark Friedman) (09/25/90)
In article <541@roo.UUCP> mark@parc.xerox.com (Mark Weiser) writes: In article <MARKF.90Sep24113028@montreux.ai.mit.edu> markf@zurich.ai.mit.edu (Mark Friedman) writes: >In article <539@roo.UUCP> mark@parc.xerox.com (Mark Weiser) writes: > And what happens in this case if two (or more) different people > are doing this (in a large project, say), each has their own notion > of my-new-numeric-types, etc. etc. >They have to talk to each other :-) Not funny, and only incompletely true. They not only have to talk to each other, but they have to each change their code when they discover each other. Suppose there are three, or six, of these people. That is a lot of people who all have to talk, and change their code, everytime one of them has a new type to add. It is this sort of thing that a good OO language avoids, and that using an OO style within a non-OO language can't avoid. Scheme loses. My original example was a SIMPLE example of a way to get genericity in Scheme. If you need all the OO goodies you can get them. In Scheme. Their a various OO packages for Scheme out there. If they are not enough for you, you can make them do more or roll your own. In any case, OO is no panacea for the problems of team programming. People still have to talk to each other; only now when they make a mistake they can cry "OOps" :-) -Mark -- Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu
kpc00@JUTS.ccc.amdahl.com (kpc) (09/29/90)
In article <541@roo.UUCP> mark@parc.xerox.com (Mark Weiser) writes:
That is a lot of people who all have to talk, and change their
code, everytime one of them has a new type to add. It is this sort
of thing that a good OO language avoids, and that using an OO style
within a non-OO language can't avoid. Scheme loses.
OK, so the question is positively screaming to be asked: What's a good
OO LISP?
... or did I come into this thread late and/or is the question
inappropriate? (This being, after all, c.l.s.)
Any CLOS or Flavors adherents? xlisp? What's out there, and what
isn't out there that should be? What kinds of OO LISP variants are
there?
If an OO LISP were such a "good OO language", would it no longer be
LISP?
--
If you do not receive a reply from me, please resend your mail;
occasionally this site's mail gets delayed.
Neither representing any company nor, necessarily, myself.