Christopher Browne wrote:
> In the last exciting episode, ·······@ziplip.com wrote:
>> Do you think Common Lisp would be a better language if everything
>> was an object like in Dylan and Smalltalk ?
>
> I thought that everything in CL was an object. I must have been
> wrong.
OK. That was poorly worded. Would it be better if all functions
were generic/extendable - that's what I meant. Did you honestly
fail to understand or did you just want to be part of the popular
creative misunderstanding frenzy?
420
·······@ziplip.com writes:
> Christopher Browne wrote:
>
> > In the last exciting episode, ·······@ziplip.com wrote:
> >> Do you think Common Lisp would be a better language if everything
> >> was an object like in Dylan and Smalltalk ?
> >
> > I thought that everything in CL was an object. I must have been
> > wrong.
>
> OK. That was poorly worded. Would it be better if all functions
> were generic/extendable - that's what I meant. Did you honestly
> fail to understand or did you just want to be part of the popular
> creative misunderstanding frenzy?
So, in Common Lisp terminology, "should everything be an object?" and
"should all functions be generic?" are two entirely different
questions that both have reasonable interpretations. (Though the first
one is a little strange since it presumes that everything *isn't* an
object and many folks like to think that everything (of interest) in
Common Lisp already *is* an object.)
People aren't, I suspect, trying to misunderstand you--at worst some
folks may have chosen not to make an effort to guess what you meant
since the way you phrased your question suggests you hadn't bothered
to get a grip on the "local" terminology.
You'll probably also want to define "better". Would a dialect of lisp
in which all functions were generic seem more flexible to the
programmer using it than a dialect where some functions are not
generic? Probably. If flexibility is your sole measure of goodness,
than such a dialect would be "better".
On the other hand, that dialect might be much harder to compile into
efficient code. If you care about the speed of your code then you
might find the less flexible, but more easily compilable dialect
"better".
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
·······@ziplip.com wrote:
> OK. That was poorly worded. Would it be better if all functions
> were generic/extendable - that's what I meant. Did you honestly
> fail to understand or did you just want to be part of the popular
> creative misunderstanding frenzy?
Here is an opinion: http://www.ai.mit.edu/~jrb/goo/wiki/index.php?GooWhy
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Here is an opinion: http://www.ai.mit.edu/~jrb/goo/wiki/index.php?GooWhy
Nice little opinion ya found there.
It seems like the author is proposing an approach to
object-orientation for Scheme, and saying that GOO is a good example
of such a proposal.
OTOH, everything he asks for is already in Common Lisp (except maybe
for the stuff about being a "smaller gem"), so it's hard to see "value
added".
He says, at the end, that "GOO and Dylan both stand on the shoulders
of several giants including CLOS." This comes across to me as saying
something like, "CLOS was ground-breaking and we have a big debt to
it, but of course we've gone beyond that." Yes, Newton was being
humble, but he revolutionized things. I'm not convinced that GOO or
Dylan can make a claim like that.
Here are some criteria that I use when reading these kinds of threads
(the "make lisp better" kind, I mean).
First, does the poster seem to understand why Lisp is a good thing?
That is, does he "get it," understanding why, for example, everything
seems like a pale imitation after using Lisp? (Imagine being exiled
from programming in Lisp. It would be like the guys in Jack Vance's
story "Green Magic".) I frequently see postings that say things like,
"Lisp is good, but it would be much better with a better syntax," or
"Lisp is good but it doesn't protect the programmer from himself in
various ways." These kinds of comments indicate to me that the poster
doesn't really get Lisp.
Second, whenever two people argue about something, and one person says
that two things are different and the other says that they're the
same, I generally believe the person who claims a difference. The
reason for this is that people who see better can see things that
people who don't see as well can't. It's like looking at a double
star. If you look at it with the naked eye, you see a single object,
but with a telescope you see two (or more....). Of course there's a
pedantic insisting on differences that isn't always good, but usually
in a serious discussion the person who distinguishes or discriminates
where another doesn't is seeing better than the other person.
Third, at one point I realized that Lisp was a language built by smart
people for smart people to use to do difficult things. This isn't to
say that smart people aren't doing other things. For example, Java
was done by smart people but it wasn't intended for smart people to
use. C++ is for clever people who like esoterica, but that's not
always smart. And so on. So I don't really expect everyone to get
Lisp. There's a process I call "backing up the bell curve". This
means that usually when something new starts out, it is beyond most
people. It tends to attract people from the right end of the bell
curve in whatever the thing is. But if it grows more popular it can
only do so by backing up the bell curve to the left, because that's
where the people are. The problem is that Lisp makes it hard to back
up the bell curve. So it won't ever be that popular. So I don't
worry about popularity. Posters who complain that Lisp isn't popular
are beating a dead horse in my view.
Finally, I don't believe in unity for unity's sake. Some differences
are good. There are at least two reasons for this. 1) Creative
ferment, and 2) Pursuit of truth. Creative ferment can come about
when people pursue their own visions, feeding off that of others but
also pushing what's unique about their own. Pursuit of truth means
that there are some things that are just wrong, and some people who
believe wrong things, and sometimes to get anywhere you just have to
march on and forget about them. And who knows, maybe they're right
and later you'll come to see that, but if you compromise, at least one
side will probably end up farther from the truth than it would
otherwise be.
--
Fred Gilham ······@csl.sri.com
REPRODUCTIVE RIGHTS: the right not to reproduce, no matter what else
you do. PLANNED PARENTHOOD: an organization that helps you plan to
avoid becoming a parent.
Fred Gilham <······@snapdragon.csl.sri.com> wrote in message news:<··············@snapdragon.csl.sri.com>...
> Pascal Costanza <········@web.de> writes:
> > Here is an opinion: http://www.ai.mit.edu/~jrb/goo/wiki/index.php?GooWhy
>
> Nice little opinion ya found there.
>
> It seems like the author is proposing an approach to
> object-orientation for Scheme, and saying that GOO is a good example
> of such a proposal.
Clarification: JRBs "Why Goo?" article is not just a proposal - it's a
rationale for a complete language implementation which he has already
done - I.e., you can download and use goo now.
>
> OTOH, everything he asks for is already in Common Lisp (except maybe
> for the stuff about being a "smaller gem"), so it's hard to see "value
> added".
No, actually, everything he asks for is *not* already in common lisp.
Specifically, there are many built in functions in Common Lisp which
cannot be extended as generics. See Barry Margolin's response to Kent
Pitman for why it is impractical to attempt to replace these built in
functions with one's own generic equivalents (i.e., lots of other
functions and methods call the built-ins, so you'd have to re-write
those as well, at which point, you're essentially reimplimenting much
of common lisp).
The real issue here is the tradeoff of genericity v. efficiency. If
JRB can get goo to compile down to code as fast as a good common lisp
implementation, then he will have shown that we can have our cake and
eat it too - generics, fully extensible, all the way down, and fast
compiled code. If JRB cannot, then he will have shown why it is that
Common Lisp defines certain low level functions as functions, not
generic functions - so that the language built on top of these
built-ins can be fast.
> He says, at the end, that "GOO and Dylan both stand on the shoulders
> of several giants including CLOS." This comes across to me as saying
> something like, "CLOS was ground-breaking and we have a big debt to
> it, but of course we've gone beyond that." Yes, Newton was being
> humble, but he revolutionized things. I'm not convinced that GOO or
> Dylan can make a claim like that.
If JRB can get goo to generate compiled code as fast as a good Common
Lisp, then, for the the lisp world at least, I think he will have made
a generic function revolution. The goal of goo is a *completely*
extensible language, that doesn't sacrifice efficiency for genericity
and extensibility.
·······@mediaone.net (Raffael Cavallaro) writes:
> Fred Gilham <······@snapdragon.csl.sri.com> wrote in message news:<··············@snapdragon.csl.sri.com>...
>
> > He says, at the end, that "GOO and Dylan both stand on the shoulders
> > of several giants including CLOS." This comes across to me as saying
> > something like, "CLOS was ground-breaking and we have a big debt to
> > it, but of course we've gone beyond that." Yes, Newton was being
> > humble, but he revolutionized things. I'm not convinced that GOO or
> > Dylan can make a claim like that.
>
> If JRB can get goo to generate compiled code as fast as a good Common
> Lisp, then, for the the lisp world at least, I think he will have made
> a generic function revolution. The goal of goo is a *completely*
> extensible language, that doesn't sacrifice efficiency for genericity
> and extensibility.
Yeah, kind of. It wouldn't be quite so much revolutionary, as
evolutionary. After all, we *do* already have standard generic
functions, just not all of our functions are generic. Of course, some
hypothetical (incf common-lisp) that had all-generic functions would
also have to open up the class heirarchy. Otherwise, I'd lose if I
tried:
(defclass modnumber () ...)
(defmethod add ((x modnumber) y)
(make-instance modnumber
'value (mod (+ (modnumber-value x) y)
(modnumber-mod x))
'mod (modnumber-mod x)))
;; ...
(in-package "LEGACY-CODE")
(defun foo (x)
(check-type x number)
(+ x ...))
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 09 Sep 2003 09:41:39 -0700, Fred Gilham wrote:
> He says, at the end, that "GOO and Dylan both stand on the shoulders
> of several giants including CLOS." This comes across to me as saying
> something like, "CLOS was ground-breaking and we have a big debt to
> it, but of course we've gone beyond that." Yes, Newton was being
> humble, but he revolutionized things.
Newton wasn't being humble; he was verbally spitting on Leibnitz.
--
If that makes any sense to you, you have a big problem.
-- C. Durance, Computer Science 234
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley wrote:
> On 09 Sep 2003 09:41:39 -0700, Fred Gilham wrote:
>
> > He says, at the end, that "GOO and Dylan both stand on the shoulders
> > of several giants including CLOS." This comes across to me as saying
> > something like, "CLOS was ground-breaking and we have a big debt to
> > it, but of course we've gone beyond that." Yes, Newton was being
> > humble, but he revolutionized things.
>
> Newton wasn't being humble; he was verbally spitting on Leibnitz.
I thought it was Hooke. Am I misremembering?
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Paul Foley wrote:
>
> > On 09 Sep 2003 09:41:39 -0700, Fred Gilham wrote:
> >
> > > He says, at the end, that "GOO and Dylan both stand on the shoulders
> > > of several giants including CLOS." This comes across to me as saying
> > > something like, "CLOS was ground-breaking and we have a big debt to
> > > it, but of course we've gone beyond that." Yes, Newton was being
> > > humble, but he revolutionized things.
> >
> > Newton wasn't being humble; he was verbally spitting on Leibnitz.
>
> I thought it was Hooke. Am I misremembering?
>
Newton wrote the "standing on the shoulders of giants" thing in a
letter to Hooke. Actually that phrase itself predated Newton, but he
is the one who said, "If I have seen further it is by standing on the
shoulders of Giants."
--
Fred Gilham ······@csl.sri.com
An ABC camera crew interviewed Hillary Clinton in the Bahamas, where
she was sunning herself on a flat rock to keep her body temperature
up. "Cookies," she said, eyeing the cameras. "Children." -- Fred Reed
In article <··············@snapdragon.csl.sri.com>, Fred Gilham
<······@snapdragon.csl.sri.com> wrote:
> Gareth McCaughan <················@pobox.com> writes:
>
> > Paul Foley wrote:
> >
> > > On 09 Sep 2003 09:41:39 -0700, Fred Gilham wrote:
> > >
> > > > He says, at the end, that "GOO and Dylan both stand on the shoulders
> > > > of several giants including CLOS." This comes across to me as saying
> > > > something like, "CLOS was ground-breaking and we have a big debt to
> > > > it, but of course we've gone beyond that." Yes, Newton was being
> > > > humble, but he revolutionized things.
> > >
> > > Newton wasn't being humble; he was verbally spitting on Leibnitz.
> >
> > I thought it was Hooke. Am I misremembering?
> >
>
> Newton wrote the "standing on the shoulders of giants" thing in a
> letter to Hooke. Actually that phrase itself predated Newton, but he
> is the one who said, "If I have seen further it is by standing on the
> shoulders of Giants."
It was (historians say) a dig at Hooke's short stature.
See e.g.: http://drfred.hispeed.com/review/ShouldersofGiants.htm
E.
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> Gareth McCaughan <················@pobox.com> writes:
>
>> Paul Foley wrote:
>>
>> > On 09 Sep 2003 09:41:39 -0700, Fred Gilham wrote:
>> >
>> > > He says, at the end, that "GOO and Dylan both stand on the shoulders
>> > > of several giants including CLOS." This comes across to me as saying
>> > > something like, "CLOS was ground-breaking and we have a big debt to
>> > > it, but of course we've gone beyond that." Yes, Newton was being
>> > > humble, but he revolutionized things.
>> >
>> > Newton wasn't being humble; he was verbally spitting on Leibnitz.
>>
>> I thought it was Hooke. Am I misremembering?
>>
>
> Newton wrote the "standing on the shoulders of giants" thing in a
> letter to Hooke. Actually that phrase itself predated Newton, but he
> is the one who said, "If I have seen further it is by standing on the
> shoulders of Giants."
And I think it was Hal Abelson that said ``If I haven't seen as far,
it is because Giants have been standing on my shoulders.''
Joe Marshall wrote:
> Fred Gilham <······@snapdragon.csl.sri.com> writes:
>
>
>>Gareth McCaughan <················@pobox.com> writes:
>>
>>
>>>Paul Foley wrote:
>>>
>>>
>>>>On 09 Sep 2003 09:41:39 -0700, Fred Gilham wrote:
>>>>
>>>>
>>>>>He says, at the end, that "GOO and Dylan both stand on the shoulders
>>>>>of several giants including CLOS." This comes across to me as saying
>>>>>something like, "CLOS was ground-breaking and we have a big debt to
>>>>>it, but of course we've gone beyond that." Yes, Newton was being
>>>>>humble, but he revolutionized things.
>>>>
>>>>Newton wasn't being humble; he was verbally spitting on Leibnitz.
>>>
>>>I thought it was Hooke. Am I misremembering?
>>>
>>
>>Newton wrote the "standing on the shoulders of giants" thing in a
>>letter to Hooke. Actually that phrase itself predated Newton, but he
>>is the one who said, "If I have seen further it is by standing on the
>>shoulders of Giants."
>
>
> And I think it was Hal Abelson that said ``If I haven't seen as far,
> it is because Giants have been standing on my shoulders.''
>
And, of course:
Ketil Z. Malde: "If I haven't seen further, it is by standing in the
footprints of giants."
!
--ag
--
Artie Gold -- Austin, Texas
Artie Gold wrote:
[Joe Marshall:]
>> And I think it was Hal Abelson that said ``If I haven't seen as far,
>> it is because Giants have been standing on my shoulders.''
[Artie Gold:]
> And, of course:
>
> Ketil Z. Malde: "If I haven't seen further, it is by standing in the
> footprints of giants."
And Brian Reid: "In computer science, we stand on each other's feet."
--
Gareth McCaughan
.sig under construc
On 10 Sep 2003 19:00:59 +0100, Gareth McCaughan wrote:
> Paul Foley wrote:
>> On 09 Sep 2003 09:41:39 -0700, Fred Gilham wrote:
>>
>> > He says, at the end, that "GOO and Dylan both stand on the shoulders
>> > of several giants including CLOS." This comes across to me as saying
>> > something like, "CLOS was ground-breaking and we have a big debt to
>> > it, but of course we've gone beyond that." Yes, Newton was being
>> > humble, but he revolutionized things.
>>
>> Newton wasn't being humble; he was verbally spitting on Leibnitz.
> I thought it was Hooke. Am I misremembering?
Nope; apparently I was.
--
Give a man a match and he'll be warm for a minute, but set him on fire
and he'll be warm for the rest of his life.
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: ··········@YahooGroups.Com
Subject: Re: everything is an object
Date:
Message-ID: <REM-2003sep11-009@Yahoo.Com>
{{Date: 09 Sep 2003 09:41:39 -0700
From: Fred Gilham <······@snapdragon.csl.sri.com>
at one point I realized that Lisp was a language built by smart
people for smart people to use to do difficult things.}}
Funny thing is, using the line-by-line programming style I developed, I
believe even a non-smart person could use Lisp to program effectively,
yielding nicely structured programs that do most data-processing tasks
almost as well as a smart person might achieve with Lisp. Lisp was
originally designed to be for list processing, but now it's for just
about all kinds of data processing. Lisp worked out better than
planned!
{{The problem is that Lisp makes it hard to back up the bell curve. So
it won't ever be that popular.}}
I don't believe that is correct/true. I believe that my method of
line-by-line programming in Lisp could be taught to just about everyone
via a CAI program over the Web. (And I could create such a CGI CAI
application myself if I had funding to support myself while doing it.)
I think doing this would be a good thing, because if virtually everyone
on the net knew how to program in Lisp, then whenever somebody tries to
force them to use some other language they'll realize the task would be
easier in Lisp and there'd be a lot of flak at all managers who insist
on use of other languages. Right now, hardly anyone knows how easy it
is to do things in Lisp, so hardly anyone complains when forced to use
another language, so the other language wins by corporate inertia.
Pascal Costanza <········@web.de> writes:
> ·······@ziplip.com wrote:
>
> > OK. That was poorly worded. Would it be better if all functions
> > were generic/extendable - that's what I meant. Did you honestly fail
> > to understand or did you just want to be part of the popular
> > creative misunderstanding frenzy?
>
> Here is an opinion: http://www.ai.mit.edu/~jrb/goo/wiki/index.php?GooWhy
Here is another
http://dictionary.reference.com/search?q=goo
;)
mike420 inquired:
> Would it be better if all functions were generic/extendable?
I can see the attraction of this. For example, with my
mathematics background I want to overload + for quaterions
or addition modulo 5 or ....
It strikes me that while I cannot do what I want, I can
nevertheless achieve my ultimate goal. I make my own generic
function add
(defmethod add (x y)
(+ x y))
to take over all the properties of +
Then I type
(defclass mod5 ()
((n :accessor residue
:initarg :value
:initform 0)))
(defmethod add ((x mod5)(y mod5))
(make-instance 'mod5
:value (mod (+ (residue x)
(residue y))
5)))
and I'm off and away just as if all functions were generic.
I'm responding with a degree of trepidation because I've
been out of action for 10 years and perhaps missed important
developments in computer science. Pressing on regardless, I
see a problem. Generic functions in CLOS must have congruent
parameter lists, and only the required parameters can be
specialized. I imagine that there is a good reason for this
restriction, so how is a function, such as +, that has no
required parameters, to be rendered generic?
Perhaps this is not really a problem, I don't know. It does
make the notion of having all functions as generic functions
sound terribly ambitious. Elsewhere the debate is single
dispatch versus multiple dispatch. Designing generic
functions to dispatch on a mixture of optional, rest and
keyword parameters sounds tricky.
Alan Crowe
Edinburgh
Scotland
In article <··············@cawtech.freeserve.co.uk>,
····@cawtech.freeserve.co.uk (Alan S. Crowe) wrote:
> Generic functions in CLOS must have congruent
> parameter lists, and only the required parameters can be
> specialized. I imagine that there is a good reason for this
> restriction, so how is a function, such as +, that has no
> required parameters, to be rendered generic?
(defun my+ (&rest args)
(reduce #'add args))
E.
Erann Gat wrote:
> In article <··············@cawtech.freeserve.co.uk>,
> ····@cawtech.freeserve.co.uk (Alan S. Crowe) wrote:
>
>
>>Generic functions in CLOS must have congruent
>>parameter lists, and only the required parameters can be
>>specialized. I imagine that there is a good reason for this
>>restriction, so how is a function, such as +, that has no
>>required parameters, to be rendered generic?
>
>
> (defun my+ (&rest args)
> (reduce #'add args))
Here is a little nitpicking. This should rather be:
(defun my+ (&rest args)
(reduce #'add args :initial-value 0))
ADD could optionally also accept zero arguments in order to make your
version (without :initial-value) work, but then you wouldn't be able to
express ADD as a generic function (<- no specialization on optional
parameters).
Pascal
····@cawtech.freeserve.co.uk (Alan S. Crowe) writes:
> mike420 inquired:
> > Would it be better if all functions were generic/extendable?
This is the sort of thing that makes neophytes all giggly, but is
really not all that interesting.
> I can see the attraction of this. For example, with my
> mathematics background I want to overload + for quaterions
> or addition modulo 5 or ....
If you really want to do this you can. Just create your own base
package for these sort of symbols, only selectively import the CL
versions (or use shadowing), export yours, and in the implementations
of the functions denoted by yours call the CL versions with full
package qualification. All the rest of your packages now use your
base package - not CL.
> see a problem. Generic functions in CLOS must have congruent
> parameter lists, and only the required parameters can be
> specialized. I imagine that there is a good reason for this
> restriction, so how is a function, such as +, that has no
> required parameters, to be rendered generic?
Just define the binary versions and use reduce on the &rest parameter
in the base dispatcher function.
/Jon
····@cawtech.freeserve.co.uk (Alan S. Crowe) writes:
> It does
> make the notion of having all functions as generic functions
> sound terribly ambitious. Elsewhere the debate is single
> dispatch versus multiple dispatch.
Pascal Constanza writes
> Here is an opinion: http://www.ai.mit.edu/~jrb/goo/wiki/index.php?GooWhy
I see evry little new here. Oaklisp (a descendant of T) by Barak
Pearlmutter and Kevin Lang has done this for the last 15 years. It's
much more than a mixture of Scheme with Common Lisp extensions (the
reader, exceptions, format).
Especially it's a dialect where not only is everything an object
(maybe except the usual fixnum culprit), but everything goes through
the generic dispatch!
You can (defun foo (x y) ...) and later add specialized methods to it.
With Oaklisp you can define a three-way tree on which CAR and CDR
would still work (e.g. for the left and right side), as well as all
other existing operations/functions. The additional third branch would
only be visible to your code.
Think about the widening concept of other OO languages: you could
possibly annotate Lisp s-expr with hidden source/line-number information.
Creating classes/types data structures in Oaklisp is real cheap (very
compact representation).
OTOH it doesn't aim at efficient compilation and doesn't care about
type declarations (like (x|<int>) in goo). It's implementation is
built on top of a VM, like CLISP.
It features single dispatch only, on the first argument.
Regards,
Joerg Hoehle
TSI ITC-Security Technologiezentrum
From: ··········@YahooGroups.Com
Subject: Re: everything is an object
Date:
Message-ID: <REM-2003sep11-008@Yahoo.Com>
{{Date: Mon, 8 Sep 2003 16:21:54 -0700 (PDT)
From: ·······@ziplip.com
Would it be better if all functions were generic/extendable}}
It's simply not feasible. As others have pointed out, the arithmetic
functions work only on numbers such that the functions have lots of
mathematical properties such as associative, commutative, zero identity
for add and one identity for multiply, etc. The compiler makes heavy
use of these properties to compile efficient code. If you allow random
programmers to extend these arithmetic functions, how can the compiler
looking at the extensions check absolutely for sure that the new code
maintains all these mathematical properties, so that the compiler can
then make the same optimizations as ite did originally? Do you really
believe it's feasible to install a complete mathematical theorem
proving engine in the Lisp compiler so as to prove all the extensions
to arithmetic functions are consistent with all the "known" properties
of arithmetic functions?
Also, as somebody pointed out, what is the correct return value of +
with no arguments, if the missing arguments might be matrices of
various sizes instead of just numbers for which the number zero is the
appropriate result? How does the compiler know when (+) is supposed to
return a two-by-two matrix of zeroes, or a fifteen-element vector of
zeroes, etc., instead of just a scalar zero?
··········@YahooGroups.Com writes:
> {{Date: Mon, 8 Sep 2003 16:21:54 -0700 (PDT)
> From: ·······@ziplip.com
> Would it be better if all functions were generic/extendable}}
>
> It's simply not feasible. As others have pointed out, the arithmetic
> functions work only on numbers such that the functions have lots of
> mathematical properties such as associative, commutative, zero identity
> for add and one identity for multiply, etc. The compiler makes heavy
> use of these properties to compile efficient code. If you allow random
> programmers to extend these arithmetic functions, how can the compiler
> looking at the extensions check absolutely for sure that the new code
> maintains all these mathematical properties, so that the compiler can
> then make the same optimizations as ite did originally?
One possibility is implemented in the Mathematica language which
solves this problem by carrying a list "attributes" with each
function. For example, the "+" function has the attributes {Flat,
Listable, NumericFunction, OneIdentity, Orderless, Protected}. The
user can read and set these attributes and the compiler will optimize
according to the attributes defined for any given function.
> Do you really believe it's feasible to install a complete
> mathematical theorem proving engine in the Lisp compiler so as to
> prove all the extensions to arithmetic functions are consistent with
> all the "known" properties of arithmetic functions?
Mathematica doesn't implement a theorem prover. Instead it relies on
the user to provide consistent definitions and attributes. If a
user writes buggy code Mathematica will do stupid things.
I have no idea how practical such an approach would be for Lisp.
> Also, as somebody pointed out, what is the correct return value of +
> with no arguments, if the missing arguments might be matrices of
> various sizes instead of just numbers for which the number zero is the
> appropriate result? How does the compiler know when (+) is supposed to
> return a two-by-two matrix of zeroes, or a fifteen-element vector of
> zeroes, etc., instead of just a scalar zero?
Mathematica's solution here is that "0" is a scalar and a matrix and a
vector and a complex at the same time. Also, you can define different
defaults depending on context.
Again: I don't know, how practical this would be for other languages.