🚀 go-pugleaf

rick@tetrauk.UUCP (Rick Jones) writes:

>This proposition is actually the crux.  It maintains that two completely
>unrelated types, which _happen_ to have two features/methods of corresponding
>names (and we will assume signatures :-), can be used interchangeably by client
>code which is only interested in those features.  But there is a difference
>between _looking_ the same and _being_ the same.

>Both a letter and an invoice may support an operation "post", but it doesn't
>mean that you are doing the same thing to both of them.  The letter you post to
>the mail, the invoice to the ledger.  It's even more subtle if you also
>consider an invoice to be a sub-type of letter which can also be posted to the
>mail.  Names in themselves are not as significant as they suggest.  Eiffel has
>demonstrated this in its handling of multiple inheritance, where it allows
>features to be renamed on inheritance (the _same_ feature can have a
>_different_ name in the context of a sub-class;  how do you handle that with
>dynamic typing?).  Names are really a syntactic convenience.

Granted, using names in this context is far from perfect.  Using names and
types together is a little closer, but still not perfect.  But I often don't
care that the two operations are in any sense the same, only that they share
certain properties.  For example, I might define a routine that raises a
value to an integer power by repeated squaring.  It should care only that
I have an associative multiplication operation available, and perhaps a
multiplicative identity.  I should be able to invoke this operation on the
string "a" and the integer 200, with concatenation acting as multiplication,
in order to get a string of 200 "a"s.  (In a language that doesn't allow
destructive updates of strings, this may even be the most efficient way
to accomplish this task.)  But this doesn't mean that concatenation and
integer multiplication are in any sense "the same".  It also points out
(as RickJones stated) that defining "the same" using inheritance is way off.
Arguing that strings and integers should inherit from a class of "monoids"
seems to me to be really pushing it, and requires way too much foresight by
the class hierarachy designer.  (Furthermore integer could inherit in two
different ways from such a class.  A priori, I don't know whether plus or
times is the interesting operation.)

I think IBMs Scratchpad II comes closest to getting this issue right, in that
(as I recall) the language allows operations in algebras to be annotated with
properties such as "associative".  Their existence is checked in cases like
the above.  There is of course no way for the compiler to associate any
semantics with the word "associative"; it's treated simply as an uninterpreted
property that some operations are asserted to have.

Hans-J. Boehm
(boehm@xerox.com)

Usual disclaimers ...