🚀 go-pugleaf

In article <632@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes:

>Stan, I don't mean to be rude, but your posting completely misses the
>point.  Normally I prefer not to respond point-by-point when
>replying, but your article contains so much confusion and
>misinformation that I do not see any reasonable alternative.

And here I thought *I* was clearing up confusion and misinformation!
I'm not trying to debate, but to clarify that there are multiple points
of view on OOP and ADTs.  There were statements with which I disagreed,
and the nature of the net is that controversial things will be challenged.
Saying that a controversial statement is an "explanation" is not going to
save one from that challenge!

>>>OOP is not (in my opinion, at least!) simply a special case of
>>>abstract data types.

I tend to view them as being more alike than different, but that is probably
because I see similarities between things rather than differences.  There
are good reasons to see similarities in a field (CS) which is prone to
reinventing wheels on the basis of trivial distinctions.  Unfortunately,
there is a lot of disagreement on what is "trivial" and what is not...

>You take the (implicitly stated) point of view that OBJ2 is
>synonymous with ADTs.  Well, that is a point of view, but it is not
>the general point of view.

OK then, I'm ignorant.  What are ADTs, and what is the archetypal ADT
language?  Some of the points made subsequently (but not reproduced here)
seem to assume particular limitations, but it was not at all clear what
those limitations are supposed to be.  For instance, an ADT without
subtypes ("subsorts") is worthless as far as I'm concerned.  I like OBJ2
because it has abstract data types without being crippled by them...

>Smalltalk is generally considered to be the archetypal OOP language.

Perhaps, but let's not confuse details of Smalltalk with the definition
of object-oriented programming.  Any definition of OOP should encompass
Simula, C++, the assorted Lisp object systems, and actors.  Older folks
seem to consider Simula as the archetypal OOP language, by the way, while
Scheme fans (and Abelson/Sussman's textbook) equate objects with functional
closures, and suggest that specialized OOP systems are unnecessary.

>On the contrary, the phrase "compile time" is not misleading, nor is
>it irrelevant.  Languages which are strongly typed (i.e., type is
>determined and checked by compiler) are RESTRICTED as to what
>programs are legal (i.e., "what can be expressed") when compared to
>languages which are "typeless".

There are a lot more kinds of language implementations than most people
realize.  Lisp alone has a gamut from pure interpretation to pure compilation,
including some strange combined approaches.  There are Pascal interpreters
too, but that doesn't mean Pascal is not strongly typed.  A Common Lisp
program with declarations probably will not compile if there are type
mismatches - does that mean that Lisp is strongly typed?  References to
"compile time" when discussing language semantics are mistakes.  The meaning
of programs is at issue, not language implementation strategies...

>I confess to not being familiar
>enough with OBJ2 to know this, but I assume that in OBJ2 the "type"
>(OBJ2 may call it something different) of a variable is known and
>checked by the compiler.

For openers, OBJ2 is based on term rewriting, and doesn't have a compiler
at all!  The word "sort" is used instead of "type", because "type" is not
a particularly precise term, and has undesirable connotations.  The only
variables are logical variables bound in environments, and their type is
always known, although perhaps not very accurately.  By "not very accurately",
I mean that because in both Smalltalk and OBJ2, types live in a hierarchy,
one always knows that the type of something is whatever is at the top of
hierarchy.  In Smalltalk, you know that everything is of class "object",
for instance.  OBJ2 proposes a "universal sort" U, which includes all types
as subtypes.  This is also like Common Lisp's type "t".

I recommend the paper on OBJ2 in POPL 85;  it is quite readable, and avoids
most of the category theory and logic that makes much modern ADT work
incomprehensible to ordinary mortals.  As a Lisp/Prolog hacker, I generally
abhor any notion of strong typing, but OBJ2's type system is so high-powered
that it does seem not restrictive at all.  (I hope I'm not overstating OBJ2's
capabilities - not having used it, I may be projecting features that I would
incorporate in an "ideal" language!)

>But, Smalltalk's polymorphism does not come "under the guise" of some
>special mechanism -- EVERY procedure is polymorphic, in the sense
>that no special mechanisms or constructs (such as "parameterized
>objects" or "subsorts") must be used to allow fully polymorphic use
>of the procedure.  This flexibility is the clearest and most
>identifiable distinction between OOP and ADT's.  

If you don't know what subsorts or parametrized objects are, then how
do you know they're "special constructs" and not something available
by default?  In fact they're declaration mechanisms, and don't affect
the rewrite rules directly.

>In OBJ2, can the value of a variable be an object of any
>type at any time?

Yes, to the extent that OBJ2 has variables.  But variables in a rewriting
system are not locations that you get data from and store data into - they
are more like mathematical variables that serve only to connect two places
together.  To find out more, read any Prolog textbook.

>From your statement about "a Unix Smalltalk compiler" I can only
>conclude that you have a severe misunderstanding both of Smalltalk
>and of the the point I was making.  Yes, it is true that compiler
>would have to know what operations to include -- and, from my
>previous paragraph, we know that that set would be ALL operations.

Yes, I must admit to having confused optimization with necessity, and
only partly saved myself by talking about construction of code and
interpreters etc.  In the total absence of information, a Smalltalk
object must be prepared to do something with any operation whatsoever,
which means that the method lookup process might have to go through
all sorts of tables trying to match names.  You couldn't even have a
fixed-shape table, because the system might dynamically create new
types (classes) and everybody must augment their lookup tables to
accommodate the new classes.  The performance of this sort of thing
is inherently dismal, but that's the price of flexibility.

I don't know if OBJ2 supports dynamic definition of new types, but this
particular issue touches on some of the deepest issues in type theory.
You can hack out systems like Smalltalk to do it, but key aspects of behavior
will be operationally-defined at best.  I suppose most people don't care
whether the system will crash if you redefine class Class, because they're
not going to do it anyway, but there is a fair amount of current research
directed at the question of what *should* happen.

>There EXIST specifications which do describe a methods behavior.
>But, any such specifications are NOT present within Smalltalk.  ADT
>languages have specifications explicitly provided as part of the
>program.  Smalltalk programs do not.  

In OBJ2, the only "specifications" are the rewrite rules, which, as it
happens, are also the program.  Perhaps this means OBJ2 is not an
ADT language...

>> >In Smalltalk, it is trivial to write a class definition for
>> >a stack which can mix integers, floats, rectangles, and even other
>> >stacks within a single stack.  The ease of writing very polymorphic
>> >code clearly distinguishes OOP from ADT's.
>> 
>> No, it clearly distinguishes inferior ADT systems from good ADT systems.
>> Polymorphism is independent of OOP and ADT - for instance, vanilla Lisp
>> and Prolog systems are polymorphic but are not considered object-oriented
>> or data-abstracted.  In my book, non-polymorphic languages are down with
>> assembly languages as things to avoid.
>
>(Here we go again on "OBJ2 is the one true ADT language" kick.
>Sorry, that just isn't the general opinion.)  

It's not at all clear to me how the assertion that polymorphism is a good
thing leads to the assertion that OBJ2 is the one true ADT language.
As I mentioned earlier, I am a Lisp and Prolog person.  I've never used
OBJ2, and probably never will, because I like to write real programs, and
OBJ2 just doesn't have the performance.  I do like to think about the next
generation of languages, and OBJ2 seems closer to that next generation...

>Lots of languages are polymorphic -- few are as
>polymorphic as Smalltalk.  No ADT language with which I am familiar
>is as polymorphic as Smalltalk.  Is OBJ2 as polymorphic as Smalltalk?
>You offer no evidence, one way or the other.

Read the POPL paper - I don't plan to type it all in myself.

>What makes OOP different *from ADT's* is the degree to which the operations
>are thought to be intrinsic rather than extrinsic.

Defining a concept by an attitude doesn't seem very precise?

>> There *is* one aspect of the object-oriented paradigm that comes out
>> better than in other paradigms - concurrency.  Hewitt-style actors
>> communicating with each other make more sense to me than the bizarre
>> concurrency formalisms promulgated for procedural, functional, and
>> logic paradigms...  Anybody see that differently?  
>
>Oh, if you understand OOP in terms of actors, I can see why you're
>confused.  (half :-)

Sigh, a frivolous response to a serious question...

>Afterthought:  I wonder if the etymology of OBJ2 is "object oriented
>extension to abstract data types"?  If so, that would explain a lot.

Ask Goguen, not me.

>The point is that we are discussing the DIFFERENCE between ADT's and
>OOP.  If ADT's are better than OOP, as you seem to imply, then they
>must also be different.  How are they different?  That is the
>question we are trying to answer, and about which you say very
>little.

I don't think I ever claimed that ADTs are "better" than OOP.  Seems unlikely,
since I believe them to be basically equivalent.  I wonder if you were
offended by my disparaging Smalltalk with respect to OBJ2.  Don't get me
wrong - I think Smalltalk is a great language, I have all the Smalltalk books,
I'm putting a section on Smalltalk internals in my thesis.  But let's not try
to equate Smalltalk with objects;  it will only confuse some and disenchant
others.  Rather, let us identify the important concepts of languages and
define them precisely, so that future languages can incorporate those
concepts both elegantly and efficiently.

>Tim

								stan