Smalltalk-80: The Language
Ralph Johnson
>Here are the quotes, with some comment (usually restatements of things I
>have already said):
> [Preface, page ix] "Smalltalk is built on the model of communicating
> objects."
>This is entirely wrong, and is the source of many confusions. Most
>emphatically Smalltalk is not an actor language. Smalltalk objects don't
>communicate with each other, in any meaningful sense of the word; they
>are passed as parameters to procedures that are organized in
>classes.
You are interpreting this statement as a statement about programming
language semantics. In fact, it is a description of the intent of
the designers of Smalltalk. It is a statement about history. Alan
Kay's paper on the history of Smalltalk elaborates this statement.
If you interpret it as about intent then it is true.
It is odd and true that a language based on the model of communicating
objects has nothing to do with distribution or concurrency. Nevertheless,
Smalltalk programmers really do think of a Smalltalk program as a set of
communicating objects. Smalltalk implementors and people who worry
about formal semantics may not think this way (and probably shouldn't),
but application programmers usually do.
People seem to get upset with the notation that your life can
be better and you can be more effective if you believe false things.
In this case, I think the reason that Smalltalk programmers are so
effective when they believe false things about their language is that
quotes like
> "An object consists of some private memory and a set of operations".
> [Objects and messages, page 6]
and
> "Computing is viewed as an intrinsic capability of objects that can be
> uniformly invoked by sending messages." [Objects and messages, page 6]
describe an ideal language that the designers of Smalltalk were striving
for. In fact, Smalltalk-72 was much more like this than Smalltalk-80.
Smalltalk-72 *was* an actor system. The designers of Smalltalk discovered
that they could make their system much faster without losing significant
benefits if they broke their ideal system in small, out of the way places.
Thus, though Smalltalk-80 is based on these principles historically,
it does not completely live up to them. This does not bother most of its
users.
> * the properties of the Smalltalk-80 language and the system.
> * that these are different from those of the virtual machine.
> * that Smalltalk-80 is as defined in those books; Smalltalk-72,
> Smalltalk-74, Smalltalk-76, Smalltalk-V, LittleSmalltalk,
> Smalltalk-with-multiple-inheritance, ParcPlace Smalltalk release X,
> and so on are defined in other books, no less meritorious, but
> different nonetheless.
Smalltalk, like every other human artifact that is useful and regularly
used, is a living system. Books capture only part of the intent of
some of its designers at a particular point in time. Languages as
fixed, mathematical objects are different from languages as useful
tools to get work done. Most people on this list are interested in
Smalltalk as a tool to build applications, not as a tool for reasoning
about languages. I think this is why there is often miscommunication.
"Smalltalk-80: The Language" is a great book. However, I am more
interested in Smalltalk, the tool, than in Smalltalk, the language.
I want a tool that fits itself to my hand, that adapts to my needs,
and that continues to be useful as my life changes. One of the
great things about Smalltalk is that it is even better on a 32 meg
Pentium than it was on a 4 meg 68000-based Tektronix machine back
in 1985. It is a lot cheaper, too!
-Ralph
Piercarlo Grandi
>>> Johnson) adds:
Ralph> p...@aber.ac.uk (Piercarlo Grandi) writes:
pcg> Here are the quotes, with some comment (usually restatements of
pcg> things I have already said):
ST80> [Preface, page ix] "Smalltalk is built on the model of
ST80> communicating objects."
pcg> This is entirely wrong, and is the source of many confusions. Most
pcg> emphatically Smalltalk is not an actor language. Smalltalk objects
pcg> don't communicate with each other, in any meaningful sense of the
pcg> word; they are passed as parameters to procedures that are
pcg> organized in classes.
Ralph> You are interpreting this statement as a statement about
Ralph> programming language semantics.
No, I am not -- I interpret it as fluff :-). But I am commenting on my
perception that a few people in comp.lang.smalltalk have shown that
_they_ regard it as a statement about the semantics of the language.
On first approximation, they are justified in doing so: the literal
meaning is hard to dispute, and it is hard to imagine that the preface
to a book contains a false premise of such magnitude about what is
discussed in most of the book (except for the discrete simulation
chaper, that is).
However, after ten seconds of using a Smalltalk system they should have
started realizing that this must be not in fact taken "literally" :-).
Ralph> In fact, it is a description of the intent of the designers of
Ralph> Smalltalk. It is a statement about history. Alan Kay's paper on
Ralph> the history of Smalltalk elaborates this statement. If you
Ralph> interpret it as about intent then it is true.
I have already intepreted it not as intent but as historical baggage: in
another thread I mentioned the references that show that those that
designed Smalltalk were familiar with actor systems (and as you mention
later, Smalltalk-72 was as a result close to an actor system).
Ralph> It is odd and true that a language based on the model of
^^^^^
"being described as based" :-)
Ralph> communicating objects has nothing to do with distribution or
Ralph> concurrency.
Ralph> Nevertheless, Smalltalk programmers really do think of a
^ "some", or perhaps even "many" :-)
Ralph> Smalltalk program as a set of communicating objects.
Ah OK, as long as they understand that things are actually completely
different: that instead of organizing a program as a collection of
actors having specific behaviours in terms of the (possibly
asynchronous) messaging patterns they engage in, they actually organize
it as a set of classes that encapsulate all the procedures that work on
the representation of values of the same type, two rather different
views.
It beats me why one should _still_ use a terminology describing the
former for a aystem based on the latter, but as long as everybody does
the mental translattions involved...
Ralph> Smalltalk implementors and people who worry about formal
Ralph> semantics may not think this way (and probably shouldn't), but
Ralph> application programmers usually do.
But to me this sort of doublethink seems a strain, and indeed in this
newsgroup there has been some evidence that some Smalltalk practitioners
have are not merely speaking of Smalltalk-80 as an actor language, but
are believing it is.
Ralph> People seem to get upset with the notation that your life can be
Ralph> better and you can be more effective if you believe false things.
Well, in "real life", whatever that is, one can do the right thing for
the wrong reasons, and be happy. But it may be different in computing:
there is an element of formality in it.
Ralph> In this case, I think the reason that Smalltalk programmers are
Ralph> so effective when they believe false things about their language
Ralph> is that quotes like
ST80> "An object consists of some private memory and a set of
ST80> operations". [Objects and messages, page 6] "Computing is viewed
ST80> as an intrinsic capability of objects that can be uniformly
ST80> invoked by sending messages." [Objects and messages, page 6]
Ralph> describe an ideal language that the designers of Smalltalk were
Ralph> striving for.
My impression is rather that Smalltalks are so nice to use and have such
powerful environments that even ceonceptualizing it erroneously does not
matter much; most Smalltalk programmers, I guess, work by imitation of
how the system is actually structured, not from first principles, and
that's fine.
Ralph> In fact, Smalltalk-72 was much more like this than Smalltalk-80.
Ralph> Smalltalk-72 *was* an actor system. The designers of Smalltalk
Ralph> discovered that they could make their system much faster
If you are thinking of Smalltalk-72's dynamic parsing of the "message
stream" and the passage to a more conventional overloaded names for
methods sort of arrangement, I think they did that in part for speed,
but also in part because it was _too_ flexible, in the sense that is
amounted to context dependent macro expansion:
"The message stream model was complicated and inefficient. One could
not tell what a given piece of code meant in isolation. This became a
problem as we attempted to build larger systems in which modularity
was more of an issue. Also, a considerable amount of time was wasted
on execution time parsing (determining whether the result of a
receiver expression should gobble the next token in the execution
stream" [Bits of history, page13].
In part they chose that model because of inspiration from Logo, more
than actor systems (I remember seeing the Scientific American paper, and
it was actually extolled as being more comprehensible to kids, a sort of
turtle parser).
Ralph> without losing significant benefits if they broke their ideal
Ralph> system in small, out of the way places.
Actually I think that thye repented wholesale: they kept the
terminology, but realized that a more conventional model suited them
better (a large part of the unpopularity of the actor model is that it
really was meant for machines with mobs of little processors, which have
not yet materialized on the desktop).
In their switch I suspect that the Smalltalk group were heavily
influenced by the (Inter)Lisp group (viceversa happened too): after all
Smalltalk-80 is actually an OO Lisp, but for the slightly odd :-)
unlisp-like syntax (another similar, more lisp-looking system, was
MDL/Muddle from the MIT LCS PRG).
Ralph> Thus, though Smalltalk-80 is based on these principles
Ralph> historically, it does not completely live up to them.
Well, as it is now, it completely "betrays" them: because the semantics
of, and the way one works in, an actor OO system and those of a
conventional OO system like Smalltalk-80 are very different.
Ralph> This does not bother most of its users.
Perhaps it should: because the decomposition principles to be used are
completely different.
If Smalltalk-80 were actor based, one should decompose programs into a
set of cooperating, autonomous active entities.
Instead in Smalltalk-80, as the books themselves show very clearly, one
decomposes programs into a set of procedures organized in a set of
hierarchically organized modules.
I suspect that Smalltalk programmers are saved from the worst
consequences of the use of an inappropriate terminology byt the fact
that while the summary description and the terminology in the
Smalltalk-80 books may mislead them into thinking that it is an actor
system, the bulk of those books are very clear about describing it as a
procedure/module based one.
pcg> [ ... Smalltalk is a family of languages embedded in a system, on
pcg> top of a virtual machine; these should not be confused with each
pcg> other, and one should talk by default about the Smalltalk-80
pcg> language, for it is the oen that is well documented ... ]
Ralph> Smalltalk, like every other human artifact that is useful and
Ralph> regularly used, is a living system. [ ... ] Most people on this
Ralph> list are interested in Smalltalk as a tool to build applications,
Ralph> not as a tool for reasoning about languages.
Yes, and then I ask: "Which Smalltalk?". If one is interested in
exploring the use as a tool of Brand X Smalltalk, fine.
Ralph> I think this is why there is often miscommunication.
I have realized this too, that's why I have been trying to make sure
that we are all talking about one specific well documented incarnation.
It's essential to be discussing "Smalltalk-80" the language, because
there is simply no alternative that makes our discussion meaningful,
because if we were discussing any conceivable dialect, and/or any
conceivable implementation, then we could as well substitute "Smalltalk"
with "thing", and have a discussion about ontology; indeed this seems a
popular pastime with some people in comp.object :-).
Ralph> "Smalltalk-80: The Language" is a great book. However, I am more
Ralph> interested in Smalltalk, the tool, than in Smalltalk, the
Ralph> language. I want a tool that fits itself to my hand, that adapts
Ralph> to my needs, and that continues to be useful as my life changes.
But the distinction between languages and tools that implement them is a
respectable one, for very solid conceptual _and_ business reasons, and
those that get so much into one tool that they forget that it is one
tool of many will pay the price on the bottom line, even if I can
understand the enthusiasm with which you write the above paragraph.
Ralph> One of the great things about Smalltalk is that it is even better
Ralph> on a 32 meg Pentium than it was on a 4 meg 68000-based Tektronix
Ralph> machine back in 1985. It is a lot cheaper, too!
Let's rephrase it as saying that finally hardware has caught up with
better, more productive, application development paradigms. It's time
more programmers did as well (and, let me add, understood they are
really programming in OO Lisp, curious as it may seem, not in
MicroPlanner :->).
Piercarlo Grandi
Piercarlo Grandi
Bytesmiths> There he goes again, folks! For some reason, the Smalltalk
Bytesmiths> archaeologist Piercarlo Grandi is suffering from the
Bytesmiths> delusion that his favorite tool for pointless argument,
Bytesmiths> "Smalltalk-80: The Language," is somehow "_the_authoritative
Bytesmiths> definition of the Smalltalk-80, version 2, language".
This is not a delusion: if you could remember the contents of the book
in question, this is what the book claims, and I have chosen to take
that at face value.
Bytesmiths> This may be true for Smalltalk-80,
So, make up your mind (if any, and not null or void): either I suffer
the delusion that a book with a title like "Smalltalk-80: The Language"
by Goldberg and Robson is the definition of Smalltalk-80, or it is not a
delusion.
Bytesmiths> but it is utterly irrelevant.
I think here we hear the voice of ignorance speaking. Since you have
been caught out several times as not "remembering" the contents of this
book, now you claim it is irrelevant. That's a very convenient position.
But the book is not irrelevant because pointless argument is that about
"Smalltalk" without defining what it is, which is what certaint arrogant
(that put down claims from above as if they had boundless authority) and
ignorant people like to do.
If there is to be argument, there must be some workable definition of
the subject. To me it seems a trivial observation, but I understand that
"ancient philosophy" can be a challenge for some.
Otherwise I can claim that "Smalltalk", contrarily to what that "utterly
irrelevant" books says, is not based on messaging and objects and
classes and ..., but has four legs and whiskers, because I know a guy
who called his cat "Smalltalk".
Bytesmiths> Those of us who are involved with the X3J20 committee prefer
Bytesmiths> the IBM Red Book, with PK's favorite tome (A. K. A. "The
Bytesmiths> Blue Book") as a back-up for historical detail. No one on
Bytesmiths> the committee agrees that the Blue Book is "_the_authoritive
Bytesmiths> definition" of modern Smalltalk.
Indeed it is not, not I have ever claimed it is; but there is _no_
authoritative definition of "modern" Smalltalk, whatever that is. The
ANSI committee work in progress is not quite there yet.
Incidentally, if you are "in the know" at least about the ANSI effort,
what's going on there? The FAQ says to look at the minutes on the xcf
FTP area, and the only minute I could find there is "February
1994". Is there another archive of the minutes?
Bytesmiths> Score: PK: 0, ANSI: 1.
Ah please: not only you cannot "remember" well known books, you also
cannot remember that I wrote that it is an authoritative definition of
Smalltalk-80 (actually you cannot even remember you acknowledged
yourself as much a few lines before!), and not of modern Smalltalk,
whatever you can make it up to be. When memory is so unreliable, it's
easy to think you have "scored".
Indeed, here is a question: what is the "modern Smalltalk" you talk
about? IBM's as you seem to claim above? Let us know!
The ANSI committee, as you should know, has been formed precisely
because "The Language", while being (hopefully!) the common base for all
Smalltalks, is no longer a _complete_ description.
The situation is not quite as catastrophic as you depict it:
Bytesmiths> Since then, ParcPlace has done whatever it felt like with
Bytesmiths> ObjectWorks/VisualWorks, since they "owned" the spec, and
Bytesmiths> other vendors have stretched things even further.
You are in effect claiming that there are no two truly compatible
implementations of "Smalltalk", and that anybody choosing one is locked
into a specific proprietary solution forever. If this is true, and in
effect in part I tend to agree, it is the single best reason for people
not to invest in Smalltalk that you could have found.
Think of it: either people who invest in Smalltalk can *rely* on what is
written in "Smalltalk-80: The Language" as the _only_ vendor independent
common base, or they are are the mercy of any vendor's policies and
continued exitence.
This of course amounts to a sales pitch for IBM's Own Smalltalk, whether
you intend to make it or not, because it is conceivable that "small"
companies like Digitalk (which was taken over by:) and even ParcPlace
could disappear (all those that have sunk loads of money in Smalltalk-V
applications in unportable applications are currently terrified of what
ParcPlace is going to do) or go under, leaving those that have invested
in their implementations high and dry and jobless.
So, that I use "The Language" as the base on which discuss Smalltalk is
not motivated by a preference for archeology, but simply by the desire
not to advance the cause of any particular vendor, and the lack of an
otherwise neutral, widely available, definition, unless of course you
give us one. :-)
Bytesmiths
Piercarlo Grandi is suffering from the delusion that his favorite tool for
pointless argument, "Smalltalk-80: The Language," is somehow
"_the_authoritative definition of the Smalltalk-80, version 2, language".
This may be true for Smalltalk-80, but it is utterly irrelevant. You
cannot buy an implementation of Smalltalk-80 these days. Those of us who
are involved with the X3J20 committee prefer the IBM Red Book, with PK's
favorite tome (A. K. A. "The Blue Book") as a back-up for historical
detail. No one on the committee agrees that the Blue Book is
"_the_authoritive definition" of modern Smalltalk. Score: PK: 0, ANSI: 1.
The last thing close to Smalltalk-80 you could buy was Tek Smalltalk, in
1988 or so. We went out of our way to conform to ST-80v2 specs. Since
then, ParcPlace has done whatever it felt like with
ObjectWorks/VisualWorks, since they "owned" the spec, and other vendors
have stretched things even further.
I think it's fine to discuss Blue Book details from a historical point of
view, and I still point beginners to it as a good starting point (with the
warning that it describes NO CURRENT IMPLEMENTATION!)
Piercarlo, please stop reading about Smalltalk and go out and use it! I
agree that some of the terminology may be inaccurate, but it is being used
that way, and YOU AREN'T GOING TO CHANGE THAT -- so get on with your life!
Jan
Jan Steinman <jan.byt...@acm.org>
Barbara Yates <barbara.b...@acm.org>
2002 Parkside Ct., West Linn, OR 97068, USA +1 503 657 7703
Dave Buck
Piercarlo Grandi <pier...@sabi.demon.co.uk> wrote:
>>>> On 27 Nov 1995 09:56:16 -0500, bytes...@aol.com (Bytesmiths) said:
>Bytesmiths> There he goes again, folks! For some reason, the Smalltalk
>Bytesmiths> archaeologist Piercarlo Grandi is suffering from the
>Bytesmiths> delusion that his favorite tool for pointless argument,
>Bytesmiths> "Smalltalk-80: The Language," is somehow "_the_authoritative
>Bytesmiths> definition of the Smalltalk-80, version 2, language".
>
>This is not a delusion: if you could remember the contents of the book
>in question, this is what the book claims, and I have chosen to take
>that at face value.
The basic Smalltalk syntax has changed little since the publication of
the Blue Book. The only major changes are:
- addition of temporaries within blocks
- addition of double precision float literals
- support for class instance variables
- change of assignment symbol to :=
- underscores are now allowed in identifiers
There may be a few other changes that I can't remember right now. The
class library, however, has changed dramatically. The UI classes are
all changed, Forms don't exist any more, the behavior hierarchy has
changed, screens and windows are completely changed, double precision
floats have been added and many more.
>Bytesmiths> This may be true for Smalltalk-80,
>
>So, make up your mind (if any, and not null or void): either I suffer
>the delusion that a book with a title like "Smalltalk-80: The Language"
>by Goldberg and Robson is the definition of Smalltalk-80, or it is not a
>delusion.
The point is that Smalltalk-80 documents an old version of the language.
>Bytesmiths> but it is utterly irrelevant.
>
>I think here we hear the voice of ignorance speaking. Since you have
>been caught out several times as not "remembering" the contents of this
>book, now you claim it is irrelevant. That's a very convenient position.
I don't think anyone else on this forum would ever consider calling
Jan Steinman "ignorant". Jan is very highly respected in the
Smalltalk community. If I were you, I wouldn't be so quick to make
judgements and to post inflamatory remarks about people who may have
disagreements with you.
>Bytesmiths> Since then, ParcPlace has done whatever it felt like with
>Bytesmiths> ObjectWorks/VisualWorks, since they "owned" the spec, and
>Bytesmiths> other vendors have stretched things even further.
>
>You are in effect claiming that there are no two truly compatible
>implementations of "Smalltalk", and that anybody choosing one is locked
>into a specific proprietary solution forever. If this is true, and in
>effect in part I tend to agree, it is the single best reason for people
>not to invest in Smalltalk that you could have found.
The same thing happened in the C world. For the longest time, the
de-facto standard was K&R C. This was actually a terrible dialect and
most venders ended up adding new extensions to it such as enums.
These additions were recognized and made official in the ANSI standard
and many new features were added.
>Think of it: either people who invest in Smalltalk can *rely* on what is
>written in "Smalltalk-80: The Language" as the _only_ vendor independent
>common base, or they are are the mercy of any vendor's policies and
>continued exitence.
No Smalltalk vender these days supports an underscore as the standard
assignment symbol (although some may have kept it as a carry-over from
the old days). No Smalltalk vender supports Forms, MVC as documented
in the Blue Book, fonts (as documented), pens, paths, bitblt, and so
on. With modern Smalltalks, the Blue Book is about half correct and
half incorrect. As such, it can't be trusted as a reference to the
language.
The standardization effort is an attempt to provide some level of
compatability between the different dialects, but only at a base
level. Even in the C++ world, you have no standard library to use for
windowing systems. Borland has OWL, Microsoft has MFC, and other
venders have other packages. Again, it's no different. If anything,
there's more commonality in Smalltalk than there is in C++.
David Buck
db...@ccs.carleton.ca
_________________________________
| David K. Buck |
| db...@ccs.carleton.ca |
| The Object People |
|_______________________________|
Dave Buck
Piercarlo Grandi <pier...@sabi.demon.co.uk> wrote:
>>>> On Tue, 28 Nov 1995 05:01:41 GMT, db...@superior.carleton.ca (Dave
>>>> Buck) said:
>Dave> For the longest time, the de-facto standard was K&R C.
>
>De jure, de facto -- the important thing being that if you wrote to K&R
>C your programs were portable and you had not sold your soul to a
>vendor; if you did not, you were owned by a particular vendor.
I can tell you from presonal experience that K&R C was FAR from
standard. Each dialect had its own unique quirks and porting from one
to the other was extremely difficult to maintain. I could give you
several examples but I'm not interested in discussing C in this group.
>Dave> Even in the C++ world, you have no standard library to use for
>Dave> windowing systems. Borland has OWL, Microsoft has MFC, and other
>Dave> venders have other packages. Again, it's no different. If
>Dave> anything, there's more commonality in Smalltalk than there is in
>Dave> C++.
>
>Ah please, don't shift the discussion: we are not talking of the
>library: we are talking of the _language_.
I just finished saying that the "language" Smalltalk has barely
changed since the Blue Book. It's the libraries that have changed.
>I have not made an issue of GUI libraries, or pens, or fonts, or
>whatever, important issues as they are practically, but of things like
>multiple/single inheritance, a single-rooted inheritance hierarchy or a
Smalltalk has always had single inheritance in the language itself.
The only multiple inheritance it ever had was added as a library
facility and was later removed.
>multi-rooted one, inheritance or general delegation, and similar
>_language level_ issues, which affect how one structures programs in
>general.
These are questions of design, not language.
>And please let me repeat: anybody investing in Smalltalk that is being
>persuaded by you and Jan and the others that it is not an "open"
>language, but a set of proprietary and incompatible products, would be
>very daring indeed to buy a proprietary Smalltalk from anybody but IBM,
>who is the only Smalltalk supplier whose middle and long term existence
>can be presumed safely.
Groundless scare tactics.
Piercarlo Grandi
>>> Buck) said:
pcg> either I suffer the delusion that a book with a title like
pcg> "Smalltalk-80: The Language" by Goldberg and Robson is the
pcg> definition of Smalltalk-80, or it is not a delusion.
Dave> The point is that Smalltalk-80 documents an old version of the
Dave> language.
It may be old, say like Ada 83, or FORTRAN 77, but is it, like them, a
language definition that is still valid as a vendor-independent
portability standard?
Or if there is a new, updated, Smalltalk-95, where is this defined
and/or implemented?
If there is no language today that is compatible with Smalltalk-80, or
no two versions of Smalltalk are compatible with each other, then any
discussion of what Smalltalk is seems rather irrelevant, and many people
investing in Smalltalk will think twice before sinking money in a
language without a commonly agreed definition.
Bytesmiths> Since then, ParcPlace has done whatever it felt like with
Bytesmiths> ObjectWorks/VisualWorks, since they "owned" the spec, and
Bytesmiths> other vendors have stretched things even further.
pcg> You are in effect claiming that there are no two truly compatible
pcg> implementations of "Smalltalk", and that anybody choosing one is
pcg> locked into a specific proprietary solution forever. If this is
pcg> true, and in effect in part I tend to agree, it is the single best
pcg> reason for people not to invest in Smalltalk that you could have
pcg> found.
Dave> The same thing happened in the C world.
This is entirely incorrect: there are dozens of large, freely available
programs that one can compile and run without modification on several
vendor platforms. A large part of the reason for which C and C++ are
popular (other than the curricula of most CS courses) is that there is a
definition against which one can write vendor-independent applications,
or at least know _where_ they are vendor dependent.
Dave> For the longest time, the de-facto standard was K&R C.
De jure, de facto -- the important thing being that if you wrote to K&R
C your programs were portable and you had not sold your soul to a
vendor; if you did not, you were owned by a particular vendor.
Dave> This was actually a terrible dialect
Think again: the whole of Unix (actually several versions), and
compilers, and many tools, was written in it, and fairly easily. ANSI C
is not very different from K&R C (mostly volatile, prototypes, some
change in arithmetic expression evaluation), and some people still write
K&R C by default.
Dave> and most venders ended up adding new extensions to it such as
Dave> enums. These additions were recognized and made official in the
Dave> ANSI standard and many new features were added.
Let's pick nits: Both of these comments are incorrect: enums were in K&R
itself (in an appendix), and the other additions were from C++
(prototypes) and invented out of the blue (volatile).
Still, if you have nothing but K&R, you can even today write a large,
working C program.
Besides any analogy between C and Smalltalk as to "standards" cannot be:
until ANSI C became widely implemented, K&R continued as _the_ standard.
Here instead people are arguing that Smalltalk-80 is not just any longer
the standard, and thus irrelevant, but that there is currently _no_
standard, for all the products marketed as being "Smalltalk" are
fundamentally incompatible _both_ with Smalltalk-80, to the point where
they cannot run Smalltalk-80 programs, and with each other, to the point
where switching suppliers is a major investment.
pcg> Think of it: either people who invest in Smalltalk can *rely* on
pcg> what is written in "Smalltalk-80: The Language" as the _only_
pcg> vendor independent common base, or they are are the mercy of any
pcg> vendor's policies and continued exitence.
Dave> No Smalltalk vender supports Forms, MVC as documented in the Blue
Dave> Book, fonts (as documented), pens, paths, bitblt, and so on.
These are all part of the environment...
Dave> With modern Smalltalks, the Blue Book is about half correct and
Dave> half incorrect. As such, it can't be trusted as a reference to
Dave> the language.
^^^^^^^^^^^^
Let's assume this is true -- what is the reference to the language? If I
want to write a portable Smalltalk program, and I ask myself 'is this
part of "Smalltalk"?' where do I find an answer? Or "anything goes" is
the answer?
Dave> The standardization effort is an attempt to provide some level of
Dave> compatability between the different dialects, but only at a base
Dave> level.
Here you seme to be arguing that any definition of what "Smalltalk"
amounts to is currently impossible, because we need to wait for the
future ANSI standard to give even a _base level_ notion of
compatibility.
Dave> Even in the C++ world, you have no standard library to use for
Dave> windowing systems. Borland has OWL, Microsoft has MFC, and other
Dave> venders have other packages. Again, it's no different. If
Dave> anything, there's more commonality in Smalltalk than there is in
Dave> C++.
Ah please, don't shift the discussion: we are not talking of the
library: we are talking of the _language_.
I have not made an issue of GUI libraries, or pens, or fonts, or
whatever, important issues as they are practically, but of things like
multiple/single inheritance, a single-rooted inheritance hierarchy or a
multi-rooted one, inheritance or general delegation, and similar
_language level_ issues, which affect how one structures programs in
general.
Suppose I wrote: "Smalltalk-NeXT is a superset of ANSI C". Where is the
authoritative reference against which this statement can be debated for
or against?
Or is any discussion of Smalltalk void and null, and Smalltalk is just a
buzzword on which project managers are asked to risk their jobs?
And please let me repeat: anybody investing in Smalltalk that is being
persuaded by you and Jan and the others that it is not an "open"
language, but a set of proprietary and incompatible products, would be
very daring indeed to buy a proprietary Smalltalk from anybody but IBM,
who is the only Smalltalk supplier whose middle and long term existence
can be presumed safely.
Try to imagine somebody who has implemented a trading system in
"Smalltalk-X" explaining to a bank director that since Supplier X has
disappeared, their trading system will have to be rewritten, with a
delay of several months on competitors, or missing the deadline on some
compliance requirement, if new functionality is needed that requires a
switch to another vendor's more upt-to-date product.
Since nobody wants to be in that position, they will either switch to
C++ or will buy Smalltalk from IBM.
I can see why (other than to cover up some of his bizarre past
statements) Jan has been arguing that the vendor neutral Smalltalk-80
base is in fact inexistent and to all practical purposes Smalltalk is
IBM's Smalltalk.
John Woods
You write:
[of Jan Steinman's post]
>I think here we hear the voice of ignorance speaking. Since you have
>been caught out several times as not "remembering" the contents of this
>book, now you claim it is irrelevant. That's a very convenient position.
Jan Steinman may not have been polite to you, but that's because
you've exhausted his patience --- and you haven't been very polite to
him, either.
I know neither of you personally, but can vouch for Jan Steinman, who
has posted here frequently, as being extremely helpful --- a
combination of knowledgability and friendliness. I have to say that
the impression I gain from your posts appears to be somewhat
different.
Your suggestion that he is ignorant breaches net.etiquette, but also,
I would think, runs counter to the experience of most c.l.s. readers.
If you are able to change the tune of this discussion from
confrontational back to conversational, you will be rewarded with the
respect of many c.l.s. readers, and may find that even if there is no
progress towards a resolution, the information content of the exchange
will be enriched, to everyone's benefit including, dare I say, yours.
.... John Woods
--
"
Forsan et haec olim meminisse iuvabit (Virgil)
[approx] Tr: The time may come when we will look back on these days and laugh
"
Bytesmiths
"Smalltalk has always had single inheritance in the language itself.
The only multiple inheritance it ever had was added as a library facility
and was later removed."
Minor quibble: multiple inheritance was part of the delivered image in
Smalltalk-80v2, as well as the first one or two releases from Tek until we
ripped it out. (Wasn't it Dan Ingalls who did added it in a weekend or so
to win a bet or something? :-)
Now, was this part of the "language," or part of the "library?" The
distinction blurs when you're meta-programming! Certainly the presense of
MI changed the syntax of Smalltalk with the "Class.method" notation, so it
could be argued that it was a part of the Smalltalk-80 "language" of the
day.
But I suppose Piercarlo Grandi will come back and say this didn't really
exist, because it wasn't documented in the Beloved Blue Book...
John Sellers
Gee whiz, this looks like fun. I think I will dive in. :-)
My experience with Smalltalk has been that every project that I worked on
was difference from the previous project because of changes in the library.
This includes changes at the system level.
Smalltalk-80 is so called because it existed in 1980. There was supposed to
be a Smalltalk-8? but there never was, the original name was kept until it
decided to become Object Works, then Visual Works. Actually after the '81
Byte Articles were written, the Xerox Park Smalltalk group got raided by
various other companies and so between writing books and short staff they
never came out with the next version...which was supposed to have some kind
of automatic typing mechanism among other things. Note that Smalltalk has
changed a lot and in many ways since the time of the Blue Book.
To choose the Blue Book as a standard is silly. End of story. I do not
know how the decision to pick the Blue Book as a standard, but I do know
that it was driven by marketing so they could say they had a standard rather
than by a high level of expertise based on the state of the art of the
technology.
Now...what should be used as a "standard"? There are a several constraints.
It should be based on what is real, what is out there, and what is most
widely used. A standard should be in place to solve real issues. What
issues does the Blue Book address? Second besides the pragmatics, it should
be based on tried and true quality technology. Well Smalltalk certainly has
some of the best things in the industry in it, but it has its warts.
Smalltalk is weak in ways which need to be solved. Smalltalk SHOULD change
in various regards. Tighter deliverables and difficulty of event debugging
come to mind as examples.
I think the time is ripe for the "next" Smalltalk, one that is based on the
best that we know today. One which is generally tighter and cleaner than
the current Smalltalks. There is plenty of trash code in the versions that
are out there today. There is plenty of room for a better language than
anyone is doing today (anywhere). Why? Let me put it this way, how many
times have you done something in Smalltalk which didn't work the way you
expected because of some lack of consistency? My experience is every time I
tread on new ground the chances are good that such will happen. Is it
possible to write classes so that they work consistently to ALL outward
appearances? YES YES YES YES YES!...however it takes being aware of a
little more than what is right under your nose...like a good understanding
of the parts of the system which there are possible intersections, and that
those parts of the system themselves are consistent. It also takes other
things. How many classes can you "break", without hardly any effort? Is it
possible to write classes that are almost unbreakable? YES!!!! CAN'T YOU
SEE THE PRODUCTIVITY GAINS OF A COMPLETELY CONSISTANT SMALLTALK
SYSTEM?...Thousands of programmers out there ALL SAVING TIME AND EFFORT.
>>>REGARDLESS OF THE COST AND EFFORT IT WOULD TAKE TO IMPLEMENT SUCH A
SMALLTALK<<< Anyone who actually goes out and does this would become 10
times richer than anyone currently in the Smalltalk community.
Also it has been quite a while since there have been any BIG breakthroughs
in the Smalltalk technology. There ARE breakthroughs out there to be had by
those who are more interested in doing a good job rather then filling their
pockets with tainted cash (eg. we fooled them [ourselves], they [we] bought
it: hook, line, and sinker). Understand I am not especially picking on
Smalltalk about this. This seems to be the general mode of Industry.
Changes in the language could improve the ease of development considerably.
For example, if Smalltalk were improved so that it had true reflection, it
would be possible to design an architecture for a development environment
which in some respect was "complete" in respect to the development process
(the developer is the customer, in the style of Dr. Deming)...that is to
say, where nothing is overly difficult that we won't immediately fix, and
where the mapping of the tools at hand would completely cover the
development aspects for the problem domains to be addressed. This would
have to be done systematically rather than ad hoc as is generally the case
in Industry today. Difficult? You bet. Worth it? Certainly, if one would
REALLY like to take over the world based on merit.
Why reflection? Because then it would be easier to get classes to answer
the question: "What am I? Do I have everything I need to be functional?
What do I need to work? What should I be that I am not?". This would also
allow developers to peak in on the applications they are developing in a
more comprehensive manner and maybe answer questions like: "Can I really be
sure this is going to work?", or "Is this like any mistake I have previously
made?", or "How do I figure all of the stuff out?".
So I dream on...it feels good to sound off (again). I think I will go pet
my cat and let somebody else play.
Jonathan Wong
pcg> either I suffer the delusion that a book with a title like
pcg> "Smalltalk-80: The Language" by Goldberg and Robson is the
pcg> definition of Smalltalk-80, or it is not a delusion.
Dave> The point is that Smalltalk-80 documents an old version of the
Dave> language.
pcg> It may be old, say like Ada 83, or FORTRAN 77, but is it, like
them, a
pcg> language definition that is still valid as a vendor-independent
portability standard?
The problem with this discussion, and most uninformed disussions about
Smalltalk in general, is that it assumes Smalltalk-80 describes a
language, and only a language. In reality, less than 5% of Smalltalk-80
describes a language, the other 95% describes an environment. Further
confusing this issue, is that the book itself doesn't clearly
distinguish the language from the environment.
Having used all three of the major vendors, I'd have to say that their
implementation of the language is 99.9999% compatible. :-) I'd also
have to say that none of the vendors implements anywhere near _all_ of
the environment described in Smalltalk-80, however, the base
environment, not including any GUI or application aspects, is about 85%
compatible between all the versions of Smalltalk that I have used, and
with Smalltalk-80.
I have also seen documents describing the common aspects, including
the base environment, between two of the major Smalltalk implementations
sufficiently to write portable code between them. Unfortunately, I
don't believe these have been published.
pcg> Or if there is a new, updated, Smalltalk-95, where is this defined
pcg> and/or implemented?
An ANSI committee, which includes all the major vendors, is working on
a _standard_ definition of the language including a definition of the
base environment.
pcg> If there is no language today that is compatible with Smalltalk-80,
or
pcg> no two versions of Smalltalk are compatible with each other, then
any
pcg> discussion of what Smalltalk is seems rather irrelevant, and many
people
pcg> investing in Smalltalk will think twice before sinking money in a
language without a commonly agreed definition.
Again, it depends on what you're talking about with regard to
compatibility. The languages are 99.999% compatible. It is
quite possible to write Smalltalk programs that are "language
compatible" and even "base environment compatible". I have worked
on a system that was developed by myself and others concurrently in
two different vendor versions of Smalltalk, and by that I mean that
I personally developed in the two different versions concurrently on
a common code base! 95% of this code was common, the 5% that was
different was only in the interface to a C language library.
Dave> Even in the C++ world, you have no standard library to use for
Dave> windowing systems. Borland has OWL, Microsoft has MFC, and other
Dave> venders have other packages. Again, it's no different. If
Dave> anything, there's more commonality in Smalltalk than there is in
Dave> C++.
pcg> Ah please, don't shift the discussion: we are not talking of the
pcg> library: we are talking of the _language_.
The vast majority of applications, today, must interface through a
library to a GUI window system. Choosing a "standard" language doesn't
practically help you in porting these applications to a different
vendor's environment. C++ is standard, but choosing a specific vendor
library to implement my application effectively locks me to that vendor
as much as if the languages between vendors was completely different.
As a matter of fact, I have seen an implementation of one of the
Smalltalk vendor's GUI under two of the other vendor's Smalltalk
systems.
There is nothing that technically prevents any vendor from implementing
this part of the environment under their competitors' systems.
Jonathan Wong
Piercarlo Grandi
>>> said:
pcg> I think here we hear the voice of ignorance speaking. Since you
pcg> have been caught out several times as not "remembering" the
pcg> contents of this book, now you claim it is irrelevant. That's a
pcg> very convenient position.
John> Your suggestion that he is ignorant breaches net.etiquette, but
John> also, I would think, runs counter to the experience of most
John> c.l.s. readers.
I have not written that he is ignorant -- I don't know about his
qualifications or background. Your intimation that I suggest he is
ignorant is a fantasy. I have however remarked that he has written some
ignorant comments, and that he has been trying to cover them up.
Jan has has been making grave mistakes like confusing the properties of
a language with those of its implementation, which is a distinction that
is taught, I am told (I did economics) in undergraduate CS courses. He
has been making this confusion, the more ignorantly, with self-assured
gumption and condescending presumption:
Jan> Although I don't disagree with his basic argument that Smalltalk
Jan> can at some level be considered to have types, Piercarlo Grandi
Jan> is seriously misinformed when he asserts that:
"behaviour depends _uniquely_ on the methods implemented for the
class, at least in Smalltalk-80"
Jan> which of course is utter nonsense to anyone who has implemented
Jan> general delegation, or has played with "thisContext" or
Jan> light-weight classes.
Jan> The AutoRecord class I posted here some time back, for example,
Jan> exhibits instance-specific behavior, behavior which is utterly
Jan> dependent on "the specific selector that names the method," which
Jan> Piercarlo asserts cannot be so.
Jan> (Some advice to Piercarlo -- drop the high-minded, know-it-all
Jan> attitude, and you just might learn something! :-)
Please note that, as I have proven beyond doubt, by quoting its manual,
that in fact _at least in Smalltalk-80_ behaviour depends uniquely on
the methods implemented for the class, _by design_.
Jan's reply to this has not been, perhaps because he is above such petty
details, to admit that he no longer remembers what Smalltalk-80 is
about, being engrossed in his own little Smalltalk-of-the-day
enhancements, or that (rather less plausibly) he had not noticed that I
had qualified my statement with "at least in Smalltalk-80".
Oh no! He has been trying to argue that even if I am right with respect
to Smalltalk-80, as I have proven to be, the latter is irrelevant (a
contention that not only is arguably incorrect, but also "politically"
dangerous), with a characteristic decoration of some more gratuitously
arrogant verbiage.
Which is of course what really riles me -- that he is trying to
upstage me ;-).
Whether Smalltalk-80 is irrelevant or not, was indeed not the issue, the
issue was whether the phrase I wrote was or was not, as it stood, utter
nonsense as he claimed, or whether what he wrote was ignorant as I have
bene able to prove by quoting the Smalltalk-80 book.
Not only his words above, and those he has expended subsequently, sound
arrogant as well as being ignorant; his attempt to cover his (perhaps
occasional) display of ignorance behind a change of subject, instead of
apologizing for his mistaken and patronizing remarks, could be regarded
as quite sleazy.
Good for him -- he must be very proud of his tactics. He has also found
a defender, a character witness no less, in you:
John> I know neither of you personally, but can vouch for Jan Steinman,
John> who has posted here frequently, as being extremely helpful --- a
John> combination of knowledgability and friendliness.
As to this I have no reason to doubt that he has been helpful with
suggestions and help in general; perhaps he is generally quite a genial
person, and perhaps he does know the mechanics of some "modern
Smalltalk" (whatever that is and which is not at all like Smalltalk-80)
implementations.
I can only take issue with what I read, which gives a different
impression from what you write, but perhaps atypical -- he may well be
going thru a period of bad mood and memory -- I know nothing of Jan's
professional competence, or his character, beyond the exchanges we have
here, on which I have commented.
Bytesmiths
"I have also seen documents describing the common aspects, including
the base environment, between two of the major Smalltalk implementations
sufficiently to write portable code between them. Unfortunately, I don't
believe these have been published."
The IBM "Red Book" (which PK dismisses because it happens to be published
by a Smalltalk vendor) is a pretty good start, and has been an important
input to the X3J20 committee. It begins with:
"This publication is intended to help the customer develop portable
applications using the Smalltalk language."
and later in the Preface states:
"This document is intended to provide... a minimal base of the classes
and methods that are common to all Smalltalk implementations."
"Smalltalk Portability: A Common Base" (AKA "The Red Book"), IBM
International Technical Support, 1992. (Sorry, I have what is surely an
illegal photocopy with the CUIP info missing -- anyone have a reference
suitable for taking to a book store?)
Incidentally, this document was also one of the major inputs to the
implementation of the base Smalltalk underlying VisualAge.
Steve Barber
>In their switch I suspect that the Smalltalk group were heavily
>influenced by the (Inter)Lisp group (viceversa happened too): after all
>Smalltalk-80 is actually an OO Lisp, but for the slightly odd :-)
>unlisp-like syntax (another similar, more lisp-looking system, was
>MDL/Muddle from the MIT LCS PRG).
>
Not that it's that relevant to the semantics of Smalltalk discussion,
but my recollection from spending two years ('82 & '83) working in the MDL group
at MIT LCS is that MDL is basically a Lisp with types, and not particularly
object-oriented in the sense that this much-discussed term is used today.
Certainly things could have changed since then.
(I'd love to hear from anybody who knows about the fate of MDL; it's been
quite a while since I even thought about it.)
-Steve Barber
Fusion Systems Group
New York
Piercarlo Grandi
Piercarlo> "behaviour depends _uniquely_ on the methods implemented
Piercarlo> for the class, at least in Smalltalk-80"
Jan> which of course is utter nonsense to anyone who has implemented
Jan> general delegation, or has played with "thisContext" or
Jan> light-weight classes.
Piercarlo> Please note that, as I have proven beyond doubt, by quoting
Piercarlo> its manual, that in fact _at least in Smalltalk-80_ behaviour
Piercarlo> depends uniquely on the methods implemented for the class,
Piercarlo> _by design_.
To clarify: I have not claimed that one cannot add delegation or
whetever to Smalltalk-80, using Smalltalk-80's own primitives; simply
that in it, _as designed_, the "type"/"kind" of an object depends
uniquely on its class. Not on whatever selectors, ...
Piercarlo Grandi
>>> Buck) said:
[ .. among some comments I quite disagree with, but that I am
uncharacteristically letting pass ... ]
pcg> And please let me repeat: anybody investing in Smalltalk that is
pcg> being persuaded by you and Jan and the others that it is not an
pcg> "open" language, but a set of proprietary and incompatible
pcg> products, would be very daring indeed to buy a proprietary
pcg> Smalltalk from anybody but IBM, who is the only Smalltalk supplier
pcg> whose middle and long term existence can be presumed safely.
Dave> Groundless scare tactics.
Far from it -- that is how the IT market has been like for thirty
years. Until relatively recently when open systems have become fairly
common, most corporate users would only risk their jobs on IBM kit and
sw. If there are only proprietary solutions, mere herd instinct results
in the biggest player dominating and setting the "standard".
Arguing that there is no common, openly defined, ground (yet), between
he various proprietary "Smalltalks", runs a serious risk of resurrecting
the bad old times of "nobody ever got fired for buying IBM's (Smalltalk)".
IBM have a good product, they have relatively rapidly achieved an
excellent market penetration, they have initiated the work of
standardizing Smalltalk largely around their own version (I imagine with
some embarassment at ParcPlace), let's not concede them the
psychological advantage too.
BTW: I have no interests whatsoever in any particular Smalltalk; I
simply like the idea that there is an openly described, effectively
non-proprietary, Smalltalk specification, even if it is/ought be a
subset of that is available today, as K&R and ANSI C are wrt say
Microsft C or GNU C.
Piercarlo Grandi
John> Gee whiz, this looks like fun. I think I will dive in. :-)
The brave man! :-)
John> My experience with Smalltalk has been that every project that I
John> worked on was difference from the previous project because of
John> changes in the library. This includes changes at the system
John> level.
This is in part a benefit, in part a problem. The benefit is of course
customizability, the problem is of course importability. Research
usually leans towards one end of the spectrum, industrial use towards
another. It is in part a pity that the Smalltalks out there today are
not (yet) leaning towards the more industrially useful part of that
continuum (a problem that has been solved years ago in the Common Lisp
community).
John> Smalltalk-80 is so called because it existed in 1980. [
John> ... agreeable historical observations ... ] Note that Smalltalk
John> has changed a lot and in many ways since the time of the Blue
John> Book.
But currently (and since the very beginning too, given the very
different flavours of -72, -74, -76, -78 and -80) there is no
"Smalltalk", there are many "Smalltalks" (including Smalltalk-NeXT,
which includes ANSI C as a subset :->).
John> To choose the Blue Book as a standard is silly. End of story.
To choose it as a standard _today_ would be silly; the problem is that
_today_ there is no alternative, so one has the choice of either making
sense debating Smalltalk-80, which is a name with a specific referent,
or not making discussing "Smalltalk", which is a name with no obvious
referent.
The impossibility of having a discussion about "Smalltalk" is why I
regularly qualify my assertions as "at least in Smalltalk-80". I could
qualify them as "at least in Smalltalk-V", or "at least in VisualAge
Smalltalk", or so on, but I prefer Smalltalk-80 simply because the
others are proprietary, and not as widely known. Everybody ought :-) to
know Smalltalk-80, whatever current dialect one is using.
John> I do not know how the decision to pick the Blue Book as a
John> standard, but I do know that it was driven by marketing so they
John> could say they had a standard rather than by a high level of
John> expertise based on the state of the art of the technology.
But the decision by many implementors to be as close as possible to
Smalltalk-80 was not silly: it is indeed widely published, and besides
it is not that bad a _base_: one can still build a lot of interesting
things that have Smalltalk-80 as a subset.
John> [ ... ] Smalltalk is weak in ways which need to be solved.
John> Smalltalk SHOULD change in various regards. Tighter deliverables
John> and difficulty of event debugging come to mind as examples.
But of course (even if some products do deliver fairly tight
deliverables already). The problem is as always "which Smalltalk"!
There has been an Ada-83, and now there is an Ada-95. An update of
Smalltalk-80 is long overdue, and the ANSI committee is trying to
deliver it.
John> I think the time is ripe for the "next" Smalltalk, one that is
John> based on the best that we know today. One which is generally
John> tighter and cleaner than the current Smalltalks. There is plenty
John> of trash code in the versions that are out there today. There is
John> plenty of room for a better language than anyone is doing today
John> (anywhere).
Actually I submit that there is one already, and is called
Smalltalk-Self :-).
Or perhaps that other one, Smalltalk-CLOS. Or even, for those that
like stability/backwards compatibility more than anything else,
Smalltalk-NeXT :-)
John> Changes in the language could improve the ease of development
John> considerably. For example, if Smalltalk were improved so that it
John> had true reflection, [ ... ] Difficult? You bet. Worth it?
John> Certainly, if one would REALLY like to take over the world based
John> on merit.
I think that could be dangerous to the deliverable story... And that
Smalltalks already have _a lot_ of reflection, if in very nonstandard
ways. Perhaps you really want to say "Standardized reflective
facilities".
Piercarlo Grandi
Dave> "Smalltalk has always had single inheritance in the language
Dave> itself. The only multiple inheritance it ever had was added as a
Dave> library facility and was later removed."
Jan> Minor quibble: multiple inheritance was part of the delivered image
Jan> in Smalltalk-80v2, as well as the first one or two releases from
Jan> Tek until we ripped it out. (Wasn't it Dan Ingalls who did added it
Jan> in a weekend or so to win a bet or something? :-)
Jan> Now, was this part of the "language," or part of the "library?"
Neither: it was a language extension implemented on top of the standard
virtual machine.
Jan> The distinction blurs when you're meta-programming! Certainly the
Jan> presense of MI changed the syntax of Smalltalk with the
Jan> "Class.method" notation, so it could be argued that it was a part
Jan> of the Smalltalk-80 "language" of the day.
Yes, it's part of the language, but of "Dan's Smalltalk" language of the
day.
Jan> But I suppose Piercarlo Grandi will come back and say this didn't
Jan> really exist, because it wasn't documented in the Beloved Blue
Jan> Book...
Well, just to show that I am not obsessed with it :->, it's Green Book
"Smalltalk-80: Bits of history, words of advice" time instead:
* _Multiple Inheritance_ While Smalltalk-80 does not provide for
multiple inheritance, we have described an experimental system
which supports multiple superclasses using the standard
Virtual Machine[10]. This is another area in which serious use
of the new paradigm might suggest useful changes to the
Virtual Machine.
This is on on page 22, in the article "The evolution of the Smalltalk
Virtual Machine" by Dan Ingalls. :-)
Clearer than this...
Rick DeNatale
<wo...@integral.com> wrote:
>I'm coming to this thread late, and hopefully, I can offer something.
>
>pcg> either I suffer the delusion that a book with a title like
>pcg> "Smalltalk-80: The Language" by Goldberg and Robson is the
>pcg> definition of Smalltalk-80, or it is not a delusion.
>
>Dave> The point is that Smalltalk-80 documents an old version of the
>Dave> language.
>
>pcg> It may be old, say like Ada 83, or FORTRAN 77, but is it, like
>them, a
>pcg> language definition that is still valid as a vendor-independent
>portability standard?
>
>
>The problem with this discussion, and most uninformed disussions about
>Smalltalk in general, is that it assumes Smalltalk-80 describes a
>language, and only a language. In reality, less than 5% of Smalltalk-80
>describes a language, the other 95% describes an environment. Further
>confusing this issue, is that the book itself doesn't clearly
>distinguish the language from the environment.
I've stepped out of this discussion for a while, but I've been following
it with a mixture of chagrin, amazement and dismay.
Jonathon points out the problems with uninformed (or maybe we should say
partially informed) discussions about languages. It reminds me of a recent
experience in a bar in Eastern Europe. The participants were another
American who lives in Paris but speaks no French, a French friend of mine,
and me. The conversation went something like this:
The Other American (OA): You don't need to speak any other language
besides English.
"Typical American Conventional Wisdom"
OA: But people who speak certain languages can't form certain thoughts.
ME: Oh?!
OA: For example there is no way to say "I like you" in French.
My French friend, being diplomatic, says nothing. After all
French is the language of diplomacy, n'est pas? I'm thinking "1. Yes you
can (my friend and I had discussed this very point just a day or two
before) and 2. Is this guy really saying you can't be subtle in French,
C'est incroyable!"
OA: And the Japanese don't have a word for no.
ME: (At this point I can't hold my tongue any longer) Yes they do! It's 'ie'.
(And there are other variations such as 'dame', but that would
mean that you could be subtle in Japanese too!)
OA: No they don't! And they don't have a way to say "I don't understand you"
ME: Yes they do it is "Wakari masen"
OA: No they don't.
At this point I gave up.
So we have an example of someone who apparently has a surface
understanding of some languages, which he doesn't speak, based on reading
a few things, and confusing syntax, semantics and culture.
The preceding traffic in this thread has followed a similar pattern. We've
had someone whose knowledge is apparently based on reading the purple
book, arguing with many people such as Dave Smith, Jan Steinman and
others, who I know to be fluent speakers of the language. Unlike mon amie
francaise, and like me they lacked the diplomacy to restrain themselves
from trying to point out the finer points of the language as it is
practiced today.
This is not intended to be a slam at anyone, I'm sure that everyone
involved in this discussion is a gentleperson, and is quite expert in
differing areas. However, the conversation has bogged down into the
problems of the tower of Babel.
Taking one book, no matter how seminal, and despite it's claims of
authority at the time of its publication, as the complete definition of
Smalltalk as it exists and is used today just doesn't square with the
facts.
In an earlier posting, PCG quibbled with the basic definitions of things
like messaging as given in "Smalltalk-80: The Language". This is
something that people do all the time, in the face of something that has
some resemblances to things they already know, but puts different
interpretations on certain things, there is a human tendency to ignore or
dismiss the subtle differences which make all the difference in the world.
>
>Having used all three of the major vendors, I'd have to say that their
>implementation of the language is 99.9999% compatible. :-) I'd also
>have to say that none of the vendors implements anywhere near _all_ of
>the environment described in Smalltalk-80, however, the base
>environment, not including any GUI or application aspects, is about 85%
>compatible between all the versions of Smalltalk that I have used, and
>with Smalltalk-80.
>I have also seen documents describing the common aspects, including
>the base environment, between two of the major Smalltalk implementations
>sufficiently to write portable code between them. Unfortunately, I
>don't believe these have been published.
Well, I was one of the main authors of an IBM Redbook called "Smalltalk
Portability: A Common Base" GG24-3903-00 which is available through IBM
for $20. Take a look at http://www.almaden.ibm.com/redbooks/
It is somewhat of an historical document, it is one of the documents
intially presented to X3J20 (along with Smalltalk-80: The language) for
consideration by the commitee. The current draft is a new work by the
committee.
>
>pcg> Or if there is a new, updated, Smalltalk-95, where is this defined
>pcg> and/or implemented?
>
>
>An ANSI committee, which includes all the major vendors, is working on
>a _standard_ definition of the language including a definition of the
>base environment.
>
>
>pcg> If there is no language today that is compatible with Smalltalk-80,
>or
>pcg> no two versions of Smalltalk are compatible with each other, then
>any
>pcg> discussion of what Smalltalk is seems rather irrelevant, and many
>people
>pcg> investing in Smalltalk will think twice before sinking money in a
>language without a commonly agreed definition.
>
>
>Again, it depends on what you're talking about with regard to
>compatibility. The languages are 99.999% compatible. It is
>quite possible to write Smalltalk programs that are "language
>compatible" and even "base environment compatible". I have worked
>on a system that was developed by myself and others concurrently in
>two different vendor versions of Smalltalk, and by that I mean that
>I personally developed in the two different versions concurrently on
>a common code base! 95% of this code was common, the 5% that was
>different was only in the interface to a C language library.
So the arguments, is that if we don't use Smalltalk-80: The languages,
then there is no common base for Smalltalk. As Jonathon rightly points
out, this isn't so. As a member of X3J20, I'm actively involved in
defining a standard. I've been amazed, but not really surprised, at the
level of agreement within the committee. The current (very initial)
commitee draft, can be obtained by request from Glenn Krasner at
ParcPlace-Digitalk.
PCG seems to take the position that Smalltalk is quite similar to C++ in
having a type hierarchy which is closely mapped to the inheritance
hierarchy. This just isn't true. The basic semantics of Smalltalk separate
the meaning of a particular message from the implementation hierarchy. Any
object can implement any selector. Inheritance is an implementation
artifact in Smalltalk. In fact, the position being taken in X3J20 is that
inheritance is up to the implementation. We are NOT defining a particular
implementation hierarchy. Instead we are defining a hierarchy of protocols
to which particular objects will conform. This means that conforming
implementations should not have to change their implementation
hierarchies, which do vary quite a bit, despite the fact that
implementations are 99.9999% compatible.
>
>
>Dave> Even in the C++ world, you have no standard library to use for
>Dave> windowing systems. Borland has OWL, Microsoft has MFC, and other
>Dave> venders have other packages. Again, it's no different. If
>Dave> anything, there's more commonality in Smalltalk than there is in
>Dave> C++.
>
>pcg> Ah please, don't shift the discussion: we are not talking of the
>pcg> library: we are talking of the _language_.
>
>
>The vast majority of applications, today, must interface through a
>library to a GUI window system. Choosing a "standard" language doesn't
>practically help you in porting these applications to a different
>vendor's environment. C++ is standard, but choosing a specific vendor
>library to implement my application effectively locks me to that vendor
>as much as if the languages between vendors was completely different.
And this too, agrees with what we are doing in X3J20. We are not
attempting to standardise higher level libraries like GUI support.
However, we do expect the standard to allow such standards to be hosted on
a standard implementation.
--
Rick DeNatale
Still looking for a cool signature ;-)
Piercarlo Grandi
Jonathan> I'm coming to this thread late, and hopefully, I can offer
Jonathan> something.
Another brave entrant :-)
pcg> either I suffer the delusion that a book with a title like
pcg> "Smalltalk-80: The Language" by Goldberg and Robson is the
pcg> definition of Smalltalk-80, or it is not a delusion.
Dave> The point is that Smalltalk-80 documents an old version of the
Dave> language.
pcg> It may be old, say like Ada 83, or FORTRAN 77, but is it, like
pcg> them, a language definition that is still valid as a
pcg> vendor-independent portability standard?
Jonathan> The problem with this discussion, and most uninformed
Jonathan> disussions about Smalltalk in general, is that it assumes
Jonathan> Smalltalk-80 describes a language, and only a language.
Sacred words! Jan take note :-). Indeed a lot of people do not clearly
distinguish between Smalltalk(-80) the language, the system, the virtual
machine, and make claims about Smalltalk(-80) the language when they are
really talking of the properties of either the system or the virtual
machine.
Jonathan> In reality, less than 5% of Smalltalk-80 describes a language,
Jonathan> the other 95% describes an environment.
Are your sure? Have your reread recently "The Language" or "The Language
and its implementation"? I have them by my side, and the page counts (a
good measure as any, I would surmise, are as follows:
"The Language" "The language and its implementation"
Language 84 84
System 465 444
Sample application
Implementation 5 153
I have included in the the page count for the system
It is not quite 5%, at least in Smalltalk-80, the books.
Jonathan> Further confusing this issue, is that the book itself doesn't
Jonathan> clearly distinguish the language from the environment.
Perhaps you should check again: on page vi of the preface of "The
language" I read:
"Part One -- an overview of the concepts and syntax of the
programming language.
Part Two -- an annotated and illustrated specification of the
system's functionality.
Part Three -- an example of the design and implementation of a
moderate-size application."
I also happen to be able to read on page 91 of "The Language":
"PART TWO
---------
Part One provided an overview of the Smalltalk-80 language both
from the semantic view of objects and message sending and from
the syntactic view of the form that expressions take. The
Smalltalk-80 programmer must first understand the semantics of
th language: that all information is represented in the form of
objects and that all processing is done by sending messages to
objects. Every object is described by a Class; every class, with
the exception of class Object, is a subclass of another
class." [ ... ]
Perhaps you should revise your paragraph above as follows:
Jonathan'> Further confusing this issue, is that even if the book itself
Jonathan'> clearly distinguishes the language from the environment and
Jonathan'> from the implementation, many people, including myself, have
Jonathan'> not read it yet, or have forgotten what's in it. Even worse,
Jonathan'> they post articles about it to comp.object, where a
Jonathan'> self-confessed language lawyer occasionally hangs around ;^).
Jonathan> Having used all three of the major vendors, I'd have to say
Jonathan> that their implementation of the language is 99.9999%
Jonathan> compatible. :-)
Jan Steinman and others are far less optimistic, for example:
Dave> With modern Smalltalks, the Blue Book is about half correct and
Dave> half incorrect. As such, it can't be trusted as a reference to
Dave> the language.
Jan> Since then, ParcPlace has done whatever it felt like with
Jan> ObjectWorks/VisualWorks, since they "owned" the spec, and other
Jan> vendors have stretched things even further.
Naturally I instead wish you are right: for if you are right and there
is almost absolute compatibility at the language level, and:
Jonathan> I'd also have to say that none of the vendors implements
Jonathan> anywhere near _all_ of the environment described in
Jonathan> Smalltalk-80, however, the base environment, not including any
Jonathan> GUI or application aspects, is about 85% compatible between
Jonathan> all the versions of Smalltalk that I have used, and with
Jonathan> Smalltalk-80.
Then my use of "Smalltalk-80: The Language" as the paragon has been
entirely justified, despite the protestations by many that it is
archeological only.
Jonathan> The vast majority of applications, today, must interface
Jonathan> through a library to a GUI window system. Choosing a
Jonathan> "standard" language doesn't practically help you in porting
Jonathan> these applications to a different vendor's environment.
Jonathan> C++ is standard, but choosing a specific vendor library to
Jonathan> implement my application effectively locks me to that vendor
Jonathan> as much as if the languages between vendors was completely
Jonathan> different.
It's not as gloomy as you depit it: because while GUIs are important,
without a common language one would not even have the choice of which
GUI API to lock oneself into. Also, if one does a properly encapsulated
OO application, one can strongly localize the calls to the particular
GUI's API, and in effect achieve, as you say, some sensible degree of
portability:
Jonathan> As a matter of fact, I have seen an implementation of one of
Jonathan> the Smalltalk vendor's GUI under two of the other vendor's
Jonathan> Smalltalk systems. There is nothing that technically prevents
Jonathan> any vendor from implementing this part of the environment
Jonathan> under their competitors' systems.
This is something that, wastefully, can well be done by the application
writer themselves.
While writing a GUI compatibility layer on top of a common language base
is at least *possible* for the application developer, if the common
language (and I would include here also the lowest layers of the system,
like the 'Object' class) base is not there, it is very hard for the
application developer to write a compatibility layer, notwithstanding
the reflective capabilities of many Smalltalk implementations.
Piercarlo Grandi
>>> DeNatale) said:
Rick> Taking one book, no matter how seminal, and despite it's claims of
Rick> authority at the time of its publication, as the complete
Rick> definition of Smalltalk as it exists and is used today just
Rick> doesn't square with the facts.
Then perhaps you have severe difficulties with reading what is before
your eyes on the screen: because as far as I know *nobody* has so far
stated or assumed that _any_ book is the "complete definition of
Smalltalk as it exists and is used today" (indeed I agreed with Jan
Steinman when he remarked that as yet there is no such book), or
anything even remotely resembling that.
In particular *I* have never written so. If you think somebody else has
written to this effect, please corroborate your assertion with a
quote. It is cheap and not very correct to leave allegations like yours
hanging in the air.
As to me, I have repeatedly stated that "Smalltalk-80: The Language"
claims to be the definition of _Smalltalk-80 (version 2)_, and that I
believe that claim, and that a non-proprietary definition of "modern
Smalltalk" does not yet exist, as Jan as remarked himself.
Alan Lovejoy
(Piercarlo Grandi) writes:
>I have written something about *Smalltalk-80*, as I have made clear
many
>times, not ``Smalltalk'', and I have _proved_ that classes are what
>computer science textbooks call types in other language, and this is
so
>by design, by quoting literally the book that describes Smalltalk-80,
>and also some popular definition of type, and anybody can then see
that
>they are equivalent.
But even in Smalltalk-80, as defined by the Blue Book, it is possible
to define two classes with different implementations, and different
inheritance hierarchies, which respond to exactly the same messages
with exactly the same semantics, preconditions and postconditions.
Instances of two such classes have the same "type" because they
respond to the same messages in the same way, but their classes are
different. This proves that a class is an implementation of a type--it
is not itself a type.
The ability to have multiple, diffrerent implementations of the same
"type" is one of the main motivations for OOP. The distinction between
type and class is necessary for polymorphism and the separation of
interface from mechanism. Because this is not possible in traditional
"value-oriented" languages, the distinction between "type" and "class"
is degenerate in those languages. But not in Smalltalk.
You can infer the type of an object from its class--but this inference
is not valid dynamically. The "type" of an object can change as
methods are added, removed and/or changed in the inheritance hierarchy
of its class.
And you positively cannot determine the class of an object by its type,
because the mapping from type to class is not one-to-one. And it is
usually bad practice to test the "type" of an object by testing its
class. Another class that implements the necessary type can be created
at any time--and the class(es) that used to implement the type may stop
doing so.
I would suggest reading the OOPSLA proceedings from the past ten years.
There have many papers presented there and elsewhere that address
these issues.
--Alan Lovejoy
Piercarlo Grandi
>>> DeNatale) said:
Rick> So we have an example of someone who apparently has a surface
Rick> understanding of some languages, which he doesn't speak, based on
Rick> reading a few things, and confusing syntax, semantics and culture.
This is indeed very true: many a participant in this thread (for
example, and I have alrady quoted him to this effect, Jan Steinman) has
difficulty distinguishing between language, system, virtual machine, and
even between Smalltalk-80 and whatever ``Smalltalk'' product is
installed on his machine today.
One could argue that this is not too bad in itself: after all
"Smalltalk"'s benefits flow from the whole. It becomes bad when it is
used in a debate about what is/is not there in the language.
Rick> The preceding traffic in this thread has followed a similar
Rick> pattern.
All too true.
Rick> We've had someone whose knowledge is apparently based on reading
Rick> the purple book,
Well, you are too pessimistic -- I am not the only one to have read it,
even if at times it looks as if it is the case. Instead of "someone" you
could write "some people".
Rick> arguing with many people such as Dave Smith, Jan Steinman and
Rick> others, who I know to be fluent speakers of the language.
Well, if you say so, of course -- anointment by you exempts from the
need to offer valid arguments. :-)
Yet there are a lot of fluent speakers of many languages that don't know
its grammar, and think that morphology is an illness -- and therefore
are howler-prone. That practitioners may well have a low level of
insight in what they do, and knowledge of "academic" material, is fairly
common in all disciplines. It become irritating when they mistake their
dexterity and fluency, if any, with understanding and knowledge, and
start making pronouncements that require the latter.
With a little application and by reading books (which is not a high
minded attitude as Jan and you seem to be thinking), which only requires
taking away some little time from playing around with your
Smalltalk-of-the-day, even you and Dave and Jan could evolve your
fluency into insight; I did it myself, at least in part, and it is not
too hard -- but then, as Jan correctly (for once :->) hinted, I haven't
got a real life that interferes.
In particular the "Smalltalk-80" series which I am happy to mention
often is rich with insight (not all of which I agree with), and by
finally getting around to reading those "archeological" books a number
of participants in this debate would spare me the need to type in so
many quotes.
Rick> Taking one book, no matter how seminal, and despite it's claims of
Rick> authority at the time of its publication, as the complete
Rick> definition of Smalltalk as it exists and is used today just
Rick> doesn't square with the facts.
Indeed! A point I have made myself many times. And that is the problem,
in part, for there is no "complete definition of Smalltalk as it exists
and is used today", unfortunately, nor even any real definition of
``Smalltalk'', a term that is used with such flexible nonchalance that
it's not possible to attach a referent to it, even if you make so much
use of it.
Rick> [ ... ] So the arguments, is that if we don't use Smalltalk-80:
Rick> The languages, then there is no common base for Smalltalk.
Primarily: "for a discussion about ``Smalltalk''".
Please note that I have characterized "Smalltalk-80: The Language", as a
widely available, detailed, published base for discussion (and to many,
for implementation too). There is simply nothing comparable as yet.
Rick> As Jonathon rightly points out, this isn't so.
You wish... I wish it too. But unfortunately a 12 year old book is what
we got, and we can give thanks it has aged so gracefully. According to
Jonathan Wong:
Jonathan> I'd also have to say that none of the vendors implements
Jonathan> anywhere near _all_ of the environment described in
Jonathan> Smalltalk-80, however, the base environment, not including any
Jonathan> GUI or application aspects, is about 85% compatible between
Jonathan> all the versions of Smalltalk that I have used, and with
Jonathan> Smalltalk-80.
and to Dave Buck:
Dave> The basic Smalltalk syntax has changed little since the
Dave> publication of the Blue Book. The only major changes are:
Dave> - addition of temporaries within blocks
Dave> - addition of double precision float literals
Dave> - support for class instance variables
Dave> - change of assignment symbol to :=
Dave> - underscores are now allowed in identifiers
Dave> There may be a few other changes that I can't remember right
Dave> now.
Rick> As a member of X3J20, I'm actively involved in defining a
Rick> standard. I've been amazed, but not really surprised, at the level
Rick> of agreement within the committee. The current (very initial)
Rick> commitee draft, can be obtained by request from Glenn Krasner at
Rick> ParcPlace-Digitalk.
So, a "(very initial)" draft that "can be obtained by request" is a
common base definition? Frankly I think that the Red Book that you also
mention might be a more defensible idea. At least it's published, and
IBM has branches everywhere.
Rick> PCG seems to take the position that Smalltalk is quite similar to
Rick> C++ in having a type hierarchy which is closely mapped to the
Rick> inheritance hierarchy.
This is a fabrication: please find anywhere where I have written this
inanity.
It is an inanity: because "Smalltalk" is such a loose term that any
attempt to claim "Smalltalk" has any given feature is meaningless, as
one can easily find both examples and counterexamples in something with
"Smalltalk" in its name.
I have written something about *Smalltalk-80*, as I have made clear many
times, not ``Smalltalk'', and I have _proved_ that classes are what
computer science textbooks call types in other language, and this is so
by design, by quoting literally the book that describes Smalltalk-80,
and also some popular definition of type, and anybody can then see that
they are equivalent.
I have already stated rather explicitly that I have never taken the
position you attribute to me, and repeating the allegation even if
prefixed with "seems" is rather disingenuous, for I have been very
clear.
If one produces the description of a Smalltalk-of-the-day, even one
based on a modification of the original Smalltalk-80 then of course:
Rick> This just isn't true. The basic semantics of Smalltalk separate
^ "Rick's Own"
Rick> the meaning of a particular message from the implementation
Rick> hierarchy.
Rick> Any object can implement any selector.
^ ", in several languages that are outside the Smalltalk
tradition, in which it is not objects but classes
that ``implement any selectors'', "
Rick> Inheritance is an implementation artifact in Smalltalk.
^ "Rick's Own"
You can well have your own "Smalltalk" in which inheritance is not a
part of the language, but is something that happens behind the scenes.
But I hope that in your own "Smalltalk" you have some very good reason
to eliminate inheritance from the language itself and make it an
implementation detail. Making methods attributes of classes and
inheritance/subclassing are parts of the language definition in
Smalltalk-80, and for the good reasons explained in:
"From the first Smalltalk interpreter to the definition of the
Smalltalk-80 Virtual Machine, the Smalltalk language has been
characterized by three principal attributes:
* Data stored as objects whic are automatically deallocated,
* Processing effected by sending messages to objects,
* Behaviour of objects described in classes.
In spite of other opinions to the contrary, we consider these to
be the hallmarks of the ``object-oriented'' style of
computing." ... ["Bits of History, Words of Advice", "The
evolution of the Smalltalk Virtual Machine", "Form follows
function", page 10]
[Note: I don't agree as to the merit]
... "Also, as our experience increased, we came to realize the
need for inheritance. This was felt first in the commonality of
behavior of Arrays, Strings, and sub-Arrays. For the time being,
we referred to common functions from those similar classes so as
to factor the behaviour, but it was clear that some sort of
inheritance mechanism was needed. ..." ["Bits of History, Words
of Advice", "The evolution of the Smalltalk Virtual Machine",
"Smalltalk-72", page 13]
... "In 1976 we carried out a major redesign of the Smalltalk
language and implementation[7]. It addresses most of the
problems encountered in the previous four years of experience
with Smalltalk:
* Classes and contexts became real objects;
* A class hierarchy provided inheritance;
" ... ["Bits of History, Words of Advice", "The evolution of
the Smalltalk Virtual Machine", "Smalltalk-76", page 14]
... "The Smalltalk-76 design stood the test of time well. It was
used for four years by 20 people daily and 100 people
occasionally. A large portion of the design survives unchanged
in the Smalltalk-80 system." ... ["Bits of History, Words of
Advice", "The evolution of the Smalltalk Virtual Machine",
"Experience with Smalltalk-76", page 14]
So it seems that one should be very careful in eliminating from the
language something that was added after considerable experience and that
ha proven itself as effective. It is also true that one can read:
... "While the present Smalltalk design has evolved over a
decade now, that does not mean it is finished." ... "
@ _Reducing Concepts_ It is always useful to reduce the number
of concepts in a programming language when possible. Smalltalk
distinguishes many levels of refinement: subclassing,
instantiation, blocks and contexts, to name a few. It is likely
that some of these distinctions can be dissolved, and that a
cleaner virtual machine design would result."
In other words, perhaps Smalltalk-BETA. Note also the mistake here: some
of those are _levels_ of refinement, some are not.
"@ _Typing and Protocols_ While Smalltalk-80 is not a typed
language in the normal sense,"
Please note that this _clearly_ means "with manifest types", as the
subsequent "variable type" and "given variable" makes clear:
"there is nonetheless an implicit notion of variable type in the
protocol (full set) of messages which must be understood by a
given variable. We have described abn experimental system based
on this notion of type[9], and a serious treatment of this
approach would likely involve changes to the Virtual Machine.
@ _Multiple Inheritance_ While Smalltalk-80 does not provide for
multiple inheritance, we have described an experimental system
which supports multiple superclasses using the standard Virtual
Machine[10]. This is another area in which serious use of the
new paradigm might suggest useful changes to the Virtual
Machine." ... ["Bits of History, Words of Advice", "The
evolution of the Smalltalk Virtual Machine", "Future
Directions", pages 21-22]
The sum total of this is that one ought to think a long time before
dismissing the experience of the original developers, and turn "Rick's
Own" Smalltalk into ANSI Smalltalk:
Rick> In fact, the position being taken in X3J20 is that inheritance is
Rick> up to the implementation.
Let me add that if one really wants to alter so radically the generic
notion of "Smalltalk" as most people, or at least those (by now I
suspect this excludes many practitioners) that have troubled themselves
with actually reading the "archeological" PARC material, there are many
excellent ready made standards: from Smalltalk-Self to Smalltalk-NeXT
(aka Smalltalk-C :->), without forgetting Smalltalk-CLOS (and at times I
opine/dread that as of today essentially all Smalltalk-??? users really
be happier with either Smalltalk-C or Smalltalk-CLOS for several good
reasons, but this is another thread entirely).
It is often the case that extraordinary changes to the fundamentals of a
language during standardization can result in problems, for if indeed:
Rick> In fact, the position being taken in X3J20 is that inheritance is
Rick> up to the implementation.
means, as is the literal meaning, that a conforming ANSI Smalltalk
product may dispense with inheritance altogether, and replace it with
some alternative reuse mechanism, from delegation to a general
"menu"-style reuse mechanism, I cannot see how ANSI Smalltalk would be a
common base for portability.
If this means that the particular type of inheritance (single, multiple,
whatever) is also up to the implementation, again this presents a
formidable obstacle to portability.
Rick> We are NOT defining a particular implementation hierarchy.
This seems to indicate that you are merely not mandating a particular
inheritance structure. Well, OK, it seems indeed an implementation
detail. For libraries, defining a set of entry points and their
semantics:
Rick> Instead we are defining a hierarchy of protocols to which
Rick> particular objects will conform.
seems a rather suitable idea, followed in most OO language documents
that have such an approach. It amounts to having only "protocol
descriptions" in "Part Two" of "The Languages".
Piercarlo Grandi
>>> said:
Alan> In <yf3vio0...@sabi.demon.co.uk> pier...@sabi.demon.co.uk
Alan> (Piercarlo Grandi) writes:
Piercarlo> I have written something about *Smalltalk-80*, as I have made
Piercarlo> clear many times, not ``Smalltalk'', and I have _proved_ that
Piercarlo> classes are what computer science textbooks call types in
Piercarlo> other language, and this is so by design, by quoting
^^^^^^^^
Piercarlo> literally the book that describes Smalltalk-80, and also some
Piercarlo> popular definition of type, and anybody can then see that
Piercarlo> they are equivalent.
Alan> But even in Smalltalk-80, as defined by the Blue Book, it is
Alan> possible to define two classes with different implementations, and
Alan> different inheritance hierarchies, which respond to exactly the
Alan> same messages with exactly the same semantics, preconditions and
Alan> postconditions.
Perhaps you should check entry level literature on programming languages
before confusing a type and its interface/specification. Such confusions
are popular in comp.object, and even in much of the research literature,
but ignorance is no excuse, not only in the law.
I have already made at length (over the past five years in comp.object)
the point that the distinction among the three aspects of a type/class,
interface, body, and semantics specifications, is not carried further
enough in most languages, including ``Smalltalk'', and the ability to
have many-many associations of each aspect with other aspect is instead
very useful, and I have even given a simple example (a deque type).
Alan> Instances of two such classes have the same "type" because they
Alan> respond to the same messages in the same way, but their classes
Alan> are different. This proves that a class is an implementation of a
Alan> type--it is not itself a type.
No, it only proves that:
A) you are prone to "confuse" the denotation of a type, and the type
itself.
B) you don't "remember" that type denotations, being in the domain of
mathematical entities, cannot by definition be expressed at the
language level, therefore by discussing "type" in the context of
``Smalltalk'' (not the feline variety!) we could not possibly have
been using "type" as an abbreviation for "type denotation" (not for
"type interface"/"type spefication").
C) you have not been following this thread, because I have had to
"remind" other people of all the points above already.
Alan> I would suggest reading the OOPSLA proceedings from the past ten
Alan> years. There have many papers presented there and elsewhere that
Alan> address these issues.
I would suggest reading some entry level textbook on mathematics, type
theory and languages and their relationship. Without having read those
your ability to make sense of those OOPSLA articles (if you have read
them yourself, which does not seem the case, because in some of them the
distinction between interface/body/semantics is clear) will have been
severely reduced by the lack of basic insight.
I would suggest that it would also be polite of you to read other
people's past articles before repeating all over again the same
inanities.
John Sellers
In Article<yf320qo...@sabi.demon.co.uk>, <pier...@sabi.demon.co.uk>
writes:
> ...
> I think that could be dangerous to the deliverable story... And that
> Smalltalks already have _a lot_ of reflection, if in very nonstandard
> ways. Perhaps you really want to say "Standardized reflective
> facilities".
>
Oh come now! Standards are developed, they are not invented. There is no
way one would decide on a standardized reflective facilities before they
are even part of the language. Nobody has broad experience in Smalltalk
refection.
The process would be something like:
* observe it
* analyse it (loop back & forth)
* design it (loop back & forth)
* implement it (loop back & forth)
* disseminate it (loop back & forth)
* use it (loop back & forth)
* enhance it (loop back & forth)
* let it mature (loop back & forth)
* let it stabilize (loop back & forth)
* standardize it (less loop back & forth) [late, not early!]
* enhance its Standards (loop back & forth)
* eventually make a fresh start
Actually real standards always have the sub-text that reads, "emerging
standards". They are the result of making the choice among the various
developments, selectively choosing only the best of the lot as part of the
standard.
Note this is as it ought to be, unfortunately there are often less
desirable forces driving standards, such as politics or ignorance.
Fortunately these always eventually do themselves in.
Piercarlo, your problem is that you make too much of the Blue Book. I know
both Adele Goldberg and David Robson and have a great deal of respect for
them both. I worked for Dave's father in the 70s. I suspect that they
would both agree that the Blue Book is dated.
The Blue Book was definitely a mile stone, but it is a mile stone that is
so far back that when one turns around to look at it, it is lost in the
distance. It is much more appropriate to look at things which are closer
to the present.
Piercarlo Grandi
John> In Article<yf320qo...@sabi.demon.co.uk>,
John> <pier...@sabi.demon.co.uk> writes:
pcg> I think that could be dangerous to the deliverable story... And that
pcg> Smalltalks already have _a lot_ of reflection, if in very nonstandard
pcg> ways. Perhaps you really want to say "Standardized reflective
pcg> facilities".
John> Oh come now! Standards are developed, they are not invented.
If only -- from what Rick DeNatale is writing, it seems as if ANSI
Smalltalk will also contain a lot of new, untested material, like many
other standards.
John> There is no way one would decide on a standardized reflective
John> facilities before they are even part of the language. Nobody has
John> broad experience in Smalltalk refection.
Well, you could ask Jan Steinman :-).
John> Piercarlo, your problem is that you make too much of the Blue
John> Book.
You must be having difficulty reading what I write: because I am not
making too much of Smalltalk-80. I know it's old, I know current
products have deviatedfrom it, but as a _matter of choice_ I have chosen
to use it as the basis for _my_ discussions about ``Smalltalk''.
Because there is no alternative, for otherwise ``Smalltalk'' is an empty
labelthat can be applied by enterprising people to anything they want to
make up.
John> I suspect that they would both agree that the Blue Book is dated.
I agree too -- so what's the problem.
John> The Blue Book was definitely a mile stone, but it is a mile stone
John> that is so far back that when one turns around to look at it, it
John> is lost in the distance. It is much more appropriate to look at
John> things which are closer to the present.
Yes, which ones? An ANSI draft that is "very initial" and can be obtained
by personal application to G Krasner, as Rick suggests?
Some people have posted here to the effect that there is very little
difference between that Smalltalk-80 language and the languages
currently implemented by the various vendors, and that the vast majority
of the basic classes/protocols are also the same.
In that case then discussing Smalltalk-80 for ``Smalltalk'' is not only
the only possible choice, despite it being over ten years old, but it is
also relevant to ``modern Smalltalk'', whatever that means.
Rick DeNatale
is no word for 'no' in Japanese. But, perhaps foolishly, I'll try once
more.
In article <yf3vio0...@sabi.demon.co.uk>, pier...@sabi.demon.co.uk
(Piercarlo Grandi) wrote:
>>>> On Fri, 01 Dec 1995 10:33:20 -0500, dena...@nando.net (Rick
>>>> DeNatale) said:
>
>Rick> So we have an example of someone who apparently has a surface
>Rick> understanding of some languages, which he doesn't speak, based on
>Rick> reading a few things, and confusing syntax, semantics and culture.
>
>This is indeed very true: many a participant in this thread (for
>example, and I have alrady quoted him to this effect, Jan Steinman) has
>difficulty distinguishing between language, system, virtual machine, and
>even between Smalltalk-80 and whatever ``Smalltalk'' product is
>installed on his machine today.
>
>One could argue that this is not too bad in itself: after all
>"Smalltalk"'s benefits flow from the whole. It becomes bad when it is
>used in a debate about what is/is not there in the language.
Yes, this holistic effect is important, and it is what several people are
arguing. One of the characteristics of Smalltalk is that it is an
extensible language, and that many of the things that are clearly defined
'in the language' in (the majority?) of languages is, at least,
conceptually defined by classes in Smalltalk. If you want to narrowly
define the language we might have less disagreement, but it wouldn't be
very useful. Just where you draw the line between language and libraries
is an important issue for standardizing Smalltalk, and one which took up
lots of discussion in the early meetings of X3J20.
>
>Rick> The preceding traffic in this thread has followed a similar
>Rick> pattern.
>
>All too true.
>
>Rick> We've had someone whose knowledge is apparently based on reading
>Rick> the purple book,
>
>Well, you are too pessimistic -- I am not the only one to have read it,
>even if at times it looks as if it is the case. Instead of "someone" you
>could write "some people".
I never said that you were the only one to have read it. I have read it
many times over the past 10+ years. I know for a fact that Dave Smith has
read it probably more than I have, and I'm 99% sure that Jan has as well.
The issue isn't whether someone has read the bible but whether they have
experience in practicing the religion.
>
>Rick> arguing with many people such as Dave Smith, Jan Steinman and
>Rick> others, who I know to be fluent speakers of the language.
>
>Well, if you say so, of course -- anointment by you exempts from the
>need to offer valid arguments. :-)
>
Yes, I apologise for not having documented credentials with you. The
people of whom we speak are long-time members of the Smalltalk community
who are well known to each other. Dave is a personal friend and the
author of two books on Smalltalk. Jan is a well-known and respected
consultant. Ralph Johnson is one of the best known researchers in the
Smalltalk community. I wrote most of the IBM Red Book, "Smalltalk
Portability: A Common Base" and I am secretary of X3J20.
>Yet there are a lot of fluent speakers of many languages that don't know
>its grammar, and think that morphology is an illness -- and therefore
>are howler-prone. That practitioners may well have a low level of
>insight in what they do, and knowledge of "academic" material, is fairly
>common in all disciplines. It become irritating when they mistake their
>dexterity and fluency, if any, with understanding and knowledge, and
>start making pronouncements that require the latter.
So, maybe French would be better off as a language if L'Academie Francaise
were composed of high school students who had mastered their French I
grammar book?
Dexterity and fluency in a language are intimately connected with
understanding and knowledge. It is hard to have either pair of attributes
without the other.
>
>With a little application and by reading books (which is not a high
>minded attitude as Jan and you seem to be thinking), which only requires
>taking away some little time from playing around with your
>Smalltalk-of-the-day, even you and Dave and Jan could evolve your
>fluency into insight; I did it myself, at least in part, and it is not
>too hard -- but then, as Jan correctly (for once :->) hinted, I haven't
>got a real life that interferes.
Again, the issue is not with reading books. We've all read the books, and
much more literature on the subject. The issue is whether reading the
books is enough. Most of the folks you've flamed on a lack of
understanding of Smalltalk, not only have a mastery of the books you
espouse, but have made significant additional contributions to the
Smalltalk literature.
>In particular the "Smalltalk-80" series which I am happy to mention
>often is rich with insight (not all of which I agree with), and by
>finally getting around to reading those "archeological" books a number
>of participants in this debate would spare me the need to type in so
>many quotes.
Yes, I've already noticed that you've written that you don't completely
agree with what is graven in the sacred scriptures. You seem to eat your
cake and have it too. You feel free to put down Smalltalk practititioners
by referring to "Jan's own Smalltalk" or "Rick's own Smalltalk" yet you
miss the point that maybe you are arguing about Piercarlo's own
interpretation of the holy scriptures. It is akin to someone saying that
they understand Christianity, but the Christians don't really believe that
Christ was God, do they?
But it isn't all we've got, and it isn't up to date. What he have is
several differing implementations which are quite compatible with each
other, despite having evolved from what is in the Blue Book.
>and to Dave Buck:
>
> Dave> The basic Smalltalk syntax has changed little since the
> Dave> publication of the Blue Book. The only major changes are:
> Dave> - addition of temporaries within blocks
> Dave> - addition of double precision float literals
> Dave> - support for class instance variables
> Dave> - change of assignment symbol to :=
> Dave> - underscores are now allowed in identifiers
> Dave> There may be a few other changes that I can't remember right
> Dave> now.
So, Dave has provided us with a list of additions since the Blue Book. The
language, unlike Latin, is not dead.
>
>Rick> As a member of X3J20, I'm actively involved in defining a
>Rick> standard. I've been amazed, but not really surprised, at the level
>Rick> of agreement within the committee. The current (very initial)
>Rick> commitee draft, can be obtained by request from Glenn Krasner at
>Rick> ParcPlace-Digitalk.
>
>So, a "(very initial)" draft that "can be obtained by request" is a
>common base definition? Frankly I think that the Red Book that you also
>mention might be a more defensible idea. At least it's published, and
>IBM has branches everywhere.
As an author of the Red book, I certainly wouldn't discourage its sales.
The (very initial) comment was due to our desire to express to the
community that the draft is still under commitee review and should not be
considered to have the legal status of a draft standard. It does however
represent the current thinking of the authors of the individual sections,
and as a whole represents the overall direction of the committee subject,
of course, to the discussions that committees are wont to have.
>
>Rick> PCG seems to take the position that Smalltalk is quite similar to
>Rick> C++ in having a type hierarchy which is closely mapped to the
>Rick> inheritance hierarchy.
>
>This is a fabrication: please find anywhere where I have written this
>inanity.
I'm sorry that I might have misinterpreted what you have posted
previously, and I haven't saved it.
However, I do remember you arguing that Smalltalk had a single rooted
hierarchy, and you seemed to me to have said that this hierarchy formed a
type hierarchy. If you didn't say this I apologise, but this is the way I
remember.
>
>It is an inanity: because "Smalltalk" is such a loose term that any
>attempt to claim "Smalltalk" has any given feature is meaningless, as
>one can easily find both examples and counterexamples in something with
>"Smalltalk" in its name.
No! All Smalltalks of which I am aware have certain features, such as the
ability to form subclasses which don't inherit from object; the separation
of method selectors from any particular inheritance graph; the same base
syntax etc. etc. etc. Arguing that we can define Smalltalk however we
please is the inanity here.
>
>I have written something about *Smalltalk-80*, as I have made clear many
>times, not ``Smalltalk'', and I have _proved_ that classes are what
>computer science textbooks call types in other language, and this is so
>by design, by quoting literally the book that describes Smalltalk-80,
>and also some popular definition of type, and anybody can then see that
>they are equivalent.
So here we have restated, the position that you claimed not to have made.
There has been a lot of work on type inferencing in Smalltalk which has
shown that a type system for Smalltalk needs to be much richer than just
being based on classes. For example, Ralph Johnson did a type checked
Smalltalk which showed that the type algebra needed to be quite rich.
Ralphs work on TypedSmalltalk is readily available. An OOPSLA paper some
years ago, the name of the author escapes me at the moment, analysed the
type relationships in the Collection class hierarchy of Smalltalk-80 and
showed that it diferred quite drastically from the class hierarchy. Dave
Thomson's master's thesis at Carleton University, which provided the base
for the type description system that we are using for X3J20, defines a
completely separate hierarchy of protocols, we are still exploring how
fine-grained that protocol hierarchy needs to be in order to capture the
use of protocols as opposed to just the provision of the protocols.
Perhaps some study of the New Testament would help.
>I have already stated rather explicitly that I have never taken the
>position you attribute to me, and repeating the allegation even if
>prefixed with "seems" is rather disingenuous, for I have been very
>clear.
Well maybe not clear enough, since you seem to have just reconfirmed my
suspicion.
>If one produces the description of a Smalltalk-of-the-day, even one
>based on a modification of the original Smalltalk-80 then of course:
>
>Rick> This just isn't true. The basic semantics of Smalltalk separate
> ^ "Rick's Own"
I hate to quote Ronald Reagan, but "There you go again!"
>Rick> the meaning of a particular message from the implementation
>Rick> hierarchy.
>
>Rick> Any object can implement any selector.
> ^ ", in several languages that are outside the Smalltalk
> tradition, in which it is not objects but classes
> that ``implement any selectors'', "
>
>Rick> Inheritance is an implementation artifact in Smalltalk.
> ^ "Rick's Own"
And there you go again! I might have been a little loose with the term
object above, but not really. Objects really do implement methods, Classes
are a mechanism for factoring common structure and behavior out of a group
of objects which share their implementation. Historically, Smalltalk had
classes before it had inheritance (of course this was before
Smalltalk-80).
>
>You can well have your own "Smalltalk" in which inheritance is not a
>part of the language, but is something that happens behind the scenes.
I didn't say that it wasn't part of the language. Inheritance in Smalltalk
serves the purpose of allowing implementation of methods and structure to
be shared. However, since in Smalltalk a client of an object never needs
to know the structure of the object, two classes can implement the same
selector without having any inheritance relationship.
>
>But I hope that in your own "Smalltalk" you have some very good reason
>to eliminate inheritance from the language itself and make it an
>implementation detail. Making methods attributes of classes and
>inheritance/subclassing are parts of the language definition in
>Smalltalk-80, and for the good reasons explained in:
>
> "From the first Smalltalk interpreter to the definition of the
> Smalltalk-80 Virtual Machine, the Smalltalk language has been
> characterized by three principal attributes:
>
> * Data stored as objects whic are automatically deallocated,
>
> * Processing effected by sending messages to objects,
>
> * Behaviour of objects described in classes.
Notice, that inheritance is not one of these three principal attributes.
What are they? In direct expansion of the above list:
1) The provision of automatic storage management (Garbage Collection)
2) The principle of computation via message sending (wasn't this the
point you quibbled with in an earlier posting?) in which all knowledge of
the implementation of an object is carefully hidden from the client BEHIND
the message dispatching mechanism (Dave Smith says that in Smalltalk "All
objects have the same shape")
3) The use of classes to allow common behavior and structure to be
factored out and shared between a set of objects with identical structure
and behavior. Inheritance was introduced later as a way to allow behaviour
to be shared between classes which differed from each other in certain
ways. Smalltalk has always allowed polymorphism outside of classes or
later class hierarchies.
>
> In spite of other opinions to the contrary, we consider these to
> be the hallmarks of the ``object-oriented'' style of
> computing." ... ["Bits of History, Words of Advice", "The
> evolution of the Smalltalk Virtual Machine", "Form follows
> function", page 10]
>
>[Note: I don't agree as to the merit]
Eating your cake and having it too! You can prove anything from a fallacy.
>
> ... "Also, as our experience increased, we came to realize the
> need for inheritance. This was felt first in the commonality of
> behavior of Arrays, Strings, and sub-Arrays. For the time being,
> we referred to common functions from those similar classes so as
> to factor the behaviour, but it was clear that some sort of
> inheritance mechanism was needed. ..." ["Bits of History, Words
> of Advice", "The evolution of the Smalltalk Virtual Machine",
> "Smalltalk-72", page 13]
So, you see I have read the literature! This is what I have been saying.
Notice that they are talking about factoring behavior, not building a type
system.
>
> ... "In 1976 we carried out a major redesign of the Smalltalk
> language and implementation[7]. It addresses most of the
> problems encountered in the previous four years of experience
> with Smalltalk:
>
> * Classes and contexts became real objects;
>
> * A class hierarchy provided inheritance;
>
> " ... ["Bits of History, Words of Advice", "The evolution of
> the Smalltalk Virtual Machine", "Smalltalk-76", page 14]
>
> ... "The Smalltalk-76 design stood the test of time well. It was
> used for four years by 20 people daily and 100 people
> occasionally. A large portion of the design survives unchanged
> in the Smalltalk-80 system." ... ["Bits of History, Words of
> Advice", "The evolution of the Smalltalk Virtual Machine",
> "Experience with Smalltalk-76", page 14]
>
>So it seems that one should be very careful in eliminating from the
>language something that was added after considerable experience and that
>ha proven itself as effective.
As I said I never said that inheritance should be eliminated. Only that it
doesn't form a type system for Smalltalk.
One of our goals in X3J20 is to allow DIFFERING implementations which
conform to the standard specification.
One of the problems with the blue book, besides being dated, is that in
describing a particular implementation, it is overspecified.
> It is also true that one can read:
>
> ... "While the present Smalltalk design has evolved over a
> decade now, that does not mean it is finished." ... "
Which is much of what we all have wasted a lot of words over here.
>
> @ _Reducing Concepts_ It is always useful to reduce the number
> of concepts in a programming language when possible. Smalltalk
> distinguishes many levels of refinement: subclassing,
> instantiation, blocks and contexts, to name a few. It is likely
> that some of these distinctions can be dissolved, and that a
> cleaner virtual machine design would result."
>
>In other words, perhaps Smalltalk-BETA. Note also the mistake here: some
>of those are _levels_ of refinement, some are not.
No there is a continuum of refinement here.
Subclassing - relates behavior based on differences between classes
instantiation - relates the behavior of instances of the same class
blocks and context - relates behavior of continuations in the
execution of the behaviors of individual objects.
>
> "@ _Typing and Protocols_ While Smalltalk-80 is not a typed
> language in the normal sense,"
>
>Please note that this _clearly_ means "with manifest types", as the
>subsequent "variable type" and "given variable" makes clear:
>
> "there is nonetheless an implicit notion of variable type in the
> protocol (full set) of messages which must be understood by a
> given variable.
What is being said here? That, an object which is held in a variable is
expected to implement a certain set of messages. This is what I call a
role. This is a client-oriented view of types, in that the usage of an
object generates a 'job description' which is a set of required abilities.
The set of abilities (methods) provided by an object of a given class is
effectively a 'resume' or set of credentials which the potential employer
can test against requirements.
> We have described abn experimental system based
> on this notion of type[9], and a serious treatment of this
> approach would likely involve changes to the Virtual Machine.
An interesting experiment, did it ever happen? It certainly doesn't affect
today's Smalltalk implementations.
> @ _Multiple Inheritance_ While Smalltalk-80 does not provide for
> multiple inheritance, we have described an experimental system
> which supports multiple superclasses using the standard Virtual
> Machine[10]. This is another area in which serious use of the
> new paradigm might suggest useful changes to the Virtual
> Machine." ... ["Bits of History, Words of Advice", "The
> evolution of the Smalltalk Virtual Machine", "Future
> Directions", pages 21-22]
Yes, another interesting experiment. MI was implemented in Smalltalk, was
found not to be needed, and was removed. Why?
Because, the class hierarchy in Smalltalk is not a type hierarchy. The
complications introduced by MI are suffered in strongly typed languages
such as C++ because they are necessary. Why are they necessary in such
languages? Precisely because the only way to describe the relationships
between types in C++ (and they must be described in a strongly typed
language) is via inheritance, so to describe a type which implements or
subtypes multiple types, you need MI. In Smalltalk which has no
requirement to describe type relationships, MI is not needed, and as it
turns out, multiple inheritance of implementation is not particularly
useful because the combination of implementation usually affects the
implementation thereby obviating the opportunity for sharing.
>The sum total of this is that one ought to think a long time before
>dismissing the experience of the original developers, and turn "Rick's
>Own" Smalltalk into ANSI Smalltalk:
Well, there you go again! No one is dismissing the experience of the
original developers, they are well represented on X3J20, and I don't
believe that they would take issue with me in substantive ways. We are
arguing that one should not dismiss the experiences amassed by those who
have actually implemented and/or actually used the language in the period
since the Blue Book which now eclipses the decade referred to earlier.
>
>Rick> In fact, the position being taken in X3J20 is that inheritance is
>Rick> up to the implementation.
>
>Let me add that if one really wants to alter so radically the generic
>notion of "Smalltalk" as most people, or at least those (by now I
>suspect this excludes many practitioners) that have troubled themselves
>with actually reading the "archeological" PARC material, there are many
>excellent ready made standards: from Smalltalk-Self to Smalltalk-NeXT
>(aka Smalltalk-C :->), without forgetting Smalltalk-CLOS (and at times I
>opine/dread that as of today essentially all Smalltalk-??? users really
>be happier with either Smalltalk-C or Smalltalk-CLOS for several good
>reasons, but this is another thread entirely).
Who is spouting inanities now.
>
>It is often the case that extraordinary changes to the fundamentals of a
>language during standardization can result in problems, for if indeed:
>
>Rick> In fact, the position being taken in X3J20 is that inheritance is
>Rick> up to the implementation.
>
>means, as is the literal meaning, that a conforming ANSI Smalltalk
>product may dispense with inheritance altogether, and replace it with
>some alternative reuse mechanism, from delegation to a general
>"menu"-style reuse mechanism, I cannot see how ANSI Smalltalk would be a
>common base for portability.
No! What this means is that implementations may implement particular
classes with differing implementation hierarchies. This is the case today,
and Smalltalk code which uses the basic classes is quite portable. Some
implementations even map several of the blue book classes to the same
concrete implementation class, and this is alright.
>
>If this means that the particular type of inheritance (single, multiple,
>whatever) is also up to the implementation, again this presents a
>formidable obstacle to portability.
>
>Rick> We are NOT defining a particular implementation hierarchy.
>
>This seems to indicate that you are merely not mandating a particular
>inheritance structure.
Yes this is what we ARE saying.
>Well, OK, it seems indeed an implementation
>detail. For libraries, defining a set of entry points and their
>semantics:
>
>Rick> Instead we are defining a hierarchy of protocols to which
>Rick> particular objects will conform.
>
>seems a rather suitable idea, followed in most OO language documents
>that have such an approach. It amounts to having only "protocol
>descriptions" in "Part Two" of "The Languages".
Why does this remind me of the story of the customer in the restaurant
who asked the waiter to taste his soup.
Waiter: I'm sorry sir, I don't want to taste your soup.
Customer: No, I insist you taste my soup.
Waiter: No, I don't want to taste your soup.
Customer: I insist that you taste my soup, or I will call the manager.
Waiter: All right, let me have your spoon.
Customer: AHA!
John Sellers
In Article<yf3wx8e...@sabi.demon.co.uk>, <pier...@sabi.demon.co.uk>
writes:
> ...
> In that case then discussing Smalltalk-80 for ``Smalltalk'' is not only
> the only possible choice, despite it being over ten years old, but it is
> also relevant to ``modern Smalltalk'', whatever that means.
I disagree. "the only possible choice"? No way. Other and more relevant
choices would be Object Works, Visual Works, Digitalk (not Parts), and/or
QKS...Visual Age to a lesser degree because it is so relatively new with a
shorter track record.
It is certainly appropriate to mention the Blue Book, but mainly for
historical reasons. The best place to start with a standard is to pick
what is out there and being widely used. What makes a good standard is
experience, because there is then a way to shake things out.
You can not establish a meaningful standard without a history. In the
early days of ADA before there was a compiler for it, when
Crieg-Brookner(sp?) (one of the language designers) was at Berkley and
Grady Booche was at the DOD tracking Language Change Requests for ADA,
there was a lot of talk about ADA being a standard. At the time, I got a
copy of their final report on this so called "standard", I thumbed through
it for a whole 15 minutes before I noticed a major flaw in the language.
They had already corrected literally thousands of such errors before I got
it in my hands. It takes a lot of time and experience to create a
meaningful standard.
Smalltalk-80 was only three years old when the Blue Book was completed. At
that time Smalltalk had been widely known by the public for 21 months. The
first commercial efforts at Digitalk started to surface around the time the
Blue Book was published. Smalltalk-80 did not become a commercial product
until later.
The amount of experience with Smalltalk since 1983 when the Blue Book was
published has been orders of magnitude larger than the experience of a
dozen or so people at Xerox Parc before it was published.
You mention Glen Krasner. He was involved in getting releases of
Smalltalk-80 before the Smalltalk Blue Book was written and has been
involved with the standards committee since its inception. That makes
sense.
What we have learned from experience since then is much more important than
anything that happened back then, except for historical interest.
Piercarlo Grandi
Rick> C++ in having a type hierarchy which is closely mapped to the
Piercarlo> [ ... ] I have written something about *Smalltalk-80*, as I
Piercarlo> have made clear many times, not ``Smalltalk'', and I have
Piercarlo> _proved_ that classes are what computer science textbooks
Piercarlo> call types in other language, [ ... ]
Piercarlo> ^^^^^^^^
Alan> [ ... ] Instances of two such classes have the same "type" because
Alan> they respond to the same messages in the same way, but their
Alan> classes are different. This proves that a class is an
Alan> implementation of a type--it is not itself a type.
Piercarlo> No, it only proves that:
Piercarlo> A) you are prone to "confuse" the denotation of a type, and
Piercarlo> the type itself. [ ... ]
Alan> I would suggest reading the OOPSLA proceedings from the past ten
Alan> years. There have many papers presented there and elsewhere that
Alan> address these issues.
Piercarlo> I would suggest reading some entry level textbook on
Piercarlo> mathematics, type theory and languages and their
Piercarlo> relationship. Without having read those your ability to make
Piercarlo> sense of those OOPSLA articles [ ... ] will have been
Piercarlo> severely reduced by the lack of basic insight.
Those that actually bother reading and understanding the literature on
the relationship between types in different flavours of programming
languages, and those types and the (very different!) notion of type in
formal type theory, have probably found easy to guess which particular
OOPSLA article Alan has in mind that "proves" that a class "is not
itself a type" and that as Rick says it "just isn't true" that
"Smalltalk is quite similar to C++ in having a type hierarchy which is
closely mapped to the inheritance hierarchy".
Alan would do well to mention the title of that article itself, if he
dares to :-)
I am ready to type in a few paragraphs from pages 474, 480-482, 489-491
of Cardelli&Wegner (ACM Comp. Surveys, Dec 1985) and some from a couple
of other broad entry level "survey" books (OOSC, OOLSA, for example)
that ought to clear the matter of whether 'class' in Smalltalk(-80) and
'type' in other OO and non OO languages are essentially equivalent
notions.
Note that I have criticized all those works in the past as they
contain some obnoxious disagreeable mistakes, IMNHO of course, but I
can also make use of the agreeable parts (I would also mention the
disagreeable parts, and explain why they are wrong).
Piercarlo Grandi
Alan> In <yf3vio0...@sabi.demon.co.uk> pier...@sabi.demon.co.uk
Alan> (Piercarlo Grandi) writes:
Piercarlo> I have written something about *Smalltalk-80*, as I have made
Piercarlo> clear many times, not ``Smalltalk'', and I have _proved_ that
Piercarlo> classes are what computer science textbooks call types in
Piercarlo> other language, and this is so by design, by quoting
^^^^^^^^
Piercarlo> literally the book that describes Smalltalk-80, and also some
Piercarlo> popular definition of type, and anybody can then see that
Piercarlo> they are equivalent.
Alan> But even in Smalltalk-80, as defined by the Blue Book, it is
Alan> possible to define two classes with different implementations, and
Alan> different inheritance hierarchies, which respond to exactly the
Alan> same messages with exactly the same semantics, preconditions and
Alan> postconditions. Instances of two such classes have the same
Alan> "type" because they respond to the same messages in the same way,
Alan> but their classes are different. This proves that a class is an
Alan> implementation of a type--it is not itself a type.
Alan> The ability to have multiple, diffrerent implementations of the
Alan> same "type" is one of the main motivations for OOP.
It is the main motivation for having modules and types at all. OO
languages are only a small subset of those that allow to have multiple
types to have the same denotation. Hey, even Pascal does:
type complex1 = record re, im : float end;
complex2 = record imag, real: float end;
stack1 = record n : 0..10; s : array[0..10] of 0..1000; end;
stack2 = record s : 0..1000; f : ^stack2 end;
What you probably wanted to say is that one of the main motivations for
OO is the ability to _hide_ the details of the multiple types so that
they can share interface and not just denotations, as you seem to
clumsily hint:
Alan> The distinction between type and class is necessary for
Alan> polymorphism and the separation of interface from mechanism.
Not at all -- unless you choose, rather bizarrely to equate "type" with
"interface" itself.
In order to separate interface from body from specification (there are
_three_ aspects to a type definition in a programming language) one just
needs suitably flexible linguistic constructs. These are available
equally for OO languages in which types are called classes and non OO
languages in which they are called types.
Alan> Because this is not possible in traditional "value-oriented"
Alan> languages,
Go tell that to the Modula-3 folks... Or those poor ML guys.
Given that the above inanities are presumably based on an ill-digested
notion of type, and the constant confusion between a type in a
programming language, which is defined as an interface, a body, and a
specification, and its denotation, which is usually defined as an
algebra, let's go back to rereading some industry standard material as I
had anticipated in another article.
I have decided to post it now, without waiting for Alan's mention of his
source, because it's a lot of typing, and I think I won't have much time
in the coming week...
The first long bit is from "On Understanding Types, Data Abstraction,
and Polymorphism", which appears in the Decembver 1985 issue of ACM
Computing Surveys, which I can quote extensively thanks to the liberal
copyright permissions by ACM.
I have often expressed reservations about this paper, in particular but
not only in its treatment of polymorphism, but for the purposes of this
discussion, the passages I am quoting here are agreeable:
... "A type may be viewed as a set of clothes (or a suit of armour)
that protects an underlying untyped representation from arbitrary or
unintended use. It provides a protective covering that hides the
underlying representation and constrains the objects may interact with
other objects. In an untyped system untyped objects are ``naked'' in
that the undrlying representation is exposed for all to see. Violating
the type system involves removing the protective set of clothing and
operating directly on the naked representation."
... "To prevent type violations, we generally impose a static type
structure on programs. Types are associated with constants, operators,
variables, and function symbols. A ``type inference'' system can be
used to infer the types of expressions when little or not type
information is given explicitly. In languages like Pascal and Ada, the
type of variables and function symbols is defined by redundant
declarations, and rhe compiler cna check the consistency of definition
and use. In languages like ML, explicit declarations are avoided
wherever possible, and the system may infer the type of expressions
from local context, while still enabling consistent usage.
Programming languages in which the type of very expression can be
determined vy static program analysis are said to be ``statically
typed''. Static typing is a useful property, but the requirement that
all variables and expressions are bound to a type at compile time is
sometimes too restrictive. It may be replaced by the weaker
requirement that all expressions are required to be type consistent
althought the type itself may be statically unknown; this can be
generally done by introducing some run-time type checking. Languages
in which all expressions are type consistent are called strongly typed
languages. If a language is strongly typed, its compiler can guarantee
that the programs it accepts will execute without type errors. In
general, we should strive for strong typing and adopt static typing
whenever possible. note that every statically typed language is
strongly typed, but the converse is not necessarily true."
... "Simula is the first ``object-oriented'' language. Its notion of
type includes classes whose instances may be assigned as values of
class-valued variables and may persist between the execution of
procedures they contain. Procedures and data declarations of a class
constitute its interface and are accessible to its users." ...
"Subsequent object oriented languages like Smalltalk and Loops combine
the class concept derived from Simula with a stringer notion of
information hiding."
... "The differences in behaviour between packages and records in Ada
are avoided in object-oriented languages by extending the notion of
type to procedures and data abastractions. In the context of this
discussion it is useful to define object-oriented languages as
extensions of procedure-oriented languages that support typed data
abstractions with inheritance. Thus we say that a language is object
oriented if and only if it satifies the following requirements:
* It supports objects that are data abastractions with an interface of
named operations and a hidden local state.
* Objects have an associated object type.
* Types may inherit attributes from supertypes.
These requirements may be summarized as
object oriented = data abastraction + object types + type inheritance"
Note: I have spared myself to annotate all this, except that here I
cannot resist and I must say that I disagree at least in part.
... "The requirement that all objects have a type allows objects to be
first-class values so that they can be managed as data structures
within the language as well as used for computation. The requirement
of type inheritance allows relations among types to be specified.
Inheritance may be viewed as a type composition mechanism that allows
the properties of one or more types to be reused in the definition of
a new type. The specification ``B inherits A'' may be be viewed as an
abbreviation mechanism that avoid redefining the attributes of type A
in the definition of type B. Inheritance, however is more than a
shorthand, since it imposes structure upon a collection of related
types that can greatly reduce the complexity of a system
specification. This is illustrated by the Smalltalk object hierarchy
in Goldberg and Robson[1983]."
... " The Smalltalk object hierarchy is also significant as an
illustration of the power of polymorphism."
... "The Smalltalk object hierarchy realizes polymorphism in the above
sense by factoring out attributes common to a collection of subtypes
into a supertype." ... "Thus polymorphism is intimately related to the
notion of inheritance, and we can say that the expressive power of
object-oriented systems is due in large measure to the polymorphism
they facilitate."
... "Supertypes in object-oriented systems may be viewed as parametric
types whose parameter is omitted by the user." ...
Another note that I must make so far for types as in programming
languages. The authors then introduce a model type system based on
lambda calculus. Now on types in mathematical type theory, and Alan will
see that this is a completely differentsort of thing, and he should not
confuse the two notions, even if the word "type" is used in this
article, confusingly, to label _both_ things, even if it is clear by
context which is which:
... "What is an adequate notion of ``type'' that can accounts for
polymorphism, abstraction, and parametrization? In the previous
sections we started to describe a particular type system by giving
informarmal typing rules for the linguistic constructs that we
use. These rules are enough to characterize the type system at an
intuitive level and can be easily formalized as a type inference
system. The rules are sound and can stand on their own, but they have
been discovered and justified by studying a particular semantics of
types,developed in " ... "
Although we do not need to discuss the semantic theory of types in
detail, it may be useful to explain the basi intuitions behind it.
The intuitions can, in turn, be useful in udnerstanding the typing
rules, particularly with regard to the concept of subtypes, which is
introduced later.
There is a universe $V$ of all value, containing simple values like
integers, data structures like pairs, records and variants, and
functions. This is a complete partial order, built by using Scott's
techniques[Scott 1976], but in first approximation we can think of it
just as a large set of all possible values.
A type is a set of elements of $V$. Not all subset of $V$ are legal
types: They must obey some technical properties. The subsets of $V$
obeying such properties are called ``ideals''. All the types found in
programming languages are ideals in this sense, so we do not have to
worry too much about subsets of $V$ that are not ideals.
Hence a type is an ideal, which is a set of values. Moreover the set
of all types (ideals) over $V$, when ordered by set inclusion, forms a
lattice. The top of this lattice is the type $Top$ (the set of all
values, i.e. $V$ itself). The bottom of the lattice is, essentially,
the empty set (actually it is the singleton set containing the least
element of $V$).
The phrase ``having a type'' is interpreted as _membership_ in the
appropriate set. Because ideals over $V$ may overlap, a value can have
many types.
A particular type system is then a collection of ideals of $V$,
which is usually identified by giving a language of type expressions
and a mapping from type expressions to ideals. The ideals in this
collection are elevated to the rank of ``types'' for a particular
language."
... "Since types are sets, subtypes simply correspond to
subsets. Moreover, the semantic assertion ``'T1' is a subtype of
'T2''' corresponds to the mathematical condition $T1 isubset T2$ in
the type lattice. This gives a very simple intepretation for subrange
types and inheritance, as we shall see in later sections.
Finally, if we take out type system as consisting of the single set
$V$, we have a type-free system in which all values are the same
type. Hence we can express typed and untyped languages in the same
semantic domain and compare them."
The article, old as it is, and poorly written, and superceded in some
parts, still deserves to be read in full.
I would also like to draw attention to two introductory textbooks, where
the wording is often so ambiguous that fluent speakers of some language
seem to have difficulty getting which is which. I am a slow typist, and
I have spent the past hour typing the above quotes, so I will just write
here short quotes, page numbers and annotations about them.
in "Object-Oriented Languages, Systems, and Applications" (a collection
of survey essays, several of which I dislike), published by Pitman,
there is a discussion on pages 86-91 on "TYPES AND OBJECT ORIENTED
SYSTEMS", in which the notion of type (denotation, that is) in formal
type theory and in OO languages are compared. The obvious results are
presented, that a class is a type and not a type denotation, and thus
several classes can implement the same denotation, and that inheritance
is not subtyping because of this (the lattice among type denotations can
be different from the inheritance graph among types). It makes some
confusion between the interface of a type, and its type denotation, like
many others, repeats the deque example, and concludes by quoting
approvingly a reference as:
"In Smalltalk, a subclass does not necessarily conform to its
superclass; for example, it may override some of the operations of the
superclass so that they expect different classes of
arguments. Moreover, one class may conform to another without a
subclass relationship existing between them. What a subclass and its
superclass *do* have in common is part of their representation and
some of their methods. In short, inheritance is a relationship between
implementations, while conformance is a relationship between
interfaces".
On page 95-96 of the same book there is a section on "Subtyping in
abstract data types", in which one can find the bizarre statement that:
"Note that rules for type checking are normally based on the syntax of
the specification alone. For example, two types which provide the same
operations must be considered to be the same type irrespective of the
semantics of the operation, Similarly rules for subtyping must be
based solely on the interfaces provided. This is a major weakness
of amny abastract data type based languages and is an area for future
research."
It's languages of this sort that perhaps confuses the unwary/unweary.
Still, OOLSA is also a book that should be read...
Finally, a source better than most, "Object Oriented Software
Construction", by B. Meyer. I mostly agree with it, even if it is like
many others lacking here and there in proper termnology, and reports
some common misconceptions, and some self-serving arguments. Still, much
better than most...
On page 59, there is "A PRECISE DEFINITION":
"Definition 2: Object-oriented design is the construction of
software systems as structured collections of abstract data type
implementations.
In an object-oriented architecture, every module will be built on a
data abstraction, that is to say on a set of data structures
described by the services that are part of its official interface,
and the properties of those services."
... "As announced earlie, the modules of object-oriented system are
called *classes*. According to the above definition, a class is an
abastract data type implementation, _not_ the abastract data type
itself. This is inevitable for a method targeted to actual design
and implementation rather than just specification. For example, the
side effect free functions of the specification ('push' and the
like) may be represented in the class, for efficiency reasons, by
procedures working by side effect.
[We shall see however, that object-oriented techniques allow for
classes that cover more than one implementation of an abastract
data type. Such classes are called *deferred classes* and will
be introduced in chapter 10. The Eiffel language used in the
following chapters grants designers flexibility to the level of
abastraction of the classes they write. It is possible to write
classes general enough to be very close indeed to a bona fide
abastract data type specification.]"
The "SEVEN STEPS TOWARDS OBJECT-ORIENTED HAPPINESS" on pages 60-62
repeat the same concepts (ADTs are mathematical entities, they can be
_described_ via specifications in some mathematical notation, and
_implemented_ in programming languages as classes), and among the points
made:
"The next step is the one which, in our opinion, truly distinguishes
object-based languages from the rest of the world." ... "true
object-oriented programming all but identifies the notion of module
with the notion of *type*. One may say that the defining equation of
such languages is the identity
module = type
"
... " Level4 (Classes): Every non-simple type is a module, and
every high-level module is a type.
The qualifier ``non-simple'' makes it possible to keep predefined
types (such as 'INTEGER' etc.) which are not viewed as modules; the
word ``high-level'' permits program structuring units such as
procedures which are not types.
A language construct combining the module and types aspects is
called a *class*.
"
The summary "KEY
CONCEPTS INTRODUCED IN THIS CHAPTER" on page 63 contains:
"* To satisfy the requirements of extendibility and reusability, the
data descriptions on which object-oriented software structures are
built should be sufficiently abstract. The answer is provided by the
theory of abastract data types, reconciling completeness of
specifications with the need not to overspecify.
* Abstract data types may be generic and are defined by functions,
preconditions and axioms. The preconditions and axioms express the
semantics of a type and are essential to a full, unambiguous
description.
* An abstract data type specification is a formal, mathematical
description. It is side effect free.
* Object-oriented systems are built as collections of classes. Every
class represents a particular abastract data type implementation, or a
group of implementations." ...
Just for completeness, I shall mention that on pages 437-439 there is a
discussion of ``Smalltalk'', in which there is the obviously kisleading
with the obviously clear:
... "As a language, Smalltalk combines the influence of Simula with
the free, typeless style of Lisp. The emphasis is on dynamic
binding. No type checkingf is performed: in contrast with the approach
emphasized in this book, the determination of whether a routine may be
applied to an object occurs only at run-time."
Note that of course taken literally this is nonsensical and contradicts
the paragrapha above: here "typeless" is really "dynamically typed".
"This, by the way, is not the standard Smalltalk terminology. A
routine is called a ``method'' in Smalltalk; applying a routine to an
object is called ``sending a message'' to the object (whose class must
find the appropriate method to handle the message)."
Another plug: OOSC is one of the must-haves, despite some criticism I
could make.
This ends this long work. I hope it will be of benefit, and will counter
the spread of authoritative inanities that I have been so unhappy with.
Piercarlo Grandi
>>> DeNatale) said:
pcg> [ ... many of the benefits of various ``Smalltalk''s stem from the
pcg> rich total environment ... ]
Rick> Yes, this holistic effect is important, and it is what several
Rick> people are arguing.
It is my impression that they are arguing a different point: not that
benefits stem from the whole, but the whole is is not quite made of
parts that can be studied rather independently, as is done in
"Smalltalk-80: The Language" itself.
Rick> One of the characteristics of Smalltalk is that it is an
Rick> extensible language,
Several ``Smalltalk''s have an extensible _system_, and if you cannot
make the distinction the distinction between extensibility of language
and of system you cannot make sense discussing either.
Rick> and that many of the things that are clearly defined 'in the
Rick> language' in (the majority?) of languages is, at least,
Rick> conceptually defined by classes in Smalltalk. If you want to
Rick> narrowly define the language we might have less disagreement, but
Rick> it wouldn't be very useful. Just where you draw the line between
Rick> language and libraries is an important issue for standardizing
Rick> Smalltalk, and one which took up lots of discussion in the early
Rick> meetings of X3J20.
It was defined very precisely in "Smalltalk-80", which is what I have
been basing my arguments on. I have often quoted this passage from
"Smalltalk-80: The Language", but it seems apt to repeat here:
"PART TWO
---------
Part One provided an overview of the Smalltalk-80 language both
from the semantic view of objects and message sending and from
the syntactic view of the form that expressions take. The
Smalltalk-80 programmer must first understand the semantics of
th language: that all information is represented in the form of
objects and that all processing is done by sending messages to
objects. Every object is described by a Class; every class, with
the exception of class Object, is a subclass of another
class." [ ... ]
Rick> We've had someone whose knowledge is apparently based on reading
Rick> the purple book,
pcg> Well, you are too pessimistic -- I am not the only one to have read
pcg> it, even if at times it looks as if it is the case. Instead of
pcg> "someone" you could write "some people".
Rick> I never said that you were the only one to have read it.
I never claimed as much: I just wanted to contradict your statement that
a singular "someone" has read it. I have surely read it, and surely
other people have: therefore that someone you mention plus me plus the
other people I know makes for "some people". My point is that it is
rather widely known, it is not such an "archeological" reference that is
"utterly irrelevant" as Jan has argued, or that only "someone" has read
it. "somemany" have read it, actually!
Rick> The issue isn't whether someone has read the bible but whether
Rick> they have experience in practicing the religion.
I don't consider the "Smalltalk-80" series a bible, just reference
material; and ``Smalltalk'' may be a religion to a neophyte, not to me,
for after nearly twenty years of familiarity with the many various
releases of ``Smalltalk'' that have happened I am a bit weary perhaps.
Rick> arguing with many people such as Dave Smith, Jan Steinman and
Rick> others, who I know to be fluent speakers of the language.
pcg> Well, if you say so, of course -- anointment by you exempts from the
pcg> need to offer valid arguments. :-)
Rick> Yes, I apologise for not having documented credentials with
Rick> you.
So it is credentials as well as anointment from you; but still it looks
like you think they exempt from the need to offer valid arguments :-).
Rick> The people of whom we speak are long-time members of the Smalltalk
Rick> community who are well known to each other.
A self back-patting clique would be a jaundiced reading of the above.
Rick> Dave is a personal friend and the author of two books on
Rick> Smalltalk. Jan is a well-known and respected consultant. Ralph
Rick> Johnson is one of the best known researchers in the Smalltalk
Rick> community. I wrote most of the IBM Red Book, "Smalltalk
Rick> Portability: A Common Base" and I am secretary of X3J20.
Congratulations!
But we are not discussing the "credentials" of the members of your
clique: I am in no position to offer you or your friends a job, some
members of the audience may be, and I hope that they will make you
suitably rich offers on seeing how impressive your credentials are.
We are engaging in a technical discussion, which perhaps you have not
noticed, and if your arguments are wrong, then your credentials don't
matter, and they would not matter even if your arguments were right.
I am not questioning your credentials: I am questioning the inanity of
your arguments, and your sleazy debating tactics of trying to shift the
question from whether your arguments are valid to whether you are a
clique of important people with credentials. The latter point is taken:
I believe that you are all important people with credentials.
pcg> Yet there are a lot of fluent speakers of many languages that don't
pcg> know its grammar, and think that morphology is an illness -- and
pcg> therefore are howler-prone. That practitioners may well have a low
pcg> level of insight in what they do, and knowledge of "academic"
pcg> material, is fairly common in all disciplines.
Rick> So, maybe French would be better off as a language if L'Academie
Rick> Francaise were composed of high school students who had mastered
Rick> their French I grammar book?
I hope you realize that this is dishonest paraphrase of what I have
written. Fortunately, you have quoted me, and anybody can see the wide
and illicit jump in your paraphrase. Please try to avoid to caricature
dishonestly other people's arguments when you have nothing better to
think.
Rick> Dexterity and fluency in a language are intimately connected with
Rick> understanding and knowledge. It is hard to have either pair of
Rick> attributes without the other.
But it is very easy to have dexterity and fluency without knowledge and
insight, as Jan and Alan and others have argued.
Rick> Again, the issue is not with reading books. We've all read the
Rick> books, and much more literature on the subject. The issue is
Rick> whether reading the books is enough. Most of the folks you've
Rick> flamed on a lack of understanding of Smalltalk,
I have "flamed" their arguments because they were fatuorsly wrong as to
"Smalltalk-80", and I have complained bitterly :-) about their habit as
persons participating in a debate to attribute to me their own words as
if they were summaries of what I have said.
Rick> not only have a mastery of the books you espouse, but have made
Rick> significant additional contributions to the Smalltalk literature.
Why then it has been only me quoting literature and only you making an
issue of how exalted your credentials are?
pcg> In particular the "Smalltalk-80" series which I am happy to mention
pcg> often is rich with insight (not all of which I agree with), and by
pcg> finally getting around to reading those "archeological" books a
pcg> number of participants in this debate would spare me the need to
pcg> type in so many quotes.
Rick> Yes, I've already noticed that you've written that you don't
Rick> completely agree with what is graven in the sacred scriptures.
Please, don't call them sacred scriptures: they might be so to you, or
"archeological" to Jan, but to me they are just important, if flawed,
reference material, that must (ought to!) be studied and understood.
Rick> You seem to eat your cake and have it too.
It may be incomprehensible to you, but knowledge and insight are derived
by study _and_ critical analysis of the scholarly literature. One
without the either is not much useful, and there is no progress without
informed criticism. This is not my own opinion, BTW -- I just repeat
here, because there seems to be a need.
Therefore I can well accept that the "Smalltalk-80" books are the
references for "Smalltalk-80", and then point out the occasional
inconsistencies or errors in them, and in what they describe.
To you or Jan "archeological" or holy scriptures perhaps must be
accepted in toto without criticism or they are "utterly irrelevant", but
that is simply not very interesting.
Rick> You feel free to put down Smalltalk practititioners by referring
Rick> to "Jan's own Smalltalk" or "Rick's own Smalltalk"
No, it's not a put down: I am even naming a ``Smalltalk'' variant after
you and him, you should be pleased :-)
More seriously, I cannot see how it is a put down just pointing out that
you and Jan are being sleazy if you use ``Smalltalk'' as if it were an
unambiguous term: the sleaze is that then you claim the ability to use
it to label anything you want. To counter that I make a point to remind
you that you ought to hyphen/qualify your statements about
``Smalltalk'', and since I don't know which ``Smalltalk'' you are
talking about...
I personally try hard to always discuss the features of a _specific_,
well defined, ``Smalltalk-x'' (usually but not always x = 80), because I
want to make sensible arguments that anybody can check by reading up
some suitable reference material (which I also quote copiously).
Naturally this is because, not being a person with the self-importance
that your credentials give your clique, I cannot claim to be able to
define by my authority what ``Smalltalk'' is.
In effect I would not even if I were the Holy Pope of your church: in
the nearly twenty years I have been studying it I have seen so many
incompatible languages bearing the name ``Smalltalk'' that I regard it
as little more as a generic trademark.
Rick> yet you miss the point that maybe you are arguing about
Rick> Piercarlo's own interpretation of the holy scriptures.
Well, I read that it is impossible to study and make a critical analysis
of _any_ written material without it being a personal analysis. Also,
and again, I do not regard certain books as holy scriptures, and I do
not regard myself as a credentialed member of the clique of the only
true authorized intepreters of the faith.
Besides I have interpreted your "holy scriptures" very little (except
when I have criticized some points, and then I have explained why): I
have mostly quoted massively from them, and anybody can then interpret
them as they wish, and check for themselves if they support or not what
I write. Admittedly it is much less convenient than just believing
whatever comes from credentialed members of the one true clique.
Rick> It is akin to someone saying that they understand Christianity,
Rick> but the Christians don't really believe that Christ was God, do
Rick> they?
Of your dishonest paraphrases and caricatures, this is the least
comprehensible (incidentally, an historically important branch of
christianity does not believe Christ is God).
pcg> Please note that I have characterized "Smalltalk-80: The
pcg> Language", as a widely available, detailed, published base for
pcg> discussion (and to many, for implementation too). There is simply
pcg> nothing comparable as yet.
Rick> As Jonathon rightly points out, this isn't so.
pcg> You wish... I wish it too. But unfortunately a 12 year old book
pcg> is what we got, and we can give thanks it has aged so
pcg> gracefully. According to Jonathan Wong:
Jonathan> I'd also have to say that none of the vendors implements
Jonathan> anywhere near _all_ of the environment described in
Jonathan> Smalltalk-80, however, the base environment, not including
Jonathan> any GUI or application aspects, is about 85% compatible
Jonathan> between all the versions of Smalltalk that I have used,
Jonathan> and with Smalltalk-80.
Rick> But it isn't all we've got, and it isn't up to date. What he have
Rick> is several differing implementations which are quite compatible
Rick> with each other, despite having evolved from what is in the Blue
Rick> Book.
But that has bene my argument precisely! So guess I can agree with you
and Jonathan that the book "Smalltalk-80: The Language" is not only the
definition of "Smalltalk-80", as it claims, but despite being old, it
has aged gracefully enough that it is also relevant today as being the
common base from which many current Smalltalk implementations derive
their being largely compatible with each other. Jan, by contrast, has
argued that the "Smalltalk-80" series is "utterly irrelevant" today.
pcg> and to Dave Buck:
Dave> The basic Smalltalk syntax has changed little since the
Dave> publication of the Blue Book. The only major changes are: [ ...
Dave> not much really IMNHO ... ]
Rick> So, Dave has provided us with a list of additions since the Blue
Rick> Book. The language, unlike Latin, is not dead.
As to this I have said myself as much, when I have mentioned all the
various ``Smalltalk'' variants evolved from Smalltalk-80 and why I
thought it was best to assume as reference material the books describing
their common ancestor: because they are good as reference materials, and
because, as you argue above, all those variants share a large number of
common traits inherited from Smalltalk-80.
Smalltalk-72 instead, just to mention another historically important
version, has neither of those attributes.
Rick> PCG seems to take the position that Smalltalk is quite similar
Rick> to C++ in having a type hierarchy which is closely mapped to the
Rick> inheritance hierarchy.
pcg> This is a fabrication: please find anywhere where I have written
pcg> this inanity.
Rick> I'm sorry that I might have misinterpreted what you have posted
Rick> previously, and I haven't saved it. However, I do remember you
Rick> arguing that Smalltalk had a single rooted hierarchy, and you
Rick> seemed to me to have said that this hierarchy formed a type
Rick> hierarchy. If you didn't say this I apologise, but this is the way
Rick> I remember.
Then you remember incorrectly: for I have said as much of ``Smalltalk-80''.
As you perhaps may also remember, there have been ``Smalltalk''s without
inheritance, for one thing, so any statement that ``Smalltalk'' has an
inheritance hierarchy is not very meaningful. Indeed later on you
suddendly remember it, wo why don't you remember it now?
Also, I have said that Smalltalk-80 classes *are* types as the term is
used in other languages, and that the inheritance hierarchy is exactly a
type hierarchy.
pcg> It is an inanity: because "Smalltalk" is such a loose term that any
pcg> attempt to claim "Smalltalk" has any given feature is meaningless,
pcg> as one can easily find both examples and counterexamples in
pcg> something with "Smalltalk" in its name.
Rick> No! All Smalltalks of which I am aware have certain features, such
Rick> as the ability to form subclasses which don't inherit from object;
Dan Ingalls writes that Smalltalk-7x for some 'x' did not even have
inheritance, so that does not certainly apply to Smalltalk-7x. Neither
does Smalltalk-80, even if the possibility is certainly present if one
creates a variant of it by breaking its definition.
That in Smalltalk-80 _by design_ _all_ classes inherit from object is
written literally in "Smalltalk-80: The Language" and this particular
concept is repeated several times in the book, most of whom I have
quoted so extensively in the past that I will refrain from doing so
here.
I would then conclude that you are not aware of Smalltalk-80 and
Smalltalk-7x, and this indeed tallies with other information.
Rick> the separation of method selectors from any particular inheritance
Rick> graph;
No question about that. This is indeed as described in that reference
series.
Rick> the same base syntax etc. etc. etc. Arguing that we can define
Rick> Smalltalk however we please is the inanity here.
Then show me where is an authoritative definition of what features
"Smalltalk" has or has not, *precisely*. I know of one widely published
one for Smalltalk-80, but none for ``Smalltalk''.
pcg> I have written something about *Smalltalk-80*, as I have made clear
pcg> many times, not ``Smalltalk'', and I have _proved_ that classes are
pcg> what computer science textbooks call types in other language, and
^^^^^^^^^^^^^^^^^
pcg> this is so by design, by quoting literally the book that describes
pcg> Smalltalk-80, and also some popular definition of type, and anybody
pcg> can then see that they are equivalent.
Rick> So here we have restated, the position that you claimed not to have made.
This is appalling shamelessness or ignorance: because there is a lot of
difference between making a claim as to ``Smalltalk'', whatever that
means, and as to *Smalltalk-80*, and you just hope that other readers
don't realize that I make a claim as to the letter, while you had
written, even in your paraphrase of my points, ``Smalltalk'', a term
that, having fully considered you important credentials, you and your
pals feel free to bandy around and define as if you owned it.
Rick> There has been a lot of work on type inferencing in Smalltalk
Rick> which has shown that a type system for Smalltalk needs to be much
Rick> richer than just being based on classes.
Indeed, but we were not discussing type systems in type theory, as you
either ignorantly or dishonestly are trying to pretend.
Your attempts to pretend you read "Smalltalk" when I write
"Smalltalk-80" and "type algebra" when I write "type in other languages":
Rick> For example, Ralph Johnson did a type checked Smalltalk which
Rick> showed that the type algebra needed to be quite rich.
are not merely ignorant, but merely dishonest, for you have written
earlier:
Rick> PCG seems to take the position that Smalltalk is quite similar to
Rick> C++ in having a type hierarchy which is closely mapped to the
Rick> inheritance hierarchy.
thus showing that you had clearly realized that I was comparing like
with like, programming language with programming language.
Unless of course you want to make the even ignorant claim that comparing
language with language or language with mathematics are just the same
thing.
Rick> Ralphs work on TypedSmalltalk is readily available.
If you weren't so important that you don't read other people's articles
you would know that I have mentioned his work already, precisely to make
the point that while Smalltalk-80 is not manifestly typed, there are
variants like Johnson's that do reveal types via type inference (on
variables, not objects as you ignorantly write later). But your
credentials probably exempt you from following an argument.
pcg> I have already stated rather explicitly that I have never taken the
pcg> position you attribute to me, and repeating the allegation even if
pcg> prefixed with "seems" is rather disingenuous, for I have been very
pcg> clear.
Rick> Well maybe not clear enough, since you seem to have just
Rick> reconfirmed my suspicion.
Let's say you have confirmed my suspicion that you are wilfully
attempting to misrepresent what I write:
Rick> PCG seems to take the position that Smalltalk is quite similar to
Rick> C++ in having a type hierarchy which is closely mapped to the
Rick> inheritance hierarchy.
pcg> I have written something about *Smalltalk-80*, as I have made clear
pcg> many times, not ``Smalltalk''.
Enough for now...
Rick DeNatale
thread, as it apparently serves no useful purpose.
None of us have been arguing that inheritance is not or should not be a
feature of Smalltalk, only it's role and how it is used in practice, and
how important specifying a particular inheritance hierarchy is or is not
in standardizing the language.
What I have come to realize is that we have here a classical Kuhnian
paradigm shift. The fact that message sending in Smalltalk is not just a
procedure call is the key fact that is being missed here. It is not a
procedure call, not because it has asynchronous semantics as in an actor
language, which it doesn't, but because it moves all knowledge of the
called object's structure to the called objects side of the interface,
thus eliminating the need for a caller to be concerned with it. This
changes what types are in a way that is easy to miss.
On one side we have PCGs own interpretation of the blue book on the other
we have people who actually use the language and know what it is and
isn't.
In article <vwjwx8c...@osfb.aber.ac.uk>, p...@aber.ac.uk (Piercarlo
Grandi) wrote:
>Rick> 2) The principle of computation via message sending (wasn't this the
>Rick> point you quibbled with in an earlier posting?)
>
>I did not "quibble": I "warned" that while they talk of "message
>sending" they really mean "procedure call", and that while they are free
>to define whatever terminology they want (they could have called "quux
>frobbing" as well, and it would have been better), it is unfortunate
>that they chose terminology already well established to indicate what
>happens in actor languages, thus giving the impression to the innocent
>that Smalltalk-80 is like an actor language, which it is not.
>>>>>>>>>>> In spite of other opinions to the contrary, we consider these to
>>>>>>>>>>> be the hallmarks of the ``object-oriented'' style of
>>>>>>>>>>> computing." ... ["Bits of History, Words of Advice", "The
>>>>>>>>>>> evolution of the Smalltalk Virtual Machine", "Form follows
>>>>>>>>>>> function", page 10]
>
>Piercarlo> [Note: I don't agree as to the merit]
I don't care so much if you agree or not, but I do care on the affect it
has on your argument. We are talking about the base philosophy of
Smalltalk here. As I said above the difference between Smalltalk message
sending and procedure calls is essential for understanding Smalltalk
semantics. Yes, it isn't the same as in actor languages, but it isn't just
a procedure call either. One could argue that a C++ virtual function call
was much closer to just a procedure call (after the caller selected the
procedure based on his knowledge of the callee and its inheritance
structure), but this is quite different from Smalltalk semantics.
>
>Rick> (Dave Smith says that in Smalltalk "All objects have the same
>Rick> shape")
>
>I can claim that they all have the same spins as well -- ``Smalltalk''
>objects are not like certain elementary particles.
I did not claim that they were. However in all Smalltalks they are not
just data structures whose structure the caller needs to understand in
order to pass them to the right procedures.
>Rick> Eating your cake and having it too! You can prove anything from a
>Rick> fallacy.
>
>Ah, please, another of silly misrepresentations. To me that is a fallacy
>as to what OO is, but it true by definition as to what Smalltalk(-80)
>is, and this was the subject of the discussion.
The fallacy is that you seem to reject an essential characteristic of
Smalltalk message sending and then 'prove' things about the relationship
(or is it equivalence) of types and classes in Smalltalk.
>
>>>>>>>>>>> ... "Also, as our experience increased, we came to realize the
>>>>>>>>>>> need for inheritance. This was felt first in the commonality of
>>>>>>>>>>> behavior of Arrays, Strings, and sub-Arrays. For the time being,
>>>>>>>>>>> we referred to common functions from those similar classes so as
>>>>>>>>>>> to factor the behaviour, but it was clear that some sort of
>>>>>>>>>>> inheritance mechanism was needed. ..." ["Bits of History, Words
>>>>>>>>>>> of Advice", "The evolution of the Smalltalk Virtual Machine",
>>>>>>>>>>> "Smalltalk-72", page 13]
>
>Rick> So, you see I have read the literature! This is what I have been
>Rick> saying. Notice that they are talking about factoring behavior,
>Rick> not building a type system.
>
>So what? my argument is precisely that they are talking of classes when
>they are really talking of types. That factoring of behaviour is
>precisely what Cardelli&Wegner calls a type. That they don't call it a
>type is just an incident. Since the term "type" is never used in the
>book (at least it does not appear in glossaries or the index), the
>question is whether 'class' does in fact name the same thing that is
>called a 'type' in other programming languages or not.
Only if you accept your 'proof' that classes are types. I tried to point
out papers in the referreed literature that have proven that classes are
insufficient to be used as types in Smalltalk.
Yes it is unfortunate that Smalltalk seems to have so many faux amis in
it's basic vocabulary. It does tend to make those with casual acquaintance
jump to conclusions.
>
>By quoting the definition of 'class' in Smalltalk-80 and quoting the
>definition of 'type' in some popular CS tract on languages it is obvious
>that they are two names for he same thing, and I have quoted those
>definitions. This argument I have repeated for at least four times
>now. That 'class' in Smalltalk-80 and 'type' in other languages are two
>terms for the same thing has, let me repeat, because I like the sound of
>it, proven.
>
>It is also clear that the authors of the book quoted above are talking
>the term 'class' and not the term 'type' is precisely the reason why you
>and your friends are misled and ignorantly conclude that classes are not
>types, more or less because the two words, not the two concepts, are
>different.
But the concepts are different, a position for which there is more than
enough refereed literature to support.
>
>So: I know that they write 'class' and not 'type', I can read -- but
>they mean the same thing.
Only in PCG's own interpretation of Smalltalk-80.
>
>Piercarlo> So it seems that one should be very careful in eliminating
>Piercarlo> from the language something that was added after considerable
>Piercarlo> experience and that ha proven itself as effective.
>
>Rick> As I said I never said that inheritance should be eliminated. Only
>Rick> that it doesn't form a type system for Smalltalk.
>
>You actually said that you actually have liminated it from your dialect
>of Smalltalk:
>
>Rick> Inheritance is an implementation artifact in Smalltalk.
>
It is just this kind of self contradictory argument that makes me very
weary of this whole discussion.
Look, I did not say that I would eliminate inheritance, only that
inheritance in Smalltalk relates implementations not types. So, maybe I
should have said something like 'Inheritance only produces implementation
artifacts in Smalltalk'
>
>Rick> Inheritance in Smalltalk serves the purpose of allowing
>Rick> implementation of methods and structure to be shared.
>
>Here we go again! Which ``Smalltalk'' are you talking about.
All of them, except perhaps PCG's own interpretation of Smalltalk-80.
>Now, the quotes I have produced _prove_ that in Smalltalk-80 inheritance
>is not an _implementation_ artifact by any means, but a central concept
>of the _language_, and by design after a long dose of experience.
>
>Therefore you cannot be speaking of Smalltalk-80, but presumably "Rick's
>Own" ``Smalltalk'' in which inheritance is not part of the language but,
>as *you* claim, an artifact of its implementation.
>
>Either this or you have expressed yourself very curiously.
Not so much curiously, I think, as the apparent fact that we just don't
have enough common language to have a meaningful discussion.
>Piercarlo> It is also true that one can read:
>
>>>>>>>>>>> ... "While the present Smalltalk design has evolved over a
>>>>>>>>>>> decade now, that does not mean it is finished." ... "
>
>Rick> Which is much of what we all have wasted a lot of words over here.
>
>Indeed! Because you and your pals have been making so many curious
>claims as to your own evolutions of ``Smalltalk'' that is is hard to
>have a clear picture of what it is about. That's why I am harping back
>to the aged but only widely published reference material available that
>has been used as the common base for most all particular
>implementations.
And my argument is that you can't understand, French, or C++, or
Smalltalk, simply by reading grammar books. You MUST be familiar with the
literature written in the language in question.
Piercarlo Grandi
here is explained a bit later. For a brief while the point here is who
has said what, for a brief while:
Rick> Inheritance is an implementation artifact in Smalltalk.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ^ "Rick's Own"
Rick> Historically, Smalltalk had classes before it had inheritance (of
Rick> course this was before Smalltalk-80). [ ... ]
Piercarlo> You can well have your own "Smalltalk" in which inheritance
Piercarlo> is not a part of the language, but is something that happens
Piercarlo> behind the scenes.
Rick> I didn't say that it wasn't part of the language.
Not that I implied this (even if I could, because you state that in your
own ``Smalltalk'' that inheritance is merely an implementation artifact,
not part of the language definition as in Smalltalk-80)...
But simply that there are/have been ``Smalltalk''s, as you acknowledge
before, that do/don't have inheritance. For example Jan to me seems to
advocate that general delegation is a better idea than inheritance for
``Smalltalk'', and he has implemented it in his own (but admittedly he
did not say he has removed inheritance though).
Rick> Inheritance in Smalltalk serves the purpose of allowing
Rick> implementation of methods and structure to be shared.
Here we go again! Which ``Smalltalk'' are you talking about, given that
you have written yourself above about ``Smalltalk''s without
inheritance, including your own? I can only presume, since you don't say
which one it is, that it is your own unpublished version, because
otherwise you could have written "Smalltalk-80", or "VisualWorks" or
whatever, and it is consistent with it being an ``artifact of the
implementation'' of your own ``Smalltalk''.
Piercarlo> But I hope that in your own "Smalltalk" you have some very
Piercarlo> good reason to eliminate inheritance from the language itself
Piercarlo> and make it an implementation detail.
I still hope so, of course, but I have seen no good argument as to why
you have done so yet.
Piercarlo> Making methods attributes of classes and inheritance/
Piercarlo> subclassing are parts of the language definition in
Piercarlo> Smalltalk-80, and for the good reasons explained in:
>>>>>>>>>> "From the first Smalltalk interpreter to the definition of the
>>>>>>>>>> Smalltalk-80 Virtual Machine, the Smalltalk language has been
>>>>>>>>>> characterized by three principal attributes:
>>>>>>>>>>> * Data stored as objects whic are automatically deallocated,
>>>>>>>>>>> * Processing effected by sending messages to objects,
>>>>>>>>>>> * Behaviour of objects described in classes.
Rick> Notice, that inheritance is not one of these three principal
Rick> attributes.
Indeed, because they are listing attributes that are common to all the
variants they have developed, including those initial without
inheritance, which they later admit were not such a good idea.
Rick> What are they? In direct expansion of the above list:
Rick> 1) The provision of automatic storage management (Garbage Collection)
Rick> 2) The principle of computation via message sending (wasn't this the
Rick> point you quibbled with in an earlier posting?)
I did not "quibble": I "warned" that while they talk of "message
sending" they really mean "procedure call", and that while they are free
to define whatever terminology they want (they could have called "quux
frobbing" as well, and it would have been better), it is unfortunate
that they chose terminology already well established to indicate what
happens in actor languages, thus giving the impression to the innocent
that Smalltalk-80 is like an actor language, which it is not.
Rick> (Dave Smith says that in Smalltalk "All objects have the same
Rick> shape")
I can claim that they all have the same spins as well -- ``Smalltalk''
objects are not like certain elementary particles.
>>>>>>>>>> In spite of other opinions to the contrary, we consider these to
>>>>>>>>>> be the hallmarks of the ``object-oriented'' style of
>>>>>>>>>> computing." ... ["Bits of History, Words of Advice", "The
>>>>>>>>>> evolution of the Smalltalk Virtual Machine", "Form follows
>>>>>>>>>> function", page 10]
Piercarlo> [Note: I don't agree as to the merit]
Rick> Eating your cake and having it too! You can prove anything from a
Rick> fallacy.
Ah, please, another of silly misrepresentations. To me that is a fallacy
as to what OO is, but it true by definition as to what Smalltalk(-80)
is, and this was the subject of the discussion.
>>>>>>>>>> ... "Also, as our experience increased, we came to realize the
>>>>>>>>>> need for inheritance. This was felt first in the commonality of
>>>>>>>>>> behavior of Arrays, Strings, and sub-Arrays. For the time being,
>>>>>>>>>> we referred to common functions from those similar classes so as
>>>>>>>>>> to factor the behaviour, but it was clear that some sort of
>>>>>>>>>> inheritance mechanism was needed. ..." ["Bits of History, Words
>>>>>>>>>> of Advice", "The evolution of the Smalltalk Virtual Machine",
>>>>>>>>>> "Smalltalk-72", page 13]
Rick> So, you see I have read the literature! This is what I have been
Rick> saying. Notice that they are talking about factoring behavior,
Rick> not building a type system.
So what? my argument is precisely that they are talking of classes when
they are really talking of types. That factoring of behaviour is
precisely what Cardelli&Wegner calls a type. That they don't call it a
type is just an incident. Since the term "type" is never used in the
book (at least it does not appear in glossaries or the index), the
question is whether 'class' does in fact name the same thing that is
called a 'type' in other programming languages or not.
By quoting the definition of 'class' in Smalltalk-80 and quoting the
definition of 'type' in some popular CS tract on languages it is obvious
that they are two names for he same thing, and I have quoted those
definitions. This argument I have repeated for at least four times
now. That 'class' in Smalltalk-80 and 'type' in other languages are two
terms for the same thing has, let me repeat, because I like the sound of
it, proven.
It is also clear that the authors of the book quoted above are talking
the term 'class' and not the term 'type' is precisely the reason why you
and your friends are misled and ignorantly conclude that classes are not
types, more or less because the two words, not the two concepts, are
different.
So: I know that they write 'class' and not 'type', I can read -- but
they mean the same thing.
Piercarlo> So it seems that one should be very careful in eliminating
Piercarlo> from the language something that was added after considerable
Piercarlo> experience and that ha proven itself as effective.
Rick> As I said I never said that inheritance should be eliminated. Only
Rick> that it doesn't form a type system for Smalltalk.
You actually said that you actually have liminated it from your dialect
of Smalltalk:
Rick> Inheritance is an implementation artifact in Smalltalk.
Now, the quotes I have produced _prove_ that in Smalltalk-80 inheritance
is not an _implementation_ artifact by any means, but a central concept
of the _language_, and by design after a long dose of experience.
Therefore you cannot be speaking of Smalltalk-80, but presumably "Rick's
Own" ``Smalltalk'' in which inheritance is not part of the language but,
as *you* claim, an artifact of its implementation.
Either this or you have expressed yourself very curiously.
Rick> One of our goals in X3J20 is to allow DIFFERING implementations
Rick> which conform to the standard specification.
I am relieved to see that X3J20 will then not adopt "Rick's Own"
``Smalltalk'', because there is a whole world of difference between
having inheritance "as an artifact of its implementation" in your own
``Smalltalk'' dialect and having it in the ANSI Smalltalk language
definition (not merely in its implementation) but leaving the
implementor free as to how achieve it.
Piercarlo> It is also true that one can read:
>>>>>>>>>> ... "While the present Smalltalk design has evolved over a
>>>>>>>>>> decade now, that does not mean it is finished." ... "
Rick> Which is much of what we all have wasted a lot of words over here.
Indeed! Because you and your pals have been making so many curious
claims as to your own evolutions of ``Smalltalk'' that is is hard to
have a clear picture of what it is about. That's why I am harping back
to the aged but only widely published reference material available that
has been used as the common base for most all particular
implementations.
>>>>>>>>>> @ _Reducing Concepts_ It is always useful to reduce the number
>>>>>>>>>> of concepts in a programming language when possible. Smalltalk
>>>>>>>>>> distinguishes many levels of refinement: subclassing,
>>>>>>>>>> instantiation, blocks and contexts, to name a few. It is likely
>>>>>>>>>> that some of these distinctions can be dissolved, and that a
>>>>>>>>>> cleaner virtual machine design would result."
Piercarlo> In other words, perhaps Smalltalk-BETA. Note also the mistake
Piercarlo> here: some of those are _levels_ of refinement, some are not.
Rick> No there is a continuum of refinement here.
Rick> Subclassing - relates behavior based on differences between classes
Rick> instantiation - relates the behavior of instances of the same class
Rick> blocks and context - relates behavior of continuations in the
Rick> execution of the behaviors of individual objects.
The usual problems with insight and knowledge...
There cannot be continuum across different domains, and the relationship
between an instance and its class is _qualitatively_ different from that
between a class and is superclass, and they cannot be put on the same
continuum.
On the other hand the relationship between block and context and class
and instance is _exactly the same_ (instantiation), so they cannot be
_different_ levels of refinement in the same continuum.
>>>>>>>>>> "@ _Typing and Protocols_ While Smalltalk-80 is not a typed
>>>>>>>>>> language in the normal sense,"
Piercarlo> Please note that this _clearly_ means "with manifest types", as the
Piercarlo> subsequent "variable type" and "given variable" makes clear:
>>>>>>>>>> "there is nonetheless an implicit notion of variable type in the
>>>>>>>>>> protocol (full set) of messages which must be understood by a
>>>>>>>>>> given variable.
Rick> What is being said here? That, an object which is held in a
Rick> variable is expected to implement a certain set of messages.
Indeed, and my point was: I was quoting this to show where perhaps some
of erroneous concepts expressed as to Smalltalk-80 and types
come. Smalltalk-80 has types even if the word uses to label them is
class, it just does not have typed variables, even if there is an
inferential notion of type for variables.
Rick> This is what I call a role. that the usage of an object generates
Rick> a 'job description' which is a set of required abilities. The set
Rick> of abilities (methods) provided by an object of a given class is
Rick> effectively a 'resume' or set of credentials which the potential
Rick> employer can test against requirements.
This is a curiously antromorphic discussion that obfuscates the issues,
just like naming the call of a dynamically overloaded procedure name a
"message send".
The main issue is not what the client/employer thinks of an object's
credentials.
The issue is more properly and directly expressed by saying that if _the
implementation_ can deduce statically the type (classes) of objects that
a variable can hold by looking at which selectors are mentioned with
that variable, and checking which types (classes) implement it, than it
can statically "type" the variables, and it can resolve overloads
(selector->methods) at compiletime (and in some cases it can raise
'doesNotUnderstand:' at compiletime too, again like maifestly typed
languages).
This is interesting if possible and there is sufficiently little
ambiguity: if all variables are used with selector 'a:', and all types
have a selector 'a:', then we cannot do much except say the type of the
variable is 'Object', that is not very useful.
If I remember well, Johnson, which did the interesting ``Smalltalk''
variant (that you also have mentioned) that does type inference, found
that in many actual programs genericity is so pervasive that the list of
selectors mentioned for a variable belongs to too many types/classes,
and thus type inference is not that useful.
I have repeated the above description to show the danger of talking in
antropomorphic terms like "client-side", "role", "resume", and cool
ones, and not in common computer science terms in which the picture is
clearer, arguably, both as to merits and demerits.
>>>>>>>>>> @ _Multiple Inheritance_ While Smalltalk-80 does not provide for
>>>>>>>>>> multiple inheritance, we have described an experimental system
>>>>>>>>>> which supports multiple superclasses using the standard Virtual
>>>>>>>>>> Machine[10]. This is another area in which serious use of the
>>>>>>>>>> new paradigm might suggest useful changes to the Virtual
>>>>>>>>>> Machine." ... ["Bits of History, Words of Advice", "The
>>>>>>>>>> evolution of the Smalltalk Virtual Machine", "Future
>>>>>>>>>> Directions", pages 21-22]
Rick> Yes, another interesting experiment. MI was implemented in
Rick> Smalltalk,
^ "Ingall's experimental" ``Smalltalk''
Yet Ingall himself does not write ``Smalltalk'', but ``experimental
system'' (aka ``Smalltalk-of-the-day-at-PARC'') and explicitly disclaims
it being part of Smalltalk-80 as such. This I am happy with: it is
proper and Ingalls evidently can make subtle distinctions that escape
your notice.
Rick> was found not to be needed, and was removed.
That is was found not to be needed is perhaps part of the story (Meyer
in OOSC -- or was that Cardelli&Wegner?) agrees, but for very different
reasons.
But I really object to your usual, absurd if not tricky, use of
``Smalltalk'' as something that has a definite referent, something to
which you can add MI and then remove it.
The words of Dan Ingalls above are clear and precise: there is
Smalltalk-80, documented in some reference books, as there have been
various Smalltalk-7x, and there are temporary experimental systems
derived from Smalltalk-80, or whatever was the current published
definition at PARC. Some of these experimental systems then could have
become, or parts of them, Smalltalk-8x or Smalltalk-9x, but this has not
really happened yet.
Rick> Why? Because, the class hierarchy in Smalltalk is not a type
Rick> hierarchy.
The usual ignorant or dishonest confusions between types in programming
languages and types in algebraic type theory.
Rick> The complications introduced by MI are suffered in strongly typed
Rick> languages such as C++ because they are necessary.
The usual ignorant confusion between strongly typed and dynamically
typed (here at the level of termonology only, because you are right if
you say "dynamically" instead of "strongly").
Rick> Why are they necessary in such languages? Precisely because the
Rick> only way to describe the relationships between types in C++ (and
Rick> they must be described in a strongly typed language)
Then they must be described in Smalltalk-80 too, because it is strongly
typed too.
Rick> is via inheritance, so to describe a type which implements or
Rick> subtypes multiple types, you need MI.
But no, this is the usual ignorant argument -- one that does not realize
that inheritance need not be restricted to mere inheritance of bodies,
but also of interfaces or specification.
Rick> In Smalltalk which has no requirement to describe type
Rick> relationships, MI is not needed, and as it turns out, multiple
Rick> inheritance of implementation is not particularly useful because
Rick> the combination of implementation usually affects the
Rick> implementation thereby obviating the opportunity for sharing.
This is frankly incomprehenensible -- if your argument is that one can
easily cust-and-paste the same method in multiple classes, this is more
or less how Ingall's experimental system did work behind the scenes, and
that was regarded as a bit of quick hack.
NO, you seemed to have hinted at the mainly accepted reason why MI is
not such a pressing in Smalltalk-80, as mentioned for example by either
Meyer or Cardelli&Wegner: because of the combination of latent typing
and absolute encapsulation, one can easily get away with *simulating*
manually MI, much like one did in C++ 1.0 (manual double dispatching for
example), and it is much easier in Smalltalk-80 than in C++ 1.0.
For less ill-conceived notions of type, type algebras, classes and
relationships thereof, that clarify my arguments, I have posted an
article where I have typed in last night for a couple of hours long
mostly sensible excerpts from Cardelli&Wegner, OOSC and OOSLA, and I
hope you will take them more seriously then me, because given that you
make so much of the importance of credentials and so little of the
validity of argument, I have chosen authors with even more impressive
credentials than those of your self-important little clique.
Dave Harris
There is a class hierarchy. Classes are types. There is a
type hierarchy.
What I think you are disagreeing with is this:
The class hierarchy is the same as the type hierarchy.
I don't think Piercarlo ever said that. He certainly doesn't say it in
any quotes in the message to which I am commenting, even though you seem
to think he does.
I think that Piercarlo would agree that the type hierarchy is different
to the class hierarchy; that sub-types are not necessary sub-classes and
vice-versa; and that the class hierarchy is explicit while the type
hierarchy is implicit. I think that you would agree with this also.
Apologies if this is wrong and adds to the confusion. I merely seek
common ground.
Dave Harris, Nashua, NH USA. | "Weave a circle round him thrice,
bran...@cix.compulink.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
- I speak only for myself - | And drunk the milk of Paradise."
Piercarlo Grandi
>>> DeNatale) said:
Rick> What I have come to realize is that we have here a classical
Rick> Kuhnian paradigm shift.
I think it is more like a Grouchian sort of shifty joke. :-)
Rick> The fact that message sending in Smalltalk is not just a procedure
Rick> call is the key fact that is being missed here.
Your credentials allow you to turn howlers into facts? They must be very
powerful indeed!
Rick> It is not a procedure call, not because it has asynchronous
Rick> semantics as in an actor language, which it doesn't,
But there are other differences between message sneding in actor systems
and procedure calls in Smalltalk-80 that are far more important; for
example that actors interpret themselves a message selector, while this
is done by a centralized overload revolver in Smalltalk-80, and that
overload resolution is based on the class chain on an object, while in
actor systems the selection of the code executed to respond to a message
is strictly local to each actor. A fairly reliable summary of all this
is provided in "Object Oriented Languages, Systems and Applications", an
anthology published by Pitman, whose chapter "Basic Concepts II
(Variations on a theme)", on page 62 reads:
"*3.4.1 Actors and Prototypes*
In contrast to the class-based languagesm typified by Smalltalk, are
the 'actor' languages[Hewitt77], [Agha86]. Whereas the class based
languages emphasize structural abstraction in that they are concerned
with the structural organization of data, actor languages are
[NOTE: ^^^^ of code...]
primarily concerned with the communication structure of interacting
processes. Actors are active objects. Each actor consists of an
_acquaintance vector_ which holds its state and a _script_ which holds
the computational element of the actor. Actors are basically
computational agents: they are active processes that communicate by
message passing. These messages are themselves actors. Actors support
an object-oriented style of programming. All actor languages offer
encapsulation: their private state is accessed only through a public
[NOTE:^^^^^^^^^^ this means that actor languages *too* offer
encapsulation, just like class based ones can, not that encapsulation is
unique to them, and turns procedure calls into message sending.]
interface, or protocol.
There is no class/instance distinction in pure actor languages. There
is no natural grouping of instances to form a class of identically
structured entities. There is no shared repository of behaviour, a
role filled by classes in traditional class based systems. There is no
special place that holds a template for instance generation. And, of
course, as there are no classes there are no metaclasses! ..."
[NOTE: there is a weakness in the argument above in that it joins
together the notion of actor system and prototype based system; but
while _usually_ actor languages are prototype based, and _usually_
traditional ones are type based, this is not always the case. This is
discussed in that article further down, where there is a reference to
the Treaty of Orlando.]
The above lines I think convey clearly the impression of why the
standard Smalltalk-80 terminology is misleading: it is exactly identical
to that for actor languages, but the semantics are _completely_ different.
Rick> but because it moves all knowledge of the called object's
Rick> structure to the called objects side of the interface,
To the class of the called object, at least in Smalltalk-80...
Rick> thus eliminating the need for a caller to be concerned with
Rick> it. This changes what types are in a way that is easy to miss.
This is one of the most grossly ignorant statements that I have ever
seen, and really puts in doubt your understanding of the very basics of
Smalltalk-80 and that of OO and programming in general. Firstly, as
Meyer writes in OOSC:
"This, by the way, is not the standard Smalltalk terminology. A
routine is called a ``method'' in Smalltalk; applying a routine to an
object is called ``sending a message'' to the object (whose class must
find the appropriate method to handle the message)."
Note: I would say that Meyer has got much more important credentials
than you, and this should matter to you, who think them so essential.
It appears that you are actually merely describing encapsulation in the
above paragraph, and as if only Smalltalk-80 had encapsulation, and as
if procedure calls in languages with encapsulation were magically
different from those without. As you display to ignore, many OO and non
OO languages that have "procedure calls" offer encapsulation: and I am
on record as stating that a specific encapsulation doctrine is indeed
the central core of the OO paradigm (exactly one ADT implementation per
module, just to remind you). A procedure call does not change nature
because of encapsulation, it remains exactly the same thing: first
name-to-"address" resolution and then transfer of control.
If you were not so ignorant of the very basics of OO and Smalltalk-80 as
in not understanding the simple point above, you could derive benefit
from Cardelli&Wegner's and Meyer's quotes that I have produced in
another article and understand that what you describe as message sending
is exactly the same as any procedure call in any language that offers
encapsulation. The also are very clear as to the other point under
"debate":
... "Simula is the first ``object-oriented'' language. Its notion of
type includes classes whose instances may be assigned as values of
class-valued variables and may persist between the execution of
procedures they contain. Procedures and data declarations of a class
constitute its interface and are accessible to its users." ...
"Subsequent object oriented languages like Smalltalk and Loops combine
the class concept derived from Simula with a stringer notion of
information hiding."
"Thus we say that a language is object oriented if and only if it
satifies the following requirements:
* It supports objects that are data abstractions with an interface of
named operations and a hidden local state.
* Objects have an associated object type.
* Types may inherit attributes from supertypes.
These requirements may be summarized as
object oriented = data abstraction + object types + type inheritance"
... "The requirement that all objects have a type allows objects to be
first-class values so that they can be managed as data structures
within the language as well as used for computation. The requirement
of type inheritance allows relations among types to be specified.
Inheritance may be viewed as a type composition mechanism that allows
the properties of one or more types to be reused in the definition of
a new type. The specification ``B inherits A'' may be be viewed as an
abbreviation mechanism that avoid redefining the attributes of type A
in the definition of type B. Inheritance, however is more than a
shorthand, since it imposes structure upon a collection of related
types that can greatly reduce the complexity of a system
specification. This is illustrated by the Smalltalk object hierarchy
in Goldberg and Robson[1983]."
This is all from Cardelli&Wegner "On Understanding Data Types ...". They
too seem to haver much bigger credentials than you and your little
clique. Not that to me it matters much: I value arguments, not
credentials, and here and there Cardelli&Wegner's arguments in that
article are very criticizable. Yet the arguments above are clear and
quite reliable (except that I think that their third point is too
specific, as it prescribes inheritance among classes instead of any
suitable reuse mechanism among either classes or objects).
Rick> On one side we have PCGs own interpretation of the blue book on
Rick> the other we have people who actually use the language and know
Rick> what it is and isn't.
On one side we have literal quotes from books by the authors of
Smalltalk-80, and from Cardelli&Wegner, and from Meyer, and others, and
on the other a clique that bandies around credentials as if they were
arguments.
Rick> We are talking about the base philosophy of Smalltalk here.
As if you understood the least of it...
Rick> As I said above the difference between Smalltalk message sending
Rick> and procedure calls is essential for understanding Smalltalk
Rick> semantics.
But there is no such difference, as you should know, and as Meyer knows,
as if you understood Smalltalk-80 and the design of languages, OO and
not OO, in general.
Rick> Yes, it isn't the same as in actor languages, but it isn't just a
Rick> procedure call either. One could argue that a C++ virtual function
Rick> call was much closer to just a procedure call (after the caller
Rick> selected the procedure based on his knowledge of the callee and
Rick> its inheritance structure), but this is quite different from
Rick> Smalltalk semantics.
If you are so sure, please describe in what way CLOS and Eiffel
procedure calls are different from "message sending" in Smalltalk-80.
Rick> (Dave Smith says that in Smalltalk "All objects have the same
Rick> shape")
pcg> I can claim that they all have the same spins as well --
pcg> ``Smalltalk'' objects are not like certain elementary particles.
Rick> I did not claim that they were.
Nor did I imply this. Please stop being sleazy with innuendo and
insinuation and trying to put word sinto my mouth!
My point here, even if you feign to not see it, is that a phrase like
"All objects have the same shape", which you attribute to poor Dave
Smith, is a colossal inanity: for objects don't have shape, don't have
spin, don't have colour, don't have mass, don't have flavour, and any
phrase like "All objects are the same height" is just meaningless
inanity.
Rick> However in all Smalltalks they are not just data structures whose
Rick> structure the caller needs to understand in order to pass them to
Rick> the right procedures.
Exactly like in any language, OO or not, that has encapsulation. Have
you ever heard of Alphard? SML? CLU? CLOS? Eiffel? No of course.
Rick> Only if you accept your 'proof' that classes are types. I tried to
Rick> point out papers in the referreed literature that have proven that
Rick> classes are insufficient to be used as types in Smalltalk.
I have never seen a single bibliographic reference from you, not to say
a quote; perhaps my newsfeed is losing articles (it does
occasionally).
There are papers that prove that classes are types in Smalltalk-80, and
I have quoted those richly; there are some that prove a completely
different thing: that types in any programming language can form
lattices that are not identical to those formed by type denotations in
algebraic type theory (mainly because more than one type can have the
same type denotation).
If you cannot make the distinction between those two very different
points you are hopelessly ignorant of programming languages and the
theory behind them and I wonder how you happened on an ANSI language
standardization committee.
pcg> By quoting the definition of 'class' in Smalltalk-80 and quoting
pcg> the definition of 'type' in some popular CS tract on languages it
pcg> is obvious that they are two names for he same thing, and I have
pcg> quoted those definitions. This argument I have repeated for at
pcg> least four times now. That 'class' in Smalltalk-80 and 'type' in
pcg> other languages are two terms for the same thing has, let me
pcg> repeat, because I like the sound of it, proven.
pcg> It is also clear that the authors of the book quoted above are
pcg> talking the term 'class' and not the term 'type' is precisely the
pcg> reason why you and your friends are misled and ignorantly conclude
pcg> that classes are not types, more or less because the two words, not
pcg> the two concepts, are different.
Rick> But the concepts are different, a position for which there is more
Rick> than enough refereed literature to support.
If you dare to do so, quote it, liar. You are lying shamelessly here.
I have now quoted hundred of lines of Cardelli&Wegner and Meyer and
others that explicitly say that in Smalltlak-80 and in OO in general
classes are the concept as types in other languages.
Rick> As I said I never said that inheritance should be eliminated. Only
Rick> that it doesn't form a type system for Smalltalk.
pcg> You actually said that you actually have eliminated it from your
pcg> dialect of Smalltalk:
Rick> Inheritance is an implementation artifact in Smalltalk.
Rick> It is just this kind of self contradictory argument that makes me
Rick> very weary of this whole discussion. Look, I did not say that I
Rick> would eliminate inheritance, only that inheritance in Smalltalk
Rick> relates implementations not types.
Rick> So, maybe I should have said something like 'Inheritance only
Rick> produces implementation artifacts in Smalltalk'
It's very convenient to change after the fact 'inheritance is' to
'inheritance produces'. 'to be' and 'to produce' are two extremely
different concepts. Didn't you say you dabble in producing language
standards?
Besides, the news are: `Smalltalk'' is an _implementation_ language.
Everything in ``Smalltalk'', or Eiffel, or CLOS, or CLU, or Mesa, or
Neliac, or JOSS, is "an implementation artifact". Creating
"implementation artifacts" is called "programming". Notations in which
"implementation artifacts" are described are called "programming
languages". ``Smalltalk'' is not a religion with holy bibles and inner
circles of high priests, it is a "programming language".
I had put Alphard and Euclid in the list above and then I realized my
mistake, not that you would know it, of course :-).
Rick> And my argument is that you can't understand, French, or C++, or
Rick> Smalltalk, simply by reading grammar books. You MUST be familiar
Rick> with the literature written in the language in question.
Which obviously I am and you are not, for I have quoted oodles of
literature and you haven't. Besides I can appreciate well the immense
variety in ``Smalltalk'' and their design philosophy: for almost twenty
years I have done so, starting with a quickie Lisp emulation of
Smalltalk-72 so long ago.
Incidentally, I recently discovered in an old "Lisp pointers" issue a
pointer :-) to a truly amusing and probably quite useful thing: an
_Emacs Lisp_ module that implements an uncannily Smalltalk-80 like OO
extension. Much better than my early proof of concept for UW Lisp:
eoops is available from ftp.cs.ucla.edu:/pub, for those that like the
genre.
You have also demonstrated a worrying lack of understanding of the
Smalltalk-80 literature that I have quoted, and entirely ignorant
misconceptions about procedure calls and encapsulations and the various
referents fro the notion of "type".
But don't worry I have partially agreed that:
>>> People seem to get upset with the notation that your life can
>>> be better and you can be more effective if you believe false
>>> things. In this case, I think the reason that Smalltalk
>>> programmers are so effective when they believe false things
>>> about their language is that quotes like
ST80> "An object consists of some private memory and a set of
ST80> operations". [Objects and messages, page 6] "Computing is
ST80> viewed as an intrinsic capability of objects that can be
ST80> uniformly invoked by sending messages." [Objects and messages,
ST80> page 6]
>>> describe an ideal language that the designers of Smalltalk were
>>> striving for.
I have even agreed that:
>>> Smalltalk, like every other human artifact that is useful and
>>> regularly used, is a living system. [ ... ] Most people on this
>>> list are interested in Smalltalk as a tool to build applications,
>>> not as a tool for reasoning about languages.
even if the mental doutblethink involved seems to me can get even
application programmers into trouble. I can acknowledge there is
experimental evidence that even people who erroneously conceptualize
``Smalltalk'' can acquire dexterity and fluency to the point they can
put together working applications (this happens also in the C++ culture,
where most programmers don't really have the background to understand
C++ fully, but manage to deliver product nonetheless).
But let me add that I agree also that
>>> Smalltalk implementors and people who worry about formal
>>> semantics may not think this way (and probably shouldn't), but
>>> application programmers usually do.
and let me add to the list: member of language standardization
committees, unless of course they are there to represent all those users
that are comfortable with believing cool but false things about
``Smalltalk''.
This discussion is turning into a remedial course on basic language
design concepts for self-important ``Smalltalk'' hackers. Well, it's a
public service :-) (I will gratefully accept donations, though).
Piercarlo Grandi
>>> Harris") said:
"Dave> What I think Piercarlo Grandi is saying about Smalltalk 80 is this:
Dave> There is a class hierarchy. Classes are types. There is a type
Dave> hierarchy.
Yes, indeed. and also:
Dave> What I think you are disagreeing with is this:
Dave> The class hierarchy is the same as the type hierarchy.
Dave> I don't think Piercarlo ever said that. He certainly doesn't say
Dave> it in any quotes in the message to which I am commenting, even
Dave> though you seem to think he does.
But if classes *are* types then the class hierarchy is the same as the
type hierarchy. Note the "are": not "represent" or "implement".
Dave> I think that Piercarlo would agree that the type hierarchy is
Dave> different to the class hierarchy; that sub-types are not necessary
Dave> sub-classes and vice-versa; and that the class hierarchy is
Dave> explicit while the type hierarchy is implicit.
No, this is all wrong, if one is talking of types as in programming
languages, such as Smalltalk-80. It is all right if were discussing type
theory models, but that's something that bears no relationship to the
present discussion as to whether Smalltalk-80 is a (dynamically,
latently) typed languaged or not.
Dave> Apologies if this is wrong and adds to the confusion. I merely
Dave> seek common ground.
The confusion is merely one of concepts: there are papers like the
classic "inheritance is not subtyping" that clearly show that the
lattice of classes/types in a programming language does not necessarily
have a one-on-one mapping on the type denotation lattice in a
mathematical model of types. As such this is a moot point: types in
programming languages *are* not types in type theory, they _represent_
them.
Basically what Alan and Rick are now doing, either ignorantly or
dishonestly, is to compare classes in programming languages with their
type denotations in abstract type theory, which are indeed completely
different things, with (possibly) differently shaped lattices; but this
is completely irrelevant to the issue of whether Smalltalk-80 is a typed
language and its types are merely called 'classes'.
That they are doing so sleazyly and not merely ignorantly is that I
have repeatedly emphasized the qualification "in other languages", and
that Rick himself has acknowledged that I am comparing the notion of
type in Smalltalk and in C++, two _languages_.
But the discussion has always been on a comparison between the concept
of class in Smalltalk and the concept of type in _other languages_, as I
have emphasized often, not of type _denotations_ in _type theory_, as
Alan and Rick are now trying to make appear.
I hope that the extensive quotes from Cardelli&Wegner and Meyer that I
have posted separately will make it very clear to everybody that classes
in Smalltalk are indeed the types in other OO and non OO languages, and
that classes/types in programming languages are very different from
their denotations and models in type theory, and cannot be compared
directly.
Dave Harris
> What I have come to realize is that we have here a classical Kuhnian
> paradigm shift. The fact that message sending in Smalltalk is not just a
> procedure call is the key fact that is being missed here. It is not a
> procedure call, not because it has asynchronous semantics as in an actor
> language, which it doesn't, but because it moves all knowledge of the
> called object's structure to the called objects side of the interface,
> thus eliminating the need for a caller to be concerned with it. This
> changes what types are in a way that is easy to miss.
But normal, static procedure calls can provide the same shift. For
example, one can use C (FILE *) routines (fclose(), fread() etc) without
knowing or caring about the structure of a FILE object. It's true that
the caller in C knows more than the caller in Smalltalk - my point is
that more enlightened programmer can experience the same paradigm shift
with a lesser technology.
Smalltalk enhances the power of abstract data types by combining them
with dynamic dispatching. There is a general principle here. Doing
anything dynamically - that is, at run time rather than at compile time -
gives you greater power and flexibility.
Part of this debate has been about whether doing something at run time
justifies giving it a new name. I am one of those who believes it
doesn't. I prefer to take the old name and prefix it with "static" or
"dynamic" as appropriate. Thus I prefer "dynamically dispatched procedure
call" to "message send". I prefer "dynamic type-checking" to "class".
My reason for this is that dynamically dispatched procedure calls have a
great deal in common with statically dispatched ones. It makes sense to
me to extract that common part and call it "procedure call", so that we
can talk about it independently of whether it is static or dynamic. For
example, the issue of whether you dispatch on one argument, as in
Smalltalk, or on multiple arguments, as in CLOS, is (or ought to be)
orthogonal to whether the dispatching is static or dynamic.
Similarly, using the "dynamic" prefix emphasises the costs and benefits
that we know are common to anything done at runtime. Using new names
tends to cover up the commonality.
I do sympathise with those who believe the paradigm shift deserves to
honoured by new names. The problem is that you can't draw a line at the
exact point the shift occurs. For some people, fclose() should be called
a "message send". Others will remain unenlightened even by Smalltalk. You
can't label shifts, you can only label technology.
The Dylan crowd have a good handle on this. By promulgating the notion of
"dynamic languages" they've shifted the focus away from mere object
orientation and abstract data types.
Dave Buck
Piercarlo Grandi <pier...@sabi.demon.co.uk> wrote:
>But there are other differences between message sending in actor systems
>and procedure calls in Smalltalk-80 that are far more important
Ok, maybe you can help me distinguish the difference between your
definition of a procedure call and a message send. In the following
steps, I will slowly transform Smalltalk into an actor system. I
would be honored to have you call any intermediate stage you wish
"Dave's Own Smalltalk". What I want to know is when did I change from
procedure calls by your definition to message sends.
Step 1: I change all classes so that they all inherit from nil (i.e.,
have no superclass) but I give them all copies of the methods they had
before. Calls to super are translated to different method names, eg.
"super initialize" is translated to "self superInitialize". This
system will work identically to the previous system except in cases
where methods ask questions about the class hierarchy explicitly (like
isKindOf:, class, etc.) For all of these messages, I explicitly
implement a method for each class to return the same result as I would
have returned if I had a class hierarchy. Now, it's impossible for
any Smalltalk code to distinguish between this system (which has no
class hierarchy and no inheritance) and the previous one. By
eliminating the class hierarchy, I've eliminated the emphasis on the
class structure. Am I sending messages yet?
Step 2: I take every instance in the system and change its class to be
a copy of the class. (There are problems in doing this with
SmallIntegers and Metaclasses, but let's not worry about this right
now). Now, every object has its own private "script" which determines
how that object responds to messages if we want to call them messages.
Do we?
Step 3: I change the implementation of the Smalltalk virtual machine
so that "call" creates a message object containing the selector, the
arguments, and the return value.. Then, the virtual machine uses this
message object as a simple structure wherever it would have referred
to the selector, arguments, or return value directly in the old
system. Note that this step is implemented completely in the virtual
machine and has no impact (besides performance) on the virtual image.
Did that turn it into message sending?
Step 4: I change the virtual machine so that every object corresponds
to a different thread. I add one more thread for the message lookup
system. Now, when a method tries to invoke another method, the
calling thread performs an asynchronous rendez-vous with the virtual
machine thread, the virtual machine thread performs the method lookup,
and then performs an asynchronous rendez-vous with the receiver's
thread. This was all done transparently by the virtual machine and no
changes were needed in the virtual image. Did that make it message passing?
Step 5: I change the virtual machine again so that the method lookup
happens to be done in the thread for the receiver rather than the
thread for the virtual machine. The thread for the virtual machine
can now be eliminated. Is it message passing now?
What's the difference between the final system and an actor system?
Does this difference constitute the difference between message passing
and procedure calls?
>is done by a centralized overload revolver in Smalltalk-80, and that
^^^^^^^^^^^^^^^^^
Revovler on overload!!! Evacuate decks 23-35!! Brace for impact!!
(Sorry, I couldn't resist) :-)
David Buck
db...@ccs.carleton.ca
_________________________________
| David K. Buck |
| db...@ccs.carleton.ca |
| The Object People |
|_______________________________|
John Sellers
In Article<yf320qj...@sabi.demon.co.uk>, <pier...@sabi.demon.co.uk>
writes and writes and writes and writes:
[ comments deleted ]
Well my comments are:
There once was a lady named Bright,
Who traveled much faster than light.
She went on her way, the relative way,
and came back the previous night.
---Unknown
or perhaps:
But I keep no log of my daily grog,
For what's the use o' being bothered?
I drink a little more when the wind's off shore,
And most when the wind's from the north'ard.
---Arthur Macy, The Indifferent Mariner.
in any case all I am doing is making a little "small talk". :-)
Matthew B. Kennel
: dena...@nando.net (Rick DeNatale) wrote:
: > What I have come to realize is that we have here a classical Kuhnian
: > paradigm shift. The fact that message sending in Smalltalk is not just a
: > procedure call is the key fact that is being missed here. It is not a
: > procedure call, not because it has asynchronous semantics as in an actor
: > language, which it doesn't, but because it moves all knowledge of the
: > called object's structure to the called objects side of the interface,
: > thus eliminating the need for a caller to be concerned with it. This
: > changes what types are in a way that is easy to miss.
: But normal, static procedure calls can provide the same shift. For
: example, one can use C (FILE *) routines (fclose(), fread() etc) without
: knowing or caring about the structure of a FILE object. It's true that
: the caller in C knows more than the caller in Smalltalk - my point is
: that more enlightened programmer can experience the same paradigm shift
: with a lesser technology.
: Smalltalk enhances the power of abstract data types by combining them
: with dynamic dispatching. There is a general principle here. Doing
: anything dynamically - that is, at run time rather than at compile time -
: gives you greater power and flexibility.
I think people are focusing on the wrong thing. "message calls" can look
like subroutine calls.
But, if 'messages' themselves may be manipulated as data values independently
of the particular target and arguments, then you have something new compared
to Fortran-subroutines.
For instance, from 3 stacks computed from independent sources, pop off
'target', 'message', and 'arguments', shaken, not stirred.
: The Dylan crowd have a good handle on this. By promulgating the notion of
: "dynamic languages" they've shifted the focus away from mere object
: orientation and abstract data types.
So what is it exactly that you get?
We do know what we lose:
you get bad performance or need "heldenoptimization".
: Dave Harris, Nashua, NH USA. | "Weave a circle round him thrice,
Piercarlo Grandi
>>> mbk@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Matthew
>>> B. Kennel) said:
Matthew> I think people are focusing on the wrong thing. "message calls"
Matthew> can look like subroutine calls.
Matthew> But, if 'messages' themselves may be manipulated as data values
Matthew> independently of the particular target and arguments,
Here it is not clear whether you mean 'selectors', or 'instantiated
message patterns'. If it is the latter, then you have essentially
closures/continuation, ala scheme 'call/cc', and that indeed gives a lot
more power than nested, ephemeral procedure instances only. But that's
called 'continuation passing', not 'message passing', and continuation
passing is not exactly a natural style in Smalltalk-80 (strictly
speaking it is not even really possible -- blocks have to be generalized
for that, e.g. as in Mario Wolckzo's Mushroom dialect, and in some
recent commercial implementations).
Matthew> then you have something new compared to Fortran-subroutines.
This is indeed true: but FORTRAN procedure calls are of the very most
primitive kind, for there is no overloading nor any dynamic overload
resolution, just strightforward static resolution from name to address.
Let's consider instead procedure calls in say Lisp or Eiffel or whatever
language has either overloading or dynamic overload resolution, and the
expressive power is completely different, and indeed identical to
Smalltalk-80's message sending (but, in some of those, for the
reflective abilities of Smalltalk-80 implementations).
My point about the poor choice of terminology in Smalltalk-80 is in this
respect is twofold:
* the mechanism is completely different from those of the same
name in actor systems *and* distributed programming.
* the mechanism is essentially identical to that used in other
advanced OO and non OO languages where it is called
differently.
I am not making the point that Smalltalk-80 'message sending' is bad
technology or it is as limited as the mechanism in FORTRAN: simply that
the terminology suggests a similarity where there is a difference and a
difference where there is a similarity.
The latter is especially bad: if the Smalltalk-80 mechanism had been
called 'glop zonking', which has (as far as I know) no established
meaning, one could have wondered why give a different name to a similar
mechanism, but at least the problems of giving a similar name to
different mechanism would not have arisen.
The latter confusion is especially confusing because in fact in the
intellectual ancestry of Smalltalk there are actor systems, and the
process/simulation primitives in the Smalltalk-80 library do in fact
support a real message sending mechanism, so one could well be left
with the impression that the mechanism 'message sending' is in fact
different from that of other non-actor languages.
Matthew> For instance, from 3 stacks computed from independent sources,
Matthew> pop off 'target', 'message', and 'arguments', shaken, not
Matthew> stirred.
Here you seem to be mentioning the powerful reflective capabilities
connected to the ability to have closures/continuations. Forth has
something similar, now that I think of it (at times too much reflectivy,
I also hear).
Given that I always try to show off my knowledge of obscure languages,
only in Hanson's SL5 (the "successor" of Icon :->) of all languages that
I have seen one had clean, full reflective access to the three steps
involved in a procedure call. A pity other languages don't too.
Alan Lovejoy
(Piercarlo Grandi) writes:
>
>>>> On 2 Dec 1995 10:33:28 GMT, love...@ix.netcom.com (Alan Lovejoy )
>>>> said:
>
>AL> (PG Grandi) writes:
>
>PG> I have written something about *Smalltalk-80*, as I have made
>PG> clear many times, not ``Smalltalk'', and I have _proved_ that
>PG> classes are what computer science textbooks call types in
>PG> other language, and this is so by design, by quoting
> ^^^^^^^^
>PG> literally the book that describes Smalltalk-80, and also some
>PG> popular definition of type, and anybody can then see that
>PG> they are equivalent.
>
>AL> But even in Smalltalk-80, as defined by the Blue Book, it is
>AL> possible to define two classes with different implementations, and
>AL> different inheritance hierarchies, which respond to exactly the
>AL> same messages with exactly the same semantics, preconditions and
>AL> postconditions.
>
>Perhaps you should check entry level literature on programming
languages
>before confusing a type and its interface/specification. Such
confusions
>are popular in comp.object, and even in much of the research
literature,
>but ignorance is no excuse, not only in the law.
Bullshit! See below.
>I have already made at length (over the past five years in
comp.object)
>the point that the distinction among the three aspects of a
type/class,
>interface, body, and semantics specifications, is not carried further
>enough in most languages, including ``Smalltalk'', and the ability to
>have many-many associations of each aspect with other aspect is
instead
>very useful, and I have even given a simple example (a deque type).
Fine. But apparently non-sequitur: In the part of my post you didn't
quote, I myself highlighted the importance of distinguishing interface
from implementation, semantics from mechanics.
>AL> Instances of two such classes have the same "type" because they
>AL> respond to the same messages in the same way, but their classes
>AL> are different. This proves that a class is an implementation of a
>AL> type--it is not itself a type.
>
>No, it only proves that:
>
>A) you are prone to "confuse" the denotation of a type, and the type
> itself.
Me? Confuse a sign with its referent? A symbol with its meaning? A
map with the territory it depicts? Perhaps I have not correctly
understood your previous posting, but at least I know the difference
between a type "in other languages", a class, an interface
specification, a semantic specification and a particular implementation
thereof.
If you really think a class is a type, then it is you who are confusing
form and content.
>B) you don't "remember" that type denotations, being in the domain of
> mathematical entities, cannot by definition be expressed at the
> language level, therefore by discussing "type" in the context of
> ``Smalltalk'' (not the feline variety!) we could not possibly have
> been using "type" as an abbreviation for "type denotation" (not for
> "type interface"/"type spefication").
I have to admit that I misinterpreted what you said in the post to
which I responded. But that wasn't because I didn't "remember that
type denotations, being in the domain of mathematical entities, cannot
by definition be expressed at the language level." No, it was because
it never occured to me that anyone could seriously believe that
"classes are what computer science texbooks call types in other
languages," where the word "type" refers to "some popular definition of
type." So I mistakenly interpreted what you said assuming you actually
had a clue about objects and classes, and so of course could only be
referring to a concept of "type" that actually has any utility in
Smalltalk.
But I now see I was very mistaken. I should have taken you literally
the first time, instead of giving you the benefit of the doubt.
At the end of this post, I'm going to thoroughly refute your thesis
that classes are identical to types "in other languages." But first:
>C) you have not been following this thread, because I have had to
> "remind" other people of all the points above already.
Well, guilty as charged. So who has time to follow even all the
interesting threads--let alone all threads?
And you're the one who brought this thread to my attention, as you well
know. You may come to regret that...
>AL> I would suggest reading the OOPSLA proceedings from the past ten
>AL> years. There have many papers presented there and elsewhere that
>AL> address these issues.
>
>I would suggest reading some entry level textbook on mathematics, type
>theory and languages and their relationship. Without having read those
>your ability to make sense of those OOPSLA articles (if you have read
>them yourself, which does not seem the case, because in some of them
the
>distinction between interface/body/semantics is clear) will have been
>severely reduced by the lack of basic insight.
Hmmmm... We both seem to have read these things. But we have come to
quite different conclusions on the rather fundamental subject of the
relationship of classes and types.
But my interpretation of the literature is the same (more or less) as
that of the acknowledged experts in OOP, some of whom you have been
arguing with in this thread. That should at least make you consider
the possibility that your interpretation just might be wrong.
When a member of the ANSI Smalltalk standards committe tells you you're
completely mistaken on such a fundamental point, you should at least
find another equivalently-credentialed expert who agrees with you. Can
you produce one?
At the very least, you should realize that in such a situation you have
no standing to be making the insulting comments and personal attacks
that you have been engaging in--even if you're right!
>I would suggest that it would also be polite of you to read other
>people's past articles before repeating all over again the same
>inanities.
Why would I want to read your past articles? You have to first
convince me that your current articles are worth reading due to their
sagacity, intelligence and insight. So far, the posts of yours I have
read are convincing me quite otherwise. When I saw your claim that
types are identitical to classes, that alone suggested to me that
reading your past posts would be a waste of time.
I think we're ready now for that promised refutation of your thesis
that Smalltalk classes are equivalent to "types in other languages."
Note that I'm explicitly referring to **Smalltalk** classes--not C++
classes, nor Eiffel classes, nor "class" as used in any other language.
So what is "a popular definition of type" as it can be found in "other
languages?" Well, the most "popular" of the strongly "typed"
languages, especially in the domain of computer science instruction at
a university, has to be Pascal [Wirth]. So I will use the Pascal
concept of type as my canonical example of "type"--with some
terminology help for those who are familiar with "C" but not with
Pascal. I think I have every justification in the choice of Pascal,
given the words you have used to specify what you mean by "type" in the
postings of yours I have read. And later, I will even consider a
somewhat different example: the abstract data type, as found in
languages such as CLU [Liskov], Ada [Ichbiah] and Modula-2 [Wirth].
[Much of what I am about to say will be well known to many readers, but
I want to keep the discussion as widely accessible as possible].
A "type" in Pascal has the following properties/functions:
1) A type specifies the semantic interpretation of the bits in a value.
Example: the semantic interpretation of a 32-bit value whose type is
INTEGER is different than for one whose type is PACKED SET OF 0..31.
In other languages, one can use different types to interpret the
same bits as either a signed or unsigned number. The point is that
the meaning of the bits is determined by the type.
2) A type specifies the storage structure of a value. For example,
two RECORDs might have the same "fields" but in a different order.
Or two RECORDs could have fields with the same names in the same
order, but the fields themselves could have different types (a
Pascal "RECORD" is analogous to what "C" calls a "struct.)" Another
example of a difference in storage structure: some implementations
of FORTRAN provide different REAL types so that floating point
values can be represented using either IEEE format or some floating
point format native to the hardware (the FORTRAN/Pascal type REAL is
called "float" in "C"). Same number of bits, same external
semantics (floating point number), same interface (+, -, *, etc),
but different structure.
3) A type specifies the storage size of a value. In Pascal, this is
limited to array/set bounds and the number of fields in a record.
In other languages, multiple numeric value sizes are typically
supported(short int, long int, float, double, etc).
4) A type is bound to an address (variable or typed pointer), not to
a value. The "type" of a value is not an organic property of the
bits of the value itself, but rather of the variable in which it is
stored (or the type of the pointer that points to it). The type of
a value can easily be changed by moving the bits to a different
address, by assigning its address to a typed pointer, or by using a
non-discriminated union (a "variable record without a tag value" in
Pascal lingo). Not all languages (or all implementations thereof)
support all forms of type casting, but they generally support it in
some form or other--even if it's not "standard".
5) A type constrains the values that may be stored at an address.
Either the language won't let you store a ColorValue in an ARRAY OF
STRING, or else the assignment "casts" the bits of the ColorValue
RECORD to be reinterpreted as the bits of a STRING--probably
destroying any rational meaning of the bits.
6) A type constrains the values that may be passed as parameters to
a procedure, function or operator. Either the language won't let
you call the intrinsic SQRT function with a SET as the argument, or
else the procedure/function/operator "casts" the bits to the
formally specified type--and thereby probably destroys the semantics
of the bits.
7) A type not only constrains the values of the actual or formal
variable to which it is bound, it also recursively (and
syntactically) constrains the values/types of the values that
compose its structure. Example: the Pascal type defined by
"TYPE ColorValue = RECORD red, green, blue: INTEGER END" not only
defines the size/structure/semantics of a variable whose type is
ColorValue, it also constrains the fields ("slots") of the record to
be INTEGERs. Types define the transitive closure of the structure
and semantics of their values down to the bit level.
8) A type is not a value. It cannot be stored in a variable, passed as
an argument to a user-defined procedure/function, nor dynamically
created by program logic.
9) A type determines syntactically (lexically) what operators,
functions and procedures can be applied to values of the type.
By contrast, a Smalltalk class has the following properties/functions:
1) A class specifies the semantic interpretation of the instance
variables, indexed instance variables (variable subclass), bytes
(variable byte subclass) or bits (immediate class) of its instances.
There does appear to be some analogy here to what types do. But the
analogy is far from an equivalence: a type **syntactically**
specifies the types of its component parts, a class can only specify
the "roles" of the instance variables of its instances--and not
syntactically, but only algorithmically. This won't prove your
thesis.
2) A class specifies the names and ordering of named instance variables
in its instances (analogous to RECORD fields), the presence or
absence of indexed instance variables (analogous to the type
constructor ARRAY, a higher-order function), whether any indexed
instance variables contain objects or byte values (analogous to the
two types "ARRAY OF OBJECT" and "ARRAY OF BYTE"), or whether the
instances are "immediate values" (roughly analogous to simple
numeric types). So over all, the fact that types and classes both
specify the structure of their values/instances is by far the best
analogy between classes and types. I assume it is what motivates
your thesis. It in no way proves it, as we shall see.
3) A class specifies the number of named instance variables in its
instances--it does not specify the number of indexed instance
variables in its instances. There is some analogy to types here,
but this won't prove your thesis either.
4) A class is bound to an object (value), not to an address. The class
of an object is an organic property of its bits, not of its address.
This is one of the key distinctions between classes and types. This
point disproves your thesis all by itself--but I intend to be
thorough.
5) A class cannot be used to constrain the objects that can be stored
in an instance variable, because the language provides no syntax for
constraining the class of an object to be assigned to an instance
variable. Nor does assigning an object to a variable ever change
the class of the object. This is another key distinction between
classes and types--and it's another nail in the coffin of your
thesis.
6) A class cannot be used to constrain which objects can be passed as
arguments to methods. Nor will passing an object as an argument ever
result in "class aliasing" of the object. In fact, you can't even
syntactically constrain which messages can be sent to which objects
(more on this later). This nail in the coffin of your thesis is the
twin of the previous one.
7) A class cannot syntactically constrain the class of objects that
will be stored in the instance variables of its instances. It does
not syntactically specify the transitive closure of the object graph
rooted at one of its instances. This is the key difference between
a traditional type and an abstract data type (hereafter, "ADT").
This property is called "encapsulation" or "information hiding"
[Parnas]. Classes and ADTs have it. Pascal types don't. Yet
another divergence between your thesis and reality.
8) A class is an object--and therefore a computable value. It can be
stored in a variable, passed as an argument to a method, and
dynamically created by program logic. This is another fact that
disagrees with your thesis.
9) A class does not determine syntactically (lexically) what messages
can be sent to its instances. The fact that sending some messages to
some objects results in a substitution of the original message with
the message #doesNotUnderstand: is not a syntactic constraint nor an
indication of linguistic illegality: it compiles without error.
Besides, the messages that the instances of a class "respond to" can
change dynamically over time as the program runs. Yet another
reason your thesis is proven to be wrong.
And of course, Pascal types don't have user-defined inheritance--except
arguably for subrange types. But there are languages whose types do
have some broader form of inheritance. Although I do think that
inheritance can be used to distinguish between classes and types, I
don't think it is a question of who has it and who doesn't, but rather
of the semantics of inheritance. More on this later.
So it is irrefutably obvious that a Smalltalk class is not equivalent,
or even highly analogous--let alone "identical"--to a Pascal "type."
May I remind you that "identical," "type in other languages," and
"a popular definition of type" are your terms. I think my
interpretation of them is entirely reasonable. If this is not your
intended interpretation, I don't apologize. Under the circumstances,
any misinterpretation of what you meant is entirely your own fault.
So what about an interpretation of "type" to mean an ADT?
There is only one important difference between a Pascal type and an
ADT:
An ADT separates the specification of the interface of a type
from the specification of the structure of values of the type,
and separates the definition of the function signatures
(headers) applicable to values of the type from the definition
of the algorithms of the functions. This is more than just the
division of modules into "*.h" and "*.c" files, because the
interface specification of the ADT only reveals the name of the
ADT and the signatures of its functions--it does not reveal the
"internal structure" of values of the ADT. So the internal
structure can be changed without requiring that clients of the
ADT be recompiled.
So an ADT does not suffer from one of the several ailments that prevent
a type from being a class. And it can be argued that it lessens the
impact of some of the others (a point I would not agree with, by the
way). But that's secondary. The key remaining deficiencies of an ADT
that prevent it from being a class are as follows:
1) An ADT--like any other type--is bound to an address (a variable or
a typed pointer). The type of the value of a ADT is not a function
of the bits of the value. This prevents it from being a class.
[What is called a class in C++ suffers from this same disease,
virtual functions notwithstanding. You'd think people could tell
the difference between an object and a discriminated union.
Sheesh].
2) An ADT constrains the values that can be stored at an address. One
can "type cast" a value from one ADT to another simply by disabling
or avoiding "type checking" during assignment or parameter passing.
Classes don't have this property. [Another reason that what's
called a class in C++--isn't].
3) An ADT is not itself an instance of an ADT. A class is an instance
of a class. Another important property where an ADT and a class
are decidedly different. [C++ fails again].
4) An ADT determines syntactically what operators/functions/procedures
are applicable to its instances. Again, classes don't do this.
[C++...oh, never mind--no use beating a dead horse]
So neither an ADT nor a C++ "class" qualifies as a true class. Perhaps
your thesis should have been "a C++ class is just a type." Now that
thesis I could agree with :-).
Perhaps you'd rather discuss whether a class denotes "a set of
values?"
--Alan Lovejoy (love...@ix.netcom.com)
Bytesmiths
lawyers who would be glad to file a libel suit over "If you dare to do so,
quote it, liar. You are lying shamelessly here." This is clearly
malicious, and I don't think many courts would believe that someone who is
putting together a national standard could be knowingly lying about it.
I believe this person is best dealt with by applying the root of one of
his favorite words: "ignore." Putting his quotes, no matter how
outlandish, in your .signature will only incite him. I have forgotten his
name, and we'd best all ignore him before his incessant typing puts some
poor publisher out of business.
According to Robert M. Bramson, Ph. D., "...the heart of Balloon
motivation seems to be the overwhelming desire to be admired and respected
by others," and they "...read newspapers, browse through the first four
chapters of many books... The problems start when they try to sell the
popcorn they make from all of these kernels of fact."
Dr. Bramson defines "Baloons" as "Those phony know-it-all experts" in the
book "Coping With Difficult People, Anchor Press, 1981, LCCN 80-2319, ISBN
0-385-17362-8. I heartily recommend this book. Often, just being seen
reaching for it on my shelf is enough to avert a brewing confrontation!
:-)
Please accept my humble apology for not writing about objects or Smalltalk
in this message.
Jan
Jan Steinman <jan.byt...@acm.org>
Barbara Yates <barbara.b...@acm.org>
2002 Parkside Ct., West Linn, OR 97068, USA +1 503 657 7703
Carl E Gundel
: pcg> But there are other differences between message sending in actor
: pcg> systems and procedure calls in Smalltalk-80 that are far more
: pcg> important
That's fine. But I like Smalltalk and don't have any objections to the
way it works. Please tell me if and why it matters that Smalltalk is not
a real actor system. Is this just an academic issue, or is there some
real benefit we are missing out on because we are using Smalltalk, and
not a real actor system instead.
Regards,
Carl
--
------------------------------------------------------------------
Carl Gundel ca...@world.std.com Shoptalk Systems 508-872-5315
author of Liberty BASIC, "EASY Windows and OS/2 programming!"
http://world.std.com/~carlg/basic.html
Piercarlo Grandi
>>> On 7 Dec 1995 06:09:22 GMT, love...@ix.netcom.com(Alan Lovejoy ) said:
Alan> Me? Confuse a sign with its referent? A symbol with its meaning? A
Alan> map with the territory it depicts? Perhaps I have not correctly
Alan> understood your previous posting, but at least I know the difference
Alan> between a type "in other languages", a class, an interface
Alan> specification, a semantic specification and a particular implementation
Alan> thereof. [ ... ]
Alan> 8) A class is an object--and therefore a computable value. It can
Alan> be stored in a variable, passed as an argument to a method, and
Alan> dynamically created by program logic. This is another fact
Alan> that disagrees with your thesis.
Which illustrates the real reason of why this thread has gone on too
long.
Piercarlo> Of course: you are so deeply ignorant as not to realize that
Piercarlo> there is a large difference between a type and its
Piercarlo> reification at runtime. The imbecilic notion that a class is
Piercarlo> an object should disqualify you from ever, ever talking about
Piercarlo> ``Smalltalk'' again. In Smalltalk-80 classes are not objects,
Piercarlo> they are _represented_ as objects, a distinction that is
Piercarlo> vital to understanding ``Smalltalk'' and type systems and
Piercarlo> classes.
Let me dwell a little more on this particular inanity of the many you
have written. Fist of all, my usual quote from "Smalltalk-80: The
Language" which is after all the title of the thread:
" Classes and Instances
...
Since classes are components of the Smalltalk-80 system, they are
represented as objects. A class's name automatically becomes the name
og a globally shared variable. The value of that variable is the
object representing the class.
...
This chapter introduces two ways to present a class, one describing
the functionality of the instances of a class and the other describin
the implementation of that functionality.
...
A third way to present classes is an interactive view called a
``system browser''." [chapter 3, pages 40-41]
Now this is is just entry level, _fundamental_ knowledge about
Smalltalk-80. The distinction between a class and the class object
representing it is essential to Smalltalk-80, and it is clearly
presented as such in the reference book (it is the first page of the
chapter that describes classes).
That the book goes on and often uses an abbreviated form like "the
class X" for the longer "the class object for class X" perhaps
explains why you cannot distinguish the two entities, but it does not
excuse it, because such shorthands are common in the literature, and
should fool nobody who has some knowledge and insight, instead of just
hackery. As an example, there is the definition in the flossary on
page 53:
"*class* an object that describes the implementation of a set of
similar objects"
which should read:
"*class* the description of the implementation of all objects of
the same type, which is represented as an object
itself."
The point is made even more clearly in Chapter 4, page 77:
"Since all Smalltalk-80 system components are represented by
objects, and all objects are instances of a class, the classes
themsleves must be represented by instances of a class."
and then continues by calling "class" the "class object", because the
point needs not further reminding.
It is not only ignorant of you to miss this important distinction, it is
stupid: because you had claimed that you know the importance of such
distinction, and even more amusingly, because it shows that not only you
have not read or cannot remember "Smalltalk-80: The Language" as it is
also painfully obvious by looking at many of your other inanities, but
that you are so arrogantly self assured that before writing something in
this thread, in which you and your pals have staked the validity of your
credentials on those of your arguments, you have not even bothered
checking the source to make sure. Your choice...
Piercarlo Grandi
>>> Buck) said:
Dave> In article <yf320qj...@sabi.demon.co.uk>,
Dave> Piercarlo Grandi <pier...@sabi.demon.co.uk> wrote:
pcg> But there are other differences between message sending in actor
pcg> systems and procedure calls in Smalltalk-80 that are far more
pcg> important
Dave> Ok, maybe you can help me distinguish the difference between your
Dave> definition of a procedure call
The definition of the popular textbooks, of Meyer, and of other authors
that I have quoted as well.
Dave> and a message send.
Ah, this differs from specific actor system to specific actor system. As
one example:
"Basic actors, as typified by the implementation in the language Act1,
for instance, have a very simple protocol that is executed on message
receipt: the receiving actor creates a new actor to handle the next
incoming call, performs the required computation, passes the result on
to another named actor, and dies. There is no updating of state in
pure actor systems. Instead a process or ``replacement'' is used,
where the replacement actor with the new state is put in place and the
old actor dies. This model provides a very powerful primitive for
distributed and concurrent applications." [OOPSLA, page 62].
Now this is true of *basic* actor systems. There have been actor system
hybrids that have had classes, or modifiable state, for example. The
logic however of message sending is largely the same as that in
distributed programming: a "packet" is copied (logically) to from the
sender to the receiver, and it is entirely up the the receiving actor to
interpret it and react, by sending a new "packet" either back to the
source, or to another actor. A rather similar technology is available in
Smalltalk-80 using processes and queues and in general the simulation
primitives.
Dave> In the following steps, I will slowly transform Smalltalk into an
Dave> actor system.
Not by the description above, though (for basic actor systems are purely
functional and continuation passing based, and in none of your step
either transformation id one): and not even by a less strict definition
Dave> I would be honored to have you call any intermediate stage you
Dave> wish "Dave's Own Smalltalk".
The first step is already you own variant of ``Smalltalk'' I would
surmise.
Dave> Step 1: I change all classes so that they all inherit from nil (i.e.,
Dave> have no superclass) but I give them all copies of the methods they had
Dave> before. [ ... ]
Dave> What I want to know is when did I change from procedure calls by
Dave> your definition to message sends.
Let's have a look
Dave> Step 2: I take every instance in the system and change its class to be
Dave> a copy of the class. [ ... ]
Dave> Step 3: I change the implementation of the Smalltalk virtual machine
Dave> so that "call" creates a message object containing the selector, the
Dave> arguments, and the return value. [ ... ]
Isn't this what is ``really'' happening already?
Dave> Step 4: I change the virtual machine so that every object
Dave> corresponds to a different thread. I add one more thread for the
Dave> message lookup system. Now, when a method tries to invoke another
Dave> method, the calling thread performs an asynchronous rendez-vous
Dave> with the virtual machine thread, the virtual machine thread
Dave> performs the method lookup, and then performs an asynchronous
Dave> rendez-vous with the receiver's thread. [ ... ]
Dave> Step 5: I change the virtual machine again so that the method
Dave> lookup happens to be done in the thread for the receiver rather
Dave> than the thread for the virtual machine. The thread for the
Dave> virtual machine can now be eliminated. Is it message passing now?
Not yet.
Dave> What's the difference between the final system and an actor
Dave> system?
For starters, it is not "continuation" passing and purely functional.
As to message sending, there is no queue of messages above (a minor
point), nor are messaging patterns allowed to be arbitrary, for they
must still be nested. You are still emulating procedure calls, using an
RPC like mechanism.
On the other hand you have replaced inheritance and classes with a
somewhat clumsy form of prototyping. Now, as a rule, actor systems do
have delegation and prototyping instead of classes and inheritance, but
this is a different issue from using message sending instead of
procedure calls.
Dave> Does this difference constitute the difference between message
Dave> passing and procedure calls?
Not yet. I would say it constitutes the difference between RPC and
procedure calls on one hand, and between having or not having classes
and inheritance.
Consider the original paragraphs in the Smalltalk-80 books: nowhere the
point is made that message passing _must_ be nested (no arbitrary
passing of information), and that there can be only one active message
(no queueing). These points become apparent only after a few pages. The
initial description is indeed that of Smalltalk-80 as a system based on
a swarm of autonomous, abitrarily message passing, objects, like actor
systems, except that there are classes instead of delegation and state
modification instead of replacement like in basic actor systems.
According to Ralph Johnson, and I agrew with him (having quoted
references to the effect that Kay and company were clearly influenced by
Hewitt's work -- after all actor systems are ideal for Kay's vision of a
world populated by Dynabooks interacting over the ether), this is
because the _goal_ was to design something more like an actor system
than what happened.
In effect the simulation classes and processes/queues allow one to
simulate, if one wants, fairly closely an actor system.
I ascribe the switch from the stronger actor orientation of Smalltalk-72
(which was not quite an actor system, mainly because the input stream
was not made of _messages_, in the sense of "packets"/actors themselves,
but of _tokens_, that is token parsing instead of message sending) to
the very conventional structure of Smalltalk-80 to two factors:
* that hardware was unequal to support a true actor system,
elegant as it was (this was what has relegated to relative
marginality actor research in general, even if genetic
algorithms and MPP MIMD machines might mean the future is
different).
* that there was fertile cross pollination between the InterLisp
group and the Smalltalk group (probably, but is just a guess
fom far away, the InterLisp group borrowed the attractive
visual interface concepts, and the Smalltalk group borrowed
large bits of the language and implementation technology),
resulting in Smalltalk-80 and InterLisp-D being essentially
two different looking versions of the same thing
(and here let me say that world history :-) would have been
different if CommonLisp had been a descendant of InterLisp
instead of, as it happened, largely of MAC Lisp and Lisps
related to it).
Two people that should know a bit better than me being nearer to the
action have broadly agreed with some of the points above in private
e-mail even if course the situation was rather more fluid... History
indeed is never so clear cut as one wishes. As to this, the ObQuote from
"The Language":
"Smalltalk is a vision
...
SCG's strategy for realizing this vision has been to concentrate on
two principal areas of research: a language of description (a
programming language) which serves as an interface between the models
in the human mind and thos in computing hardware, and a language of
interaction (a user interface) which matches the human communication
system to that of the computer. Smalltalk research has followed a
two-to-four year cycle: create a system embodying current
understanding of the software needs; implement applications that test
the system's ability to support these applications; and finally, base
don the resulting experience, reformulate the understanding of
software needs and redesign the programming language and/or the user
interface.
Smalltalk-80 marks the fifth time through this cycle. The research
is still in progress. We hope that presenting a detailed description
of the current research results will contribute to the community
working towards SCG's vision. The continued unfolding of the research
means that the software system described in this book is literally a
``moving target'' and the information in this book represents only one
station on a long track. Holding the train in the station long enough
to write about it made the task complex."
Unfortunately the two-to-four year cycle has been broken (commercial
startups don't necessarily have the same possibilities or goals as
research labs of immense corporations), and there have been no
Smalltalk-84, or Smalltalk-88, or Smalltalk-92 book series, only release
manuals for various products. Let's hope that the ANSI effort produces a
snapshot of Smalltalk-96 of as good a quality as the earlier
series. It's long overdue.
In the meantime a little archeology perhaps help clarifying whence it
came from and why...
Piercarlo Grandi
Alan> Me? Confuse a sign with its referent? A symbol with its meaning? A
Alan> map with the territory it depicts? Perhaps I have not correctly
Alan> understood your previous posting, but at least I know the difference
Alan> between a type "in other languages", a class, an interface
Alan> specification, a semantic specification and a particular implementation
Alan> thereof.
That's what you claim now, it's easy to claim this after I explained the
points above to you. Your previous words are quite clear that you did not.
pcg> B) you don't "remember" that type denotations, being in the domain of
pcg> mathematical entities, cannot by definition be expressed at the
pcg> language level, therefore by discussing "type" in the context of
pcg> ``Smalltalk'' (not the feline variety!) we could not possibly have
pcg> been using "type" as an abbreviation for "type denotation" (not for
pcg> "type interface"/"type spefication").
Alan> I have to admit that I misinterpreted what you said in the post to
Alan> which I responded.
It's very convenient to claim so, now. But as I have demonstrated you
had not misinterpreted at all, for it was very clear that the discussion
was about types in programming languages (I even _emphasized_ my
qualification) as described in some populare notion of type that I had
quoted, and that you understood it (comparing Smalltalk classes with
C++ types).
Alan> But my interpretation of the literature
Which literature? You haven't even bothered quoting it, nor producing
any references. If you have any sense you will be frantically reading up
now, but you will only find that you should have done before writing
inanities.
Alan> is the same (more or less) as that of the acknowledged experts in
Alan> OOP, some of whom you have been arguing with in this thread.
A self important clique, who loudly claim to be experts, and that
congratulate each other as experts; hey these sorts of cliques happen
all the time, the more so in smaller somewhat inbred subcultures.
The acknowledged experts in OOP and type systems are those that I have
quoted for hundred of lines (even if I dissent from them on several
points), and evidently reading what they have to say and the obvious
validity of most of their arguments has been of no benefit to you.
Alan> When a member of the ANSI Smalltalk standards committe tells you
Alan> you're completely mistaken on such a fundamental point, you should
Alan> at least find another equivalently-credentialed expert who agrees
Alan> with you.
I don't care: I check the validity of arguments, not the credentials of
their authors. I am in no position to offer you or any of your pals
employment, not that I would if I were (I think sensible employers check
ability ot perform more than credentials).
The subject of discussion is whether certain arguments are valid, and
this in no way depends on how self-important your credentials
are.
However, given that the person in question, and you, have linked the
validity of the arguments they make with their credentials, let me add:
your arguments have been _proven_ to be wrong, and perhaps one would
conclude that certain people should not sit on standards committees, for
they might bring them into disrepute.
Alan> Can you produce one?
For the benefit of those like you that still have a middle ages mindset,
where "Aristotle wrote that" was enough, I have produced hundreds of
lines of quotes from Goldberg&Robson, Cardelli&Wegner, Meyer, and the
OOSLA authors, all of whom have far more impressive credentials than
any member of your little clique.
Indeed so far (and perhaps my newsfeed is running late) I have been the
_only_ participant in this debate to actually have produced references
and quotes, for weeks and weeks, whereas you and the other pals have
only produced your own self important assurances that you cannot be
wrong, because of your credentials.
But even if I repost (and I will) the quotes I have copiously produced
in the past few weeks, there is the little problem that they will not
benefit you, because you write with typical arrogance:
Alan> Why would I want to read your past articles?
Before this sort of mindset one can only shrug.
Alan> At the very least, you should realize that in such a situation you
Alan> have no standing to be making the insulting comments and personal
Alan> attacks that you have been engaging in--even if you're right!
I have made no such personal attack: I have remarked several members of
your little clique been engaging in several examples of wilfully
malicious mispresentation of what I have written, i.e. lying
shamelessly. There have been whole articles written by them in which
they have caricatured what according to them are my arguments _without a
single line of quote of my words_, despite cut-and-paste being so easy,
and that's curious isn't it? :-). This is simply dishonest. This is not
a personal attack: it is a complaint. If they engage in dishonest
debating tricks, as I have dmeonstrated countless times by comparing
their malicious paraphrases with what I have actually written,
complaining about that surely is legitimate.
Also, please note that I have as a rule been careful to characterize
arguments as inane and ignorant: that somebody makes an ignorant and
inane argument does not imply that the author is ignorant or inane,
simply perhaps that it was a slipup, for whatever reasons (fatigue,
pique, who knows).
But, and this is your problem, you and your pals have made an issue of
your personal credentials in this discussion, not just of your arguments.
Given that _you_ have made this link, then it follows that according _to
you_ if your arguments are wrong, it's because you are incompetent and
your credentials undeserved.
To make a personal link between yourself and the validity of your
arguments is a double edged sword: your credentials may lend weight to
your arguments for those who cannot or don't want to check on their
validity themselves, but then if you are wrong, this backfires. Your
choice, and you have already made it.
pcg> I would suggest that it would also be polite of you to read other
pcg> people's past articles before repeating all over again the same
pcg> inanities.
Alan> Why would I want to read your past articles?
To avoid wasting my time by repeating they same inanities all over
again, as I have written. Discussions have a context, and it is a waste
of time to restart them at any arbitrary point just because you cannot
be bothered to follow them. I have quoted hundreds of line of
authorities with greater credentials than you (not that those matter to
me: as I have written, I think they are wrong on several points)
directly contradicting your inanities, and it's very convenient for you
not to have read them, but very tiring for me to have to repeat the same
quotes and argument with every member of your little clique.
Alan> I think we're ready now for that promised refutation of your
Alan> thesis that Smalltalk classes are equivalent to "types in other
Alan> languages." Note that I'm explicitly referring to **Smalltalk**
Alan> classes--not C++ classes, nor Eiffel classes, nor "class" as used
Alan> in any other language.
Alan> So what is "a popular definition of type" as it can be found in
Alan> "other languages?" Well, the most "popular" of the strongly
Alan> "typed" languages, especially in the domain of computer science
Alan> instruction at a university, has to be Pascal [Wirth].
This is your assumption -- you are building a straw man. You have
specifically mentioned C++, and I have specifically mentioned Eiffel, as
close examples. Besides, if you were not dishonest, you would quote me
without assembling bits and pieces, because the popular notion of type I
was referring to was that in entry level books, not in Pascal, and the
contention was that classes in ``Smalltalk'' and other languages are
essentially identical, not _literally_ identical as you make it appear
above.
Alan> So I will use the Pascal concept of type as my canonical example
Alan> of "type"--with some terminology help for those who are familiar
Alan> with "C" but not with Pascal. I think I have every justification
Alan> in the choice of Pascal,
No, you have not: because the definition of type i have produced is nbot
tied to any specific languge: I have used the definition in
Cardelli&Wegner, "On Understanding data types", which you would do well
do read, before embarassing yourself further with self-ridicule.
Alan> given the words you have used to specify what you mean by "type"
Alan> in the postings of yours I have read.
It shows that you are making it up here, and it is understandable, as
you have admitted later:
Alan> Why would I want to read your past articles?
Again, the answer is: to be able to quote me, or failing that, because
your editor does not evidently support cut and paste so easily, to make
reliable summaries of my positions. But that of course is not the point.
Alan> A "type" in Pascal has the following properties/functions:
Who cares? Read Cardelli&Wegner, and you will find a suitable
definition.
Alan> By contrast, a Smalltalk class has the following properties/functions:
You are comparing, dishonestly, the smallest detail of the definition of
the type and class liguistic constructs in two extremely different
languages.
Unfortunately, as you seem to be ignorant of, no two languages have
_exactly_ the same definition of type/class. Indeed, as you dishonestly
feign to not have realized, I wrote repeatedly, anticipating this sort
of dishonest objection, of the _essential notion_ of type, as described
for example in Cardelli&Wegner, not any particular realization.
If you had read a basic tract such as Cardelli&Wegner "On understanding
data types", of which I have provided in the past ample quotes as my
"popular definition of type" (which you haven't obviously read), you
would know what that notion is, and that Cardelli&Wegner clearly state
that notion is the same in Smalltalk-80 as in other languages.
Besides your characterization of ``Smalltalk'' classes contains quite a
few ridiculous mistakes, for example:
Alan> 8) A class is an object--and therefore a computable value. It can
Alan> be stored in a variable, passed as an argument to a method, and
Alan> dynamically created by program logic. This is another fact
Alan> that disagrees with your thesis.
Of course: you are so deeply ignorant as not to realize that there is a
large difference between a type and its reification at runtime. The
imbecilic notion that a class is an object should disqualify you from
ever, ever talking about ``Smalltalk'' again. In Smalltalk-80 classes
are not objects, they are _represented_ as objects, a distinction that
is vital to understanding ``Smalltalk'' and type systems and classes.
But making this confusion is consistent with past displays of your
inability to grasp these obcvious points, and belies your
Alan> Me? Confuse a sign with its referent? A symbol with its meaning?
Alan> A map with the territory it depicts?
If you could remember the Smalltalk-80 books, they make it clear that a
Smalltalk-80 class can be _represented_ in at least two different ways
(reified at runtime as an object, and as a class description in printed
or displayed form). Neither _is_ the class, and it is not a surprise you
cannot make the distinction. Impressive credentials indeed!
I will add that indeed _all_ languages reifiy classes or types in some
representation or another. Some like EL1 (a non OO language) and
Smalltalk-80 (an OO one) reify types at runtime as well as
compiletime, some only represent them at compiletime. So what? Does
this detail change anything essential? Perhaps -- but to argue so you
would have to understand the distinction above, which unfortunately
you don't.
And also, just to pick at random another howler:
Alan> 5) A class cannot be used to constrain the objects that can be stored
Alan> in an instance variable, because the language provides no
Alan> syntax for constraining the class of an object to be assigned
Alan> to an instance variable. Nor does assigning an object to a
Alan> variable ever change the class of the object. This is
Alan> another key distinction between classes and types--and it's
Alan> another nail in the coffin of your thesis.
It's just proof that you don't understand types and classes at all, and
not just ``Smalltalk''... Because manifest typing is a language feature
completely independent of what a type ``is'' or is not. There are typed
languages that are manifestly typed (e.g. C++) and those that are
latently typed (e.g. Lisp and most ``Smalltalk''s), and there are even
those that are latently but _statically_ typed (e.g. ML, that does not
require type annotations because it can statically infer them).
It's also another proof that your arguments are dishonest -- because the
issue, as it is clear to everybody, was never whether ``Smalltalk'' is a
manifestly typed language, but whether its object types are equivalent
to those of other languages. It is also an argument over which we have
gone several weeks ago. But of course, why bother reading the context to
avoid repeating inanities?
I must admit that the inanities you write above (confusing a class with
one of its representations, confusing manifest typing with typing) are
popular enough, but the popularity of an inanity does not make right.
Alan> Why would I want to read your past articles?
Just to avoid ridiculing yourself by showing that not only you have not
read the commonly read papers I have quoted, but you could not even
bother reading them on news when I have quoted so many hundred lines
from them. Of course my quotes are no real substitute for the full
papers and books, which you could usefully get acquainted with before
writing further inanities, but at least they should give you an idea of
the contents thereof.
Alan> [ ... ] So it is irrefutably obvious that a Smalltalk class is not
Alan> equivalent, or even highly analogous--let alone "identical"--to a
Alan> Pascal "type."
Perhaps then you should write to Cardelli or Wegner or Meyer and tell
them that they are writing nonsense in their papers and books... But
given that you feel credentials are so important, perhaps you should
not.
Alan> May I remind you that "identical," "type in other languages," and
Perhaps you have forgotten "cut&paste"? Please quote me as writing them
in the logical succession you maliciously attribute to me.
I was carefully to qualify my statements because of course I anticipated
that some innocent reader might then think that classes in Smalltalk-80
and types in ML or C++ or Eiffel are not defined in a _literally_
identical way, even if they are essentially (their essence, not their
details) identical. Hey, was I wrong?
Alan> "a popular definition of type" are your terms. I think my
Alan> interpretation of them is entirely reasonable. If this is not
Alan> your intended interpretation, I don't apologize. Under the
Alan> circumstances, any misinterpretation of what you meant is entirely
Alan> your own fault.
No, because both you and I have made it very clear, by mentionining them
by name, what is the correct interpretation, that you have wilfully
disregarded to set up a strawman. For "popular notion of type" I quoted
Cardelli&Wegner; for other popular language you mentioned C++ and I
mentioned Eiffel (and Cardelli&Wegner's discussion again).
Alan> So what about an interpretation of "type" to mean an ADT?
Alan> There is only one important difference between a Pascal type and an
Alan> ADT: [ ... ]
Please read carefully Cardelli&Wegner's quotes that I have posted, and
come back then.
Alan> So neither an ADT nor a C++ "class" qualifies as a true class.
A-mazing! For ADTs are not classes, and then Stroustrup will have a fit
when he will read this and be enlightened by you that when he designed
"C with classes" (the original name of C++) he was having hallucinations.
Doesn't he have more impressive credentials than yours? Why do do you
dare to question his judgement? :-)
Alan> Perhaps your thesis should have been "a C++ class is just a type."
Alan> Now that thesis I could agree with :-).
That's also true. :-)
Alan Lovejoy
This is continuation of post that had to be split into two parts due
to the limitations of my Windows-based internet access program.
It is a discussion between myself and Piercarlo Grandi on the
subject of whether or not a "type" is a "class."
Piercarlo Grandi writes:
>Another note that I must make so far for types as in programming
>languages. The authors then introduce a model type system based
>on lambda calculus. Now on types in mathematical type theory, and
Hmm.. For once, I could not correct the typo [thank you, thank you],
so I'm not completely sure what I'm missing in the above sentence.
I think a word was left out, but I have no idea what it may have been.
>Alan will see that this is a completely different sort of thing, and
he
>should not confuse the two notions, even if the word "type" is used in
>this article, confusingly, to label _both_ things, even if it is clear
by
>context which is which:
>
> ... "What is an adequate notion of ``type'' that can account for
> polymorphism, abstraction, and parameterization? In the previous
> sections we started to describe a particular type system by giving
> informal typing rules for the linguistic constructs that we
> use. These rules are enough to characterize the type system at an
> intuitive level and can be easily formalized as a type inference
> system. The rules are sound and can stand on their own, but they
> have been discovered and justified by studying a particular
> semantics of types,developed in " ... "
> Although we do not need to discuss the semantic theory of types
> in detail, it may be useful to explain the basic intuitions behind
it.
> The intuitions can, in turn, be useful in understanding the typing
> rules, particularly with regard to the concept of subtypes, which is
> introduced later.
> There is a universe $V$ of all values, containing simple values
like
> integers, data structures like pairs, records and variants, and
> functions. This is a complete partial order, built by using Scott's
> techniques[Scott 1976], but in first approximation we can think of
it
> just as a large set of all possible values.
> A type is a set of elements of $V$. Not all subsets of $V$ are
legal
> types: They must obey some technical properties.
> The subsets of $V$ obeying such properties are called ``ideals''.
> All the types found in programming languages are ideals in this
> sense, so we do not have to worry too much about subsets of $V$
> that are not ideals.
> Hence a type is an ideal, which is a set of values. Moreover the
> set of all types (ideals) over $V$, when ordered by set inclusion,
> forms a lattice. The top of this lattice is the type $Top$ (the set
of all
> values, i.e. $V$ itself). The bottom of the lattice is, essentially,
> the empty set (actually it is the singleton set containing the least
> element of $V$).
> The phrase ``having a type'' is interpreted as _membership_ in the
> appropriate set. Because ideals over $V$ may overlap, a value can
> have many types.
> A particular type system is then a collection of ideals of $V$,
> which is usually identified by giving a language of type expressions
> and a mapping from type expressions to ideals. The ideals in this
> collection are elevated to the rank of ``types'' for a particular
> language."
The issue you should consider is this: what is the identity function
that either equates or distinguishes the members of $V$?
Different identity functions give different results.
We can "identify" two members as "the same" by function,
by content, by form, by structure, by name, etc.
A class is an ur-type, as I have agreed.
> "In Smalltalk, a subclass does not necessarily conform to its
> superclass; for example, it may override some of the operations of
> the superclass so that they expect different classes of
> arguments. Moreover, one class may conform to another without a
> subclass relationship existing between them. What a subclass and
> its superclass *do* have in common is part of their representation
> and some of their methods. In short, inheritance is a relationship
> between implementations, while conformance is a relationship
> between interfaces".
Good. Just what "the clique" has been saying.
>On page 95-96 of the same book there is a section on "Subtyping in
>abstract data types", in which one can find the bizarre statement
that:
>
> "Note that rules for type checking are normally based on the syntax
> of the specification alone. For example, two types which provide the
> same operations must be considered to be the same type
> irrespective of the semantics of the operation, Similarly rules for
> subtyping must be based solely on the interfaces provided. This is a
> major weakness of any abastract data type based languages and
> is an area for future research."
>
>It's languages of this sort that perhaps confuses the unwary/unweary.
>
>Still, OOLSA is also a book that should be read...
Seems the author is talking about implementation of conformance
checking, not abstract concept, when he says "two types which
provide the same operations must be considered to be the same type
irrespective of the semantics of the operation."
But it shows that the author means what the OOP community
calls "protocol" when he says "interface." The "protocol" of
an object is the messages it responds to--regardless of semantics.
The "type" (in our jargon) is the "protocol" including the semantics.
That's what's important when coding in an OOPL.
The Esquimau have all those words for snow because that's what
matters to them in the context of their lives. And the terminology
of the OOP community reflects what we have found to be significant.
>Finally, a source better than most, "Object Oriented Software
>Construction", by B. Meyer. I mostly agree with it, even if it is like
>many others lacking here and there in proper termnology, and
>reports some common misconceptions, and some self-serving
>arguments. Still, much better than most...
>
>On page 59, there is "A PRECISE DEFINITION":
>
> "Definition 2: Object-oriented design is the construction of
> software systems as structured collections of abstract data type
> implementations.
Thinking of classes as abstract data types is usually an acceptable
approximation when designing. Newtonian mechanics is usually
good enough for government work, too.
> In an object-oriented architecture, every module will be built on
a
> data abstraction, that is to say on a set of data structures
> described by the services that are part of its official interface,
> and the properties of those services."
> ... "As announced earlier, the modules of object-oriented systems
> are called *classes*. According to the above definition, a class
is
> an abstract data type implementation, _not_ the abastract data
> type itself.
That last sentence is **very** similar to a statement I made in my
original post: "a class is an implementation of a type--it is not
itself a type." I think Meyer and I mean the same thing.
> This is inevitable for a method targeted to actual design
> and implementation rather than just specification. For example,
the
> side effect free functions of the specification ('push' and the
> like) may be represented in the class, for efficiency reasons, by
> procedures working by side effect.
>
> [We shall see however, that object-oriented techniques allow for
> classes that cover more than one implementation of an abastract
> data type. Such classes are called *deferred classes* and will
> be introduced in chapter 10. The Eiffel language used in the
> following chapters grants designers flexibility to the level of
> abastraction of the classes they write. It is possible to write
> classes general enough to be very close indeed to a bona fide
> abastract data type specification.]"
Hooray for Eiffel? That's obviously Meyer's point. What was
yours?
>The "SEVEN STEPS TOWARDS OBJECT-ORIENTED HAPPINESS" >on pages 60-62
repeat the same concepts (ADTs are mathematical
>entities, they can be _described_ via specifications in some
>mathematical notation, and _implemented_ in programming
>languages as classes), and among the points made:
>
> "The next step is the one which, in our opinion, truly
distinguishes
> object-based languages from the rest of the world." ... "true
> object-oriented programming all but identifies the notion of module
> with the notion of *type*. One may say that the defining equation of
> such languages is the identity
>
> module = type
> "
Why wouldn't this hold for any well-designed ADT-based language?
In any case, Meyer has already said that classes aren't types,
but simply implement them. So his implied analogy between
classes and types is just that: an analogy, not an identity.
> ... " Level4 (Classes): Every non-simple type is a
module, and
> every high-level module is a type.
>
> The qualifier ``non-simple'' makes it possible to keep predefined
> types (such as 'INTEGER' etc.) which are not viewed as modules;
Why not?
> the word ``high-level'' permits program structuring units such as
> procedures which are not types.
An aside: "Polymorphic Programming Languages" [Harland] develops
a type-theory where types are modeled as higher-order functions.
The book motivates and defines polymorphism using denotational
semantics, and defines a programming language "Poly" based on the
concepts discussed. Recommended.
> A language construct combining the module and types aspects is
> called a *class*.
> "
At best, this applies to Eiffel and other statically-typed languages.
>The summary "KEYCONCEPTS INTRODUCED IN THIS CHAPTER"
>on page 63 contains:
>
> "* To satisfy the requirements of extendibility and reusability, the
> data descriptions on which object-oriented software structures are
> built should be sufficiently abstract. The answer is provided by the
> theory of abastract data types, reconciling completeness of
> specifications with the need not to overspecify.
>
> * Abstract data types may be generic and are defined by functions,
> preconditions and axioms. The preconditions and axioms express
> the semantics of a type and are essential to a full, unambiguous
> description.
>
> * An abstract data type specification is a formal, mathematical
> description. It is side effect free.
>
> * Object-oriented systems are built as collections of classes. Every
> class represents a particular abastract data type implementation,
> or a group of implementations." ...
Curious thing to say: "or a group of implementations." Does he
mean the subclasses? But he did say "implementation." Again.
>Just for completeness, I shall mention that on pages 437-439 there is
>a discussion of ``Smalltalk'', in which there is the obviously
kisleading
>with the obviously clear:
>
> ... "As a language, Smalltalk combines the influence of Simula with
> the free, typeless style of Lisp. The emphasis is on dynamic
By "typeless" he obviously means "monotyped variables" with
values whose type is a function of their state.
> binding. No type checking is performed: in contrast with the
by which he obviously means "no static type checking is performed
because all variables have the same value-oriented type"
> approach emphasized in this book, the determination of whether a
> routine may be applied to an object occurs only at run-time."
Except of course that it is syntactically impossible to specify
exactly which "routine" (method) is to be executed. One can
only specify the abstract operation one wants to apply. The
object decides which method to invoke at run time based on
its internal state--which in Smalltalk includes its class. This is
significant especially because the syntax only allows sending
a message to a variable or an expression result--you don't get to
identify the recipient object itself directly, so there is no way
in general to have a-priori knowledge of the class of the object
to which one is sending a message.
>Note that of course taken literally this is nonsensical and
contradicts
>the paragrapha above: here "typeless" is really "dynamically typed".
Well, I know what you mean by "dynamically typed." And given
what you intend to convey by that phrase, I don't disagree. But
think a minute about that phrase. An object cannot change its
class (although it can change it's type, as I have shown). [Yes,
I know about the VisualWorks primitive #changeClassToThatOf:.
That primitive is not mentioned in Blue Book Smalltalk, so I am
free to ignore it :-)]. So if classes are types, it cannot literally
be true that objects are "dynamically typed." What this phrase
refers to is not the objects, but the variables. Of course, the
variables are all statically typed with the same value-oriented
type, so the "type" that is changing dynamically is the one
indirectly extended to the variable by the object it points to.
Like so:
type
OOP = ^Object;
function selectAnObject(): OOP;
begin ... end;
var
anObject: OOP;
begin
while (PGSeeksEnlightenment) do
anObject := selectAnObject;
sendMessage(anObject, 'congratulations');
end;
The static type of the value returned by the function "selectAnObject"
and assigned to the variable "anObject" is always "pointer to Object."
But the type extended to it by the object that is returned by the
function on each invocation may be different. Hence the term
"dynamic typing."
> "This, by the way, is not the standard Smalltalk terminology. A
> routine is called a ``method'' in Smalltalk; applying a routine to
an
> object is called ``sending a message'' to the object (whose class
must
> find the appropriate method to handle the message)."
He's probably just forgetting the differences between Eiffel and
Smalltalk. So what? He's not the only one to make this mistake,
and if it can happen to him, it can happen to anyone.
>Another plug: OOSC is one of the must-haves, despite some
>criticism I could make.
>
>This ends this long work. I hope it will be of benefit, and will
counter
>the spread of authoritative inanities that I have been so unhappy
with.
Well, perhaps due to the responses it generates...
--Alan Lovejoy (love...@ix.netcom.com)
P.S. Jan: is this keeping you sufficiently entertained?
William D. Gooch
I really hesitate to jump into this thread, but there are a couple
of things here I'd like to respond to. I'll keep it short.
> The fact that message sending in Smalltalk is not just a
>procedure call is the key fact that is being missed here. It is not a
>procedure call, not because it has asynchronous semantics as in an actor
>language, which it doesn't, but because it moves all knowledge of the
>called object's structure to the called objects side of the interface,
>thus eliminating the need for a caller to be concerned with it....
Well, it *could*, but in reality there is no such constraint. Sure,
we do (and to some extent the language does) encourage a
style in which what you say is true, but it isn't inherent in the
way Smalltalk (any Smalltalk) works. Yes, there's no *need*
for the sender to be concerned about the receiver's internals
*if the design properly accomodates this style* -- but the same
is true of a non-object-oriented program which observes the
same sort of constraints and boundaries. Certainly the same
can also be said of a program in CLOS which uses functions
to do things in good object-oriented style.
>.... We are talking about the base philosophy of
>Smalltalk here. As I said above the difference between Smalltalk message
>sending and procedure calls is essential for understanding Smalltalk
>semantics....
In what way? I hear claims of this sort thrown around a lot,
but have yet to see or hear any substantial support for them.
I think the fact that many people have successfully implemented
high quality, large scale object-oriented software systems in
non-messaging OO languages is quite an adequate refutation.
Alan Lovejoy
(Piercarlo Grandi) writes:
>
>>>> On 2 Dec 1995 10:33:28 GMT, love...@ix.netcom.com (Alan Lovejoy )
said:
>
>AL> (Piercarlo Grandi) writes:
>
>PG> I have written something about *Smalltalk-80*, as I have made
>PG> clear many times, not ``Smalltalk'', and I have _proved_ that
>PG> classes are what computer science textbooks call types in
>PG> other language, and this is so by design, by quoting
> ^^^^^^^^
>PG> literally the book that describes Smalltalk-80, and also some
>PG> popular definition of type, and anybody can then see that
>PG> they are equivalent.
>
>AL> possible to define two classes with different implementations, and
>AL> different inheritance hierarchies, which respond to exactly the
>AL> same messages with exactly the same semantics, preconditions and
>AL> postconditions. Instances of two such classes have the same
>AL> "type" because they respond to the same messages in the same way,
>AL> but their classes are different. This proves that a class is an
>AL> implementation of a type--it is not itself a type.
>
>AL> The ability to have multiple, diffrerent implementations of the
>AL> same "type" is one of the main motivations for OOP.
>
>It is the main motivation for having modules and types at all. OO
>languages are only a small subset of those that allow to have multiple
>types to have the same denotation. Hey, even Pascal does:
>
> type complex1 = record re, im : float end;
> complex2 = record imag, real: float end;
> stack1 = record n : 0..10; s : array[0..10] of 0..1000; end;
> stack2 = record s : 0..1000; f : ^stack2 end;
But multiple value-oriented types with the same denotation (algebra)
have different practical consquences than multiple Smalltalk classes
with the same interfaces.
Consider the following Pascal type declarations:
type
ColorValue1 = record r, g, b: integer end;
ColorValue2 = record red, green, blue: integer end;
ColorValue3 = record green, blue, red: integer end;
ColorValue4 = record hue, saturation, value: real end;
By the definition of Pascal, all four types are distinct. They
are not compatible. The functions/procedures defined on the domain
of each type are disjoint sets. It is illegal to assign values of one
type to variables bound to another type (in the four cases
above).
Even if we consider some variation of Pascal, call it Pascal-minus,
where type compatibility is either not enforced or else is determined
by structural equivalence, the only change is that the two Pascal types
ColorValue1 and ColorValue2 degenerate into the same Pascal-minus
type. Except that changing the structure of ColorValue1 without making
the analogous change to ColorValue2 destroys the type equivalence.
If we instead consider a variation of Pascal, call it Pascal++, where
function/procedure name overloading is supported, and use this new
feature to define an equivalent set of functions/procedures for
each of the four types such that each equivalent function in the
domain of each type has the same name, then we manage to get
four different types with the same interface. But this doesn't have
any practical consequences on the semantics of the program.
The only practical consequence to us as programmers is that we
can use a text editor to globally search and replace all references
to any one of the four types with any of the other three (other than
in the declarations of the types themselves) without changing the
correctness or function of the program. We could say that this
demonstrates "static" or "lexical" polymorphism. But we still have
four different types, a fact the compiler will gleefully inform you
about if you try to ignore it--or that will cause a program error if
you disable or avoid type checking.
Contrast this with four Smalltalk classes whose instance variable
structures are anologous to the aforementioned Pascal record types.
Assuming all four implement the same protocol with the same
semantics (have the same interface), then we can do something
that none of the three type-based variations of Pascal can match:
we can substitue any instance of any of the four classes with a
logically-equivalent instance of any of the other three classes
without affecting the function of the program--and we can do this
while the program is running. This demonstrates dynamic
polymorhpism and the difference between classes and value-oriented
types.
Note that we did the "same" things with Pascal types (and variations
thereof) and with Smalltalk classes, but we didn't get the same
results--and the difference has important practical consequences.
If classes are identical to value-oriented types, how could this be?
If two objects, whose classes differ, represent the same logical
value, then they cannot both be in the same set of logical values.
And so their logical, type-theoretic type is the same. OOP langauges
can take advantage of this "type equivalence" during program execution.
Statically-typed value-oriented languages cannot.
A difference (for instance, the class of an object) that makes no
difference, is no difference (for instance, of type). If different
Smalltalk classes whose interfaces are indentical denote different
"types," what practical consequence does it have? What
**difference** does it make? What is the utility of this distinction?
I already know your answer: the words "type" and "class" are
considered by you to be synonyms, so distinguishing the "type" of
objects whose classes differ is exactly as relevant as distinguishing
their classes. But then this discussion is reduced to a mere quibble
over terminology.
But I think there is more to it than this. The problem is that the
term "type" as used in Pascal, as used in the OOP community and as
used by other domains (such as mathematical type theory) does in
fact denote different things, and you aren't doing as good a job
being consistent in your usage as you'd like to think. And some of
the quotations you make below suffer from this same problem--or date
from a time when modern usages were not yet established.
There is admittedly an analogy between the "type" concept of
value-oriented languages and the concept called "class" in Smalltalk.
Rick DeNatale has admitted this. Jan Steinmann has admitted this.
I am admitting it now: it is possible--even useful--to abstract
a higher level concept from the analogies between the value-oriented
concept of "type" and the concept "class." But don't switch the
meanings of the term "type" without warning among "type as it exists
in value-oriented languages," "class," "the abstract ur-type
(to coin a term) that denotes what is common between classes and
types in value-oriented languages" and "type denotation/algebra
as defined in type theory."
So let me state my position very explicitly: A Smalltalk class is not
identical to what is called a type in value-oriented languages such
as Pascal, nor is it identical to what the OOP community calls
a type (which is synonomous with interface), but there is a higher
level abstraction that captures a symmetry between value-oriented
types and Smalltalk classes. I will refer henceforth to this concept
abstracted from "value-oriented type" and "class" by the term
"ur-type."
And the usage of the term "type" to mean "interface" has less
dissonance with the meaning of the term "type" in type theory than
does the usage you advocate. This is why the usage has become
popular.
>What you probably wanted to say is that one of the main motivationsfor
>OO is the ability to _hide_ the details of the multiple types so that
>they can share interface and not just denotations, as you seem to
>clumsily hint:
My example above shows that even in Pascal++, where types without
encapsulation can share identical interfaces, the benefits of
dynamic polymorphism cannot be demonstrated. Even adding
encapsulation/information hiding to the types of Pascal++ wouldn't
do this. As long as an ur-type is a static property of an address
(variable, typed pointer), instead of an organic property of a value,
there cannot be dynamic polymorphism, and the type cannot be
considered identical to a (Smalltalk) class. QED.
And once values are bound to ur-types, there is no need for
addresses to be bound to different value-oriented types. Binding all
addresses to the same value-oriented type is the means by which
dynamic polymorphism is made manifest. Unless values are bound to
ur-types as an organic property of their bits, dynamic polymorphism
cannot be implemented. QED.
An address whose value-oriented type denotes an Object is called
an object-oriented pointer, or "OOP." So Smalltalk does have exactly
one value-oriented type to which all Smalltalk variables are statically
bound. It is this type that is referred to in the famous statement
"everything is an object." The statement is NOT referring to the
class Object. The "OOP" value-oriented type is what unifies Smalltalk
and the prototype-based languages such as Self [Ungar]. Obviously,
the class Object cannot be the point of unification between Self
and Smalltalk! QED.
>AL> The distinction between type and class is necessary for
>AL> polymorphism and the separation of interface from mechanism.
>
>Not at all -- unless you choose, rather bizarrely to equate "type"
with
>"interface" itself.
It is standard practice in the OOP community to equate "type" with
"interface itself." You yourself imply that you are well aware
of the common usages of terms such as "type" in the OOP community,
including the newsgroups comp.object and comp.lang.smalltalk (the
immediate context) and in the OOP-related computer science
literature. Admittedly, you characterize these usages as wrong and
mistaken, but you are clearly aware of them, and should know that
they are not just isolated behavior of a few random individuals but
instead the normative behavior of the majority. So you have no excuse
for acting as though each such usage was the aberrant and/or
ignorant behavior of another misguided wrong way driver. When 1000
cars are coming toward you on your side of the freeway, and you're
the only one going the other way, you'd be crazy to keep going just
because you think the signs are in your favor. Crash!
Much better is to get off the road and turn around. And then perhaps
you can convince everyone else to drive the other way--but don't
drive against the rest of the traffic, no matter what the signs seem to
say!
When you come to the United States, which side of the road do you
drive on?
Are we really just arguing terminology, and not principle or concept?
If that is your game, you can have much more fun posting an article
to sci.linguistics asserting that the purpose of linguistic science
is to prescribe instead of describe the usage of language. Be sure
to give a good blow-by-blow account of the success of your
experimental attempt to prescribe to this community how it should use
the terms "type" and "class." The entertainment value should be
immense :-).
>In order to separate interface from body from specification (there are
>_three_ aspects to a type definition in a programming language) one
>just needs suitably flexible linguistic constructs. These are
>available equally for OO languages in which types are called classes
>and non OO languages in which they are called types.
Well, it's certainly true that statically-typed non-OOP languages exist
that have encapsulation/information hiding, generics, types as first
class values, strong typing and type inheritance. But none of those
things, separately or in combination, produces the effect of dynamic
polymorphism nor any of its benefits. The only way such languages
can emulate all the capabilities of Smaltalk classes in all cases where
different value-oriented, statically-bound-to-an-address-types have
identical interfaces is by editing/recompling source code. This is the
point I wanted to make, which I admit was not unambiguously expressed.
>AL> Because this is not possible in traditional "value-oriented"
>AL> languages,
>
>Go tell that to the Modula-3 folks... Or those poor ML guys.
There are two different ways that classes separate interface
from mechansim. One way is by information hiding, which
ADTs and classes both provide, and Modula-3 and ML both
support. And the other way--the one I was referring to--is by
dynamic polymorphism. ML and Modula-3 don't have that.
>Given that the above inanities are presumably based on an ill-digested
>notion of type, and the constant confusion between a type in a
>programming language, which is defined as an interface, a body, and a
>specification, and its denotation, which is usually defined as an
>algebra, let's go back to rereading some industry standard material as
>I had anticipated in another article.
>
>I have decided to post it now, without waiting for AL's mention of his
>source, because it's a lot of typing, and I think I won't have much
>time in the coming week...
Since you seem to already know my source, and prefer to be
convinced by the merits of an argument rather than by credentials,
I'll desist from typing in someone else's words and use my own.
>The first long bit is from "On Understanding Types, Data Abstraction,
>and Polymorphism", which appears in the Decembver 1985 issue of ACM
>Computing Surveys, which I can quote extensively thanks to the liberal
>copyright permissions by ACM.
>
>I have often expressed reservations about this paper, in particular
>but not only in its treatment of polymorphism, but for the purposes of
>this discussion, the passages I am quoting here are agreeable:
>
> ... "A type may be viewed as a set of clothes (or a suit of armour)
> that protects an underlying untyped representation from arbitrary or
> unintended use. It provides a protective covering that hides the
> underlying representation and constrains the [way] objects may
> interact with other objects. In an untyped system untyped objects
> are ``naked'' in that the undrlying representation is exposed for
> all to see. Violating the type system involves removing the
> protective set of clothing and operating directly on the naked
> representation."
Psychobabble. Everything has a type, even if it's just "Bits[32]"
or "BYTE[4]." What the author means by "an untyped system"
is really just "a system of only one or a few primitive types,
where higher level type abstractions are implemented algorithmically
in terms of the fixed set of primitive types without any way to
syntactically guarantee the invariants of the higher level
abstractions."
And of course, by "type" I understand the author to mean what I have
defined above as "ur-type." Interpreting "type" as ur-type is
often necessary in the remaining quotes as well...
> ... "To prevent type violations, we generally impose a static type
> structure on programs. Types are associated with constants,
operators,
> variables, and function symbols. A ``type inference'' system can be
> used to infer the types of expressions when little or no type
> information is given explicitly. In languages like Pascal and Ada,
the
> type of variables and function symbols is defined by redundant
> declarations, and rhe compiler can check the consistency of
definition
> and use. In languages like ML, explicit declarations are avoided
> wherever possible, and the system may infer the type of expressions
> from local context, while still enabling consistent usage.
But in ML, the type is "inferred" by lexical analysis of the source,
not fixed as an organic property of a value.
> Programming languages in which the type of every expression can
> be determined by static program analysis are said to be ``statically
> typed''. Static typing is a useful property, but the requirement
that
> all variables and expressions are bound to a type at compile time is
> sometimes too restrictive. It may be replaced by the weaker
> requirement that all expressions are required to be type consistent
> althought the type itself may be statically unknown; this can be
> generally done by introducing some run-time type checking.
> Languages in which all expressions are type consistent are called
> strongly typed languages. If a language is strongly typed, its
> compiler can guarantee that the programs it accepts will execute
> without type errors. In general, we should strive for strong typing
> and adopt static typing whenever possible. note that every
statically
> typed language is strongly typed, but the converse is not
> necessarily true."
No complaints worth mentioning.
> ... "Simula is the first ``object-oriented'' language. Its notion of
> type includes classes whose instances may be assigned as values
> of class-valued variables and may persist between the execution of
> procedures they contain. Procedures and data declarations of a
> class constitute its interface and are accessible to its users." ...
> "Subsequent object oriented languages like Smalltalk and Loops
> combine the class concept derived from Simula with a stronger
> notion of information hiding."
And Smalltalk and Loops also have dynamic polymorphism and lack
static typing.
> ... "The differences in behaviour between packages and records in
> Ada are avoided in object-oriented languages by extending the
> notion of type to procedures and data abastractions. In the context
> of this discussion it is useful to define object-oriented languages
as
> extensions of procedure-oriented languages that support typed data
> abstractions with inheritance. Thus we say that a language is object
> oriented if and only if it satifies the following requirements:
>
> * It supports objects that are data abastractions with an interface
of
> named operations and a hidden local state.
An ADT. No problem.
> * Objects have an associated object type.
Note the very precise usage of terminology. He said "Objects,"
not "Variables."
> * Types may inherit attributes from supertypes.
>
> These requirements may be summarized as
>
> object oriented = data abastraction + object types + type
inheritance"
For one thing, the author is writing this in 1985. For another,
he's defining object and class, so of course he would not create
a circular definition by defining a "class" as a "class." So as long
as we understand "type" as "ur-type," "object type" as "class," and
remember that objects are VALUES that encapsulate BOTH behavior
and state without requiring that this be the result of the object
having a class (so that Self is not excluded, among other things),
then the above quote is agreeable.
An object has a type, whether or not it has a class. This is
another reason to be suspicious of an identity between classes
and types. Everthing has a type. Some objects have classes,
some don't. Objects with the same class can have different
types--because their type can be a function of their state.
I'm not just talking about delegation here, although that's an
important consideration. Much more profound is the realization
that an object's behavior is a function of its state. In fact, an
object's class is part of its state. Does it matter whether a change
in an object's behavior is due to a change of its class or the value
of some (other!) instance variable? How can you tell which it
was, and how does it matter to the semantics of a program?
An object **encapsulates** its behavior. It's a black box. Where
it's behavior comes from internally is irrelevant.
>Note: I have spared myself to annotate all this, except that here I
>cannot resist and I must say that I disagree at least in part.
>
> ... "The requirement that all objects have a type allows objects to
be
> first-class values so that they can be managed as data structures
> within the language as well as used for computation.
What does it mean to "require that all objects have a type"? How
could an object not have a type? Even if by "type" the author
means class, the predicate of the statement does not logically
follow. And not all objects have a class, so that can't be a
requirement.
As I have already shown above, it's the fact that all variables in
an OOPL have the same static value-oriented type that allows all
objects to be first-class values and handled polymorphically.
> The requirement of type inheritance allows relations among types
> to be specified.Inheritance may be viewed as a type composition
> mechanism that allows the properties of one or more types to be
> reused in the definition of a new type. The specification ``B
inherits
> A'' may be be viewed as an abbreviation mechanism that avoids
> redefining the attributes of type A in the definition of type B.
> Inheritance, however is more than a shorthand, since it imposes
> structure upon a collection of related types that can greatly reduce
> the complexity of a system specification. This is illustrated by the
> Smalltalk object hierarchy in Goldberg and Robson[1983]."
> ... " The Smalltalk object hierarchy is also significant as an
> illustration of the power of polymorphism."
As long as "type" denotes "ur-type," I won't quibble...
> ... "The Smalltalk object hierarchy realizes polymorphism in the
> above sense by factoring out attributes common to a collection of
> subtypes into a supertype." ... "Thus polymorphism is intimately
> related to the notion of inheritance, and we can say that the
> expressive power of object-oriented systems is due in large
> measure to the polymorphism they facilitate."
So if we modify Smalltalk into Smalltalk-Prime by adding the
capability to have multiple root classes, then by the above reasoning
the resulting language would no longer be fully polymorphic, since
not all classes would inherit from a common root class. The observable
consequences predicted by this theory would be: we wouldn't be able to
assign any object to any variable without restriction, pass any object
as an argument to any method without restriction, or send any arbitrary
message to any object without restriction. Well, this experiment has
been tried, and the results predicted by this theory did not happen.
So I guess the theory loses this argument.
This is not to say that there is no sense in which the above quote has
any validity: inheritance enhances dynamic polymorphism, it just does
not enable it. Admittedly, inheritance from a common, value-oriented,
static type such as a classical ADT does enable "lexical" or "static"
polymorphism. That and a dollar will get you a cup of coffee. Yawn.
[As to whether or not Smalltalk-80 as defined in the Blue Book
permits more than one root class, I have my own opinion but decline
to state it so as to avoid introducing any non-sequitur issues].
> ... "Supertypes in object-oriented systems may be viewed as
> parametric types whose parameter is omitted by the user." ...
As long as "type" denotes "ur-type"...
This ends part one of my reply. NetCruiser runs out of "String space"
when I attempt to post the whole thing. It's obviously not a Smalltalk
program :-).
TO BE CONTINUED...
--Alan Lovejoy (love...@ix.netcom.com)
Piercarlo Grandi
>>> Harris") said:
"Dave> dena...@nando.net (Rick DeNatale) wrote:
Rick> What I have come to realize is that we have here a classical
Rick> Kuhnian paradigm shift. The fact that message sending in Smalltalk
Rick> is not just a procedure call is the key fact that is being missed
Rick> here. It is not a procedure call, not because it has asynchronous
Rick> semantics as in an actor language, which it doesn't, but because
Rick> it moves all knowledge of the called object's structure to the
Rick> called objects side of the interface, thus eliminating the need
Rick> for a caller to be concerned with it. This changes what types are
Rick> in a way that is easy to miss.
Dave> But normal, static procedure calls
A very strong note here, just in case, just to make sure: I have never
ever written that "static procedure calls" are the same as "message
sending". I have always argued that "procedure call" covers both the
static and the dynamic case, as demonstrated by the countless languages
that have dynamic dispatching and still one described it as "procedure
call"; and that not only therefore "message sending" is redundant, it is
positively confuding because "message sending" is a term commonly used
to describe a completely different mechanism from either static or
dynamic procedure calls, for example the inter module communication
mechanism used in actor or distributed systems.
Dave> can provide the same shift.
As to this, yes, but not really: because dynamic procedure calls
_directly_ support certain forms of genericity and reuse that are
painful to support manually as in:
Dave> For example, one can use C (FILE *) routines (fclose(), fread()
Dave> etc) without knowing or caring about the structure of a FILE
Dave> object. It's true that the caller in C knows more than the caller
Dave> in Smalltalk - my point is that more enlightened programmer can
Dave> experience the same paradigm shift with a lesser technology.
but with much greater inconvenience (see the Xt pre-widget library). And
the name of the game for OO is greater convenience/productivity thanks
to higher reuse, so even if it is _possible_ to adopt an OO style in a
language that does not support OO and the features that are useful for
programming-in-the-large, it is not a very good idea.
Therefore the enhacement you mention is rather important:
Dave> Smalltalk enhances the power of abstract data types by combining
Dave> them with dynamic dispatching. There is a general principle
Dave> here. Doing anything dynamically - that is, at run time rather
Dave> than at compile time - gives you greater power and flexibility.
This is indeed very true: and leaving things at runtime has been for a
long time why things Lisp and similar languages have provided (at a
price) greater power and flexibility than many other more static
languages.
Dave> Part of this debate has been about whether doing something at run
Dave> time justifies giving it a new name.
This is not really the debate I have participated in, I think. It has
been whether the same mechanism ought to be named by two different
names, one of which also names a completely different mechanism too.
Dave> I am one of those who believes it doesn't. I prefer to take the
Dave> old name and prefix it with "static" or "dynamic" as
Dave> appropriate. Thus I prefer "dynamically dispatched procedure call"
Dave> to "message send".
Or just procedure call: for after all whether a procedure call should be
resolved statically or dynamically should be really an (almost, let me
add) invisible optimization, as Meyer argues.
Dave> I prefer "dynamic type-checking" to "class".
Note that again I perceive the subject of my arguments as being
different, and I note this just to make sure, not because you are
necessarily thinking of them: here it is not the terminology to be
inappropriate, I believe, but simply the idea that the notion of class
is essentially different from that of type (while "real" message sending
is entirely different from procedure calling), when in fact is it is
just a particular case, if one wants to go as far sa saying that.
Even if classes do represent the very same notion as types, being a
special case, there is a significantly different emphasis: that a class
is/should be that particular notion of type in which the type
representation is hidden but to the procedures in the same module as the
type definition. Now this is a rather more fundamental specialization of
the notion of "type" (of which that of class is a particular instance)
than the distinction between dynamic and static dispatching, because
while the latter can be left as an optimization concern, restricting
types to be as one with modules and thus be classes profoundly
influences the way one organizes programs (the availability of dynamic
procedure calls does too, but IMNHO in a less fundamtantally specific to
OO way).
Dave> My reason for this is that dynamically dispatched procedure calls
Dave> have a great deal in common with statically dispatched ones. It
Dave> makes sense to me to extract that common part and call it
Dave> "procedure call", so that we can talk about it independently of
Dave> whether it is static or dynamic. For example, the issue of whether
Dave> you dispatch on one argument, as in Smalltalk, or on multiple
Dave> arguments, as in CLOS, is (or ought to be) orthogonal to whether
Dave> the dispatching is static or dynamic. Similarly, using the
Dave> "dynamic" prefix emphasises the costs and benefits that we know
Dave> are common to anything done at runtime. Using new names tends to
Dave> cover up the commonality.
Oh yes, this is mostly agreeable.
Dave> I do sympathise with those who believe the paradigm shift deserves
Dave> to honoured by new names. The problem is that you can't draw a
Dave> line at the exact point the shift occurs. For some people,
Dave> fclose() should be called a "message send". Others will remain
Dave> unenlightened even by Smalltalk. You can't label shifts, you can
Dave> only label technology.
This is a point, but the main problem is that "message send" is not
devoid of other established connotations, therefore it could be merely
used to denote a special case of procedure calls. It is already
frequently used to denote something _completely different_ from a
procedure call, and something that is also in Smalltalk-80, as part of
the process/queue/simulation facilities.
The relatively ``Smalltalk'' community can well go against the grain
and call dynamic procedure calls "message sending" if it is understood
this is really dynamic procedure calls and not what everybody else
understands as "message sending", but the risk of confusion is really
large. As Ralph Johnson has said (if I understood him correctly), it
is also true that even believing wrong things does not matter in
practice if one then does the right thing, still...
Having an arbitrary synonym for "dynamic procedure call" is gratuitous
but in itself only modestly confusing (while at least "dynamic procedure
call clearly indicates that it is just a special case of an already
known notion). The bad problem is really that "message sending" is
already loaded with a completely different meaning, and even worse, it
makes people think that the completely different meaning is what
actually applies to ``Smalltalk'', also because some of the language in
the Smalltalk-80 series and its intellectual ancestry seem to indicate
so.
Piercarlo Grandi
[ ... much omitted ... ]
Alan> The ability to have multiple, diffrerent implementations of the
Alan> same "type" is one of the main motivations for OOP.
Piercarlo> It is the main motivation for having modules and types at
Piercarlo> all. OO languages are only a small subset of those that allow
Piercarlo> to have multiple types to have the same denotation. Hey, even
^^^^
Piercarlo> Pascal does: [ ... ]
Alan> have different practical consquences than multiple Smalltalk classes
Alan> with the same interfaces.
This goes without saying. My point was that _even_ Pascal can do
multiple implementations of the same type denotation, and nothing more.
Alan> Contrast this with four Smalltalk classes whose instance variable
Alan> structures are anologous to the aforementioned Pascal record
Alan> types. Assuming all four implement the same protocol with the
Alan> same semantics (have the same interface), then we can do something
Alan> that none of the three type-based variations of Pascal can match:
Alan> [ ... lots more on, IMNHO, the same point ... ]
Indeed, but that goes without saying, why expend so much on it? Have you
discovered the difference between the very limited type system of Pascal
and the stronger one of Smalltalk this morning and you are still excited
about it? I hope not. They do express the same notion of type, but it's
obvious that's in very different ways, so what.
Alan> [ ... ] If two objects, whose classes differ, represent the same
Alan> logical value, then they cannot both be in the same set of logical
Alan> values. [ ... ]
How can two objects be in the same or different sets of logical values
if they are _not_ logical values as they _represent_ them? :-)
Alan> [ ... ] OOP langauges can take advantage of this "type
Alan> equivalence"
"Conformance" is a more precise term. If all calls in a body conform to
a non singleton set of types, then that body is generic with respect to
that set of type (a purely syntactic property, usually). Thus
(wide) conformance is the root of genericity (I think this is discussed
in the Cardelli&Wegner model 'Fun' that I have omitted from my quotes
for brevity).
Alan> during program execution. Statically-typed value-oriented
Alan> languages cannot.
By definition: for if they are statically typed they cannot be
dynamically typed.
But genericity (the consequence of conformance) to which you seem to be
referring can be exploited in both OO and non OO languages, both
statically and dynamically, as it is a completely orthogonal issue as to
being OO or non OO (even if OO genericity has its own special charms).
Alan> A difference (for instance, the class of an object) that makes no
Alan> difference, is no difference (for instance, of type). If different
Alan> Smalltalk classes whose interfaces are indentical denote different
Alan> "types," what practical consequence does it have? What
Alan> **difference** does it make? What is the utility of this
Alan> distinction?
Ah, as to this I am pleased to argue that for example they require
completely different verification, and if they don't denote the same
type denotation, also completely diffent specification.
Types/classes represent type denotations, and each representation is
characterized by its own interface, body, and specification, whether or
not this is made explicit in the specific linguistic structure used to
express the type/class.
There are in effect _four distinct_ algebras/lattices over bodies,
interfaces and specifications and over their combinations,
types/classes; in some cases they are forced to parallel each other, but
this need not be the case. In particular types with the same interface
need not have at all the same spefication (or body), but if they do,
that's an interesting fact that does help quite a bit. And we have been
discussing specifically "types", not the relationships between them,
or their denotations, or their constituent bits (whether expressible in
the particular language or not), or those among the latter.
Alan> I already know your answer: the words "type" and "class" are
Alan> considered by you to be synonyms,
As far as their notions go, not literally... Let me repeat:
for class:
"A _class_ describes the implementation of a set of objects that all
represent the same kind of system component." ... "Programming in the
Smalltalk-80 system consists of creating classes, creating instances
of classes, and specifying sequences of messages among these objects."
[Classes and Instances, page 8]
"Every Smalltalk-80 object is an _instance_ of a _class_. The
instances of a class all have the same message interface; the class
describes how to carry out each of the operations available thru that
interface. The selector of a message determines what type of operation
the receiver should perform, so a class has one method for each
selector in its interface. When a message is sent to an object, the
method associated with that type of message in the receiver's class is
executed. A class also describes what type of private memory its
instances will have." [page 40]
"*class* An object that describes the implementation of a set of
similar objects." [Summary of terminology, page 53]
"Every object in the Smalltalk-80 system is an instance of a
class. All instances of a class represent the same kind of system
component. For example, each instance of 'Rectangle' represents a
rectangular area and each instace of 'Dictionary' represents a set of
associations between names and values. The fact that all instances of
a class all represent the same kind of component is reflected both in
the way the instance responds to messages and in the form of their
instance variables." [Subclasses, page 56]
for type:
"Untyped universes of computational objects decompose naturally into
subsets with uniform behaviour. Sets of objects with uniform behaviour
may be named and are referred to as types. For example, all integers
exhibit uniform behaviour by hacing the same set of applicable
operations. Functions from integers to integers behave uniformly in
that they apply to objects of a given type and produce values of a
given type." [Cardelli&Wegner, page 473]
... "A type may be viewed as a set of clothes (or a suit of armour)
that protects an underlying untyped representation from arbitrary or
unintended use. It provides a protective covering that hides the
underlying representation and constrains the objects may interact with
other objects. In an untyped system untyped objects are ``naked'' in
that the undrlying representation is exposed for all to see. Violating
the type system involves removing the protective set of clothing and
operating directly on the naked representation."
As an aside, note that the latter does not in any way support the
idiotic notion:
David> Thus, types are a characteristic of variables which aid the
David> compiler in producing proper code.
as the quotes on type inference, which I also produced, emphasize even
more (for it is a type inference system, possibly aided by explicit
declarations of some/all terms of an expression, that results in static
typing that has the effect above).
Alan> so distinguishing the "type" of objects whose classes differ is
Alan> exactly as relevant as distinguishing their classes. But then this
Alan> discussion is reduced to a mere quibble over terminology.
Which has been my argument indeed :-). Instead If I have understood
correctly the argument by you and others has been that the difference is
not merely terminological, which I think is wrong, because a lot of
people have been
pcg> [ ... ] confusing a type and its interface/specification. Such
pcg> confusions are popular in comp.object, and even in much of the
pcg> research literature, [ ... ]
The mistake is perhaps made comprehensible and reprehensible by the
following exchange in another discussion:
carroll> A fine example of this is Smalltalk, where you never define
carroll> an interface as an explicit, seperate part of the source
carroll> code. But when you sit down with your Smalltalk browser, you
carroll> can view the interface as if it had been implemented
carroll> seperately.
Dent> And using a browser such as Object Master the same applies to
Dent> your C++, C, Pascal, Modula and Object Pascal code. The only
Dent> reason for splitting items into files is then for performance
Dent> and reducing compile-time dependencies.
Alan> But I think there is more to it than this. The problem is that the
Alan> term "type" as used in Pascal,
Just to make sure, not that you are necessairly implying this: I never
wrote "type as used in Pascal". I mentioned and quoted explicitly the
popular notion of type described in Cardelli&Wegner. I only used Pascal
as an extreme example.
Alan> as used in the OOP community and as used by other domains (such as
Alan> mathematical type theory) does in fact denote different things,
Which has been one of main arguments all along: for I have tried hard to
make the distinction, and I have explicitly qualified my statements,
using _emphasis_, to make clear what I was writing (still a lot of
people have tried to pretend they did not get it).
Alan> and you aren't doing as good a job being consistent in your usage
Alan> as you'd like to think.
I try hard -- and so far I have been the only one. I may have have
slipped occasionally, but hey, that's fair.
Alan> And some of the quotations you make below suffer from this same
Alan> problem--or date from a time when modern usages were not yet
Alan> established.
A point I also made myself several times, usually with the purpose of
trying to explain how so many self-styled experts could write such
inanities.
Alan> There is admittedly an analogy between the "type" concept of
Alan> value-oriented languages and the concept called "class" in
Alan> Smalltalk.
Alan> Rick DeNatale has admitted this. Jan Steinmann has admitted this.
Quote them. I haven't seen _anything_ of the sort.
Alan> I am admitting it now: it is possible--even useful--to abstract a
Alan> higher level concept from the analogies between the value-oriented
Alan> concept of "type" and the concept "class." But don't switch the
Alan> meanings of the term "type" without warning among "type as it
Alan> exists in value-oriented languages," "class,"
But I never did this of all things. I always used, rather explicitly,
the notion of type as it exists in most popular languages (OO and non
OO, nost just non-OO, as I have written many many times, quoting
Cardelli&Wegner and Meyer and OOSLA as using type to use "type" to
describe classes in many popular OO languages: this point was at least
understood by David Smith when hw included C++:
David> Popular languages that most programmers are familiar with (C,
David> C++, COBOL, FORTRAN, PL/I, and Pascal come to mind) have
David> types. (I'm leaving out research and specialized languages on
David> purpose.)
in an early segment of this discussion. I have used myself some of those
as topical examples, and also Lisp and Eiffel).
Such a notion of type, that I have clearly documented many many times in
the past few months by quoting relentlessly its expression in several
bits of published literature, is indeed:
Alan> "the abstract ur-type (to coin a term) that denotes what is common
Alan> between classes and types in value-oriented languages"
(if one substitutes "abstract ur-" with "generic ", and adds that I have
never used the "value-oriented" qualification, but the "some popular"
one)
But not at all:
Alan> and "type denotation/algebra as defined in type theory."
Because there is very little that is common between a notion of type for
programming languages, however generic, and
Because the notion of type I have used is the *generic*, not abstract,
notion of type as differently expressed in many popular languages, as
described in the quotes above by Cardelli&Wegner; it is generic because
it tries to subsume meaningfully all those different expressions, but it
is not abstract in the sense that type denotations are. Indeed I have
quoted Cardelli&Wegner not only giving a generic notion of type in
languages, but also one (several actually) of type denotation in type
theory, just to empahsize that they were on totally different planes.
Alan> So let me state my position very explicitly: A Smalltalk class is
Alan> not identical to what is called a type in value-oriented languages
Alan> such as Pascal,
No question as to that: they are languages with the same notion of type,
but totally different type systems expressing it (and the Smalltalk-80
one is far stronger).
Alan> nor is it identical to what the OOP community calls a type (which
Alan> is synonomous with interface),
_Some_ people do, contradictorily. I have forestalled any possible
confusion by _clearly_ qualifying my argument to exclude this confusion,
by providing quotes, and even if despite this somebody has suffered such
"confusion", I have provided quotes from OOSLA that show indeed an
inconsistent usage of "type" to label both the linguistic construct and
just its interface bit, and I have even quoted the admission that using
a notion of type based on one of interface "conformance" causes obvious
problems:
Piercarlo> in "Object-Oriented Languages, Systems, and Applications"
Piercarlo> (a collection of survey essays, several of which I
Piercarlo> dislike), published by Pitman, there is a discussion on
Piercarlo> pages 86-91 on "TYPES AND OBJECT ORIENTED SYSTEMS",
"In Smalltalk, a subclass does not necessarily conform to its
superclass; for example, it may override some of the operations of
the superclass so that they expect different classes of
arguments. Moreover, one class may conform to another without a
subclass relationship existing between them. What a subclass and its
superclass *do* have in common is part of their representation and
some of their methods. In short, inheritance is a relationship
between implementations, while conformance is a relationship between
interfaces".
"Note that rules for type checking are normally based on the syntax
of the specification alone. For example, two types which provide the
same operations must be considered to be the same type irrespective
of the semantics of the operation, Similarly rules for subtyping
must be based solely on the interfaces provided. This is a major
weakness of any abstract data type based languages and is an area
for future research."
Let me add: apart from the confusion between being interface based type
checking and being an ADT based language, this is indeed a major problem
with confusing conformance with typing, and the lattice of interface
reuse with thart suitable for a _type_ (rather than conformance)
checking system.
Alan> but there is a higher level abstraction that captures a symmetry
Alan> between value-oriented types and Smalltalk classes. I will refer
Alan> henceforth to this concept abstracted from "value-oriented type"
Alan> and "class" by the term "ur-type."
This generic (rather than abstract) notion is what I have called "type",
and Cardelli&Wegner call also "type", and Meyer also calls "type", as
known in most popular languages, as I have demonstrated many many
times. I guess this concludes the discussion: there are some issues of
detail later, but let's skip most of them.
Alan> And the usage of the term "type" to mean "interface" has less
Alan> dissonance with the meaning of the term "type" in type theory than
Alan> does the usage you advocate. This is why the usage has become
Alan> popular.
As to this, the point has alreay been raised. Let me repeat my
observations as to this (the very essence of News is repetition, as
somebody ovbserved and I have rediscovered in this thread).
Firstly just a side note that in Smalltalk-80 there are two
``approximations'' to the interface concept, but neither are part of the
language like 'class' is: one is a programming _idiom_, the abstract
class, the other is a way of _describing_ classes.
1. A _procotol description_ lists the messages in the instances'
message interface. Each message is accompanied by a comment
describing the operation an instance will perform when it
receives that type of message."
This may be seen as a limitation, BTW. There are languages like
Smalltalk-NeXT :-) and Modula-3 in which interface specifications aka
protocols are linguistic constructs, and one _could_ found a notion of
type on that. I cannot see the merit of doing so:
* First the established usage in most popular languages and textbooks
and literature is to use "type" to label the notion I have documented
above which the same as that of "class" in Smalltalk-80 (in
Cardelli&Wegner the equivalence is given so much for granted that they
virtually never use "class" for Smalltalk-80, they always use "type"
to describe the same entity). This is merely of course a matter of
convention, which has some weight independent of its merit.
* Second, the merit of the convention is actually solid: for a notion of
type based on similarity of implementations is far more specific and
useful to the programmer than one based on mere conformance of
interface, and which gives raise to problems the other does not,
as admitted in the quote above from OOSLA.
Finally, some random (but representative) quotes just to remind you and
everyone that this discussion on whether Smalltalk-80 has a type system
where types are called classes was originated by the following inanities
by the sort of people Jan Steiman has so clearly described in one of his
articles:
David> Saying that all types derive from type Object misses the point
David> entirely. There are no types to derive from.
David> There are no types.
David> Smalltalk IS different.
Rick> I agree with David Smith that Smalltalk has no types, by the
Rick> definition most non-Smalltalkers use for type.
Rick> As I said I never said that inheritance should be eliminated. Only
Rick> that it doesn't form a type system for Smalltalk.
Michael> Smalltalk is different. Smalltalk-80 does NOT have types.
David> Amen. And saying otherwise doesn't make it so.
... "The requirement that all objects have a type allows objects to be
first-class values so that they can be managed as data structures
within the language as well as used for computation. The requirement
of type inheritance allows relations among types to be specified.
Inheritance may be viewed as a type composition mechanism that allows
the properties of one or more types to be reused in the definition of
a new type. The specification ``B inherits A'' may be be viewed as an
abbreviation mechanism that avoid redefining the attributes of type A
in the definition of type B. Inheritance, however is more than a
shorthand, since it imposes structure upon a collection of related
types that can greatly reduce the complexity of a system
specification. This is illustrated by the Smalltalk object hierarchy
in Goldberg and Robson[1983]."
Evidently some self-important published author does not understand much
about Smalltalk-80. :-) (hint: those with the lesser credentials, of
course :->).
Piercarlo Grandi
[ ... among many other things for which I am a bit of short of time now
... ]
Meyer> A language construct combining the module and types aspects is
Meyer> called a *class*.
Alan> At best, this applies to Eiffel and other statically-typed
Alan> languages.
Testing again the limits of your ignorance? This is the very
(conceptual) definition of class in OO in general, irrespective of any
particular language.
(I added "conceptual", because the mechanical definition is "user
instantiatable procedure", of course, but that's just the mechanism
with which the concept is realized).
Meyer> "This, by the way, is not the standard Smalltalk terminology. A
Meyer> routine is called a ``method'' in Smalltalk; applying a routine
Meyer> to an object is called ``sending a message'' to the object (whose
Meyer> class must find the appropriate method to handle the message)."
Alan> He's probably just forgetting the differences between Eiffel and
Alan> Smalltalk. So what? He's not the only one to make this mistake,
Alan> and if it can happen to him, it can happen to anyone.
He is writing that as to this there is no difference; in the surrounding
text hte does note the other main differences, and write this just to
emphasize this is not a difference despite the different terminology.
Besides, his credentials are much more impresssive that yours, and this,
according to the declared principles of your little clique, puts his
arguments above the objections of the likes of you.
James Raynard
Piercarlo Grandi <p...@aber.ac.uk> wrote:
>>>> On 7 Dec 1995 21:07:35 -0500, bytes...@aol.com (Bytesmiths) said:
>
>Bytesmiths> Civility has not been this thread's strenght, but I know of
>Bytesmiths> several lawyers who would be glad to file a libel suit over
>Bytesmiths> "If you dare to do so, quote it, liar. You are lying
>Bytesmiths> shamelessly here." This is clearly malicious, and I don't
>Bytesmiths> think many courts would believe that someone who is putting
>Bytesmiths> together a national standard could be knowingly lying about
>Bytesmiths> it.
>
>It would be interesting if you could mention the context of that quote,
>because what you report is news to me. I have been following this thread
>closely, and I have not seen anything like what you describe
I have been following this thread with, frankly, the attention it deserves,
but I had no difficulty locating the following quote (with some context):-
<quote>
pcg> It is also clear that the authors of the book quoted above are
pcg> talking the term 'class' and not the term 'type' is precisely the
pcg> reason why you and your friends are misled and ignorantly conclude
pcg> that classes are not types, more or less because the two words, not
pcg> the two concepts, are different.
Rick> But the concepts are different, a position for which there is more
Rick> than enough refereed literature to support.
If you dare to do so, quote it, liar. You are lying shamelessly here.
I have now quoted hundred of lines of Cardelli&Wegner and Meyer and
others that explicitly say that in Smalltlak-80 and in OO in general
classes are the concept as types in other languages.
</quote>
The headers for this message follow. For those not familiar with Demon,
it may be worth mentioning that their news servers add an X-NNTP-Posting-Host
line to any postings made to them, to considerably increase the difficulty
of using their servers to forge Usenet postings. For anyone whose feed has
already expired the article in question, they have a publically available
server, pubnews.demon.co.uk, which keeps articles for a minimum of 14 days.
Sender: pier...@sabi.demon.co.uk
Message-ID: <yf320qj...@sabi.demon.co.uk>
References: <johnson.817221545@sal> <49cjig$j...@newsbf02.news.aol.com>
+ <yf3u43q...@sabi.demon.co.uk> <DIqLy...@cunews.carleton.ca>
+ <yf34tvo...@sabi.demon.co.uk> <30BEB3F2.41C67EA6@integral.
+ com>
+ <denatale-011...@vyger317.nando.net>
+ <yf3vio0...@sabi.demon.co.uk>
+ <denatale-031...@vyger310.nando.net>
+ <vwjwx8c...@osfb.aber.ac.uk>
+ <denatale-051...@vyger112.nando.net>
Reply-To: pier...@sabi.demon.co.uk (Piercarlo Grandi)
NNTP-Posting-Host: sabi.demon.co.uk
X-NNTP-Posting-Host: sabi.demon.co.uk
James
--
Segmentation fault (core dumped): cannot find file '.signature'
Piercarlo Grandi
>>> Raynard) said:
James> In article <vwjka47...@osfb.aber.ac.uk>,
James> Piercarlo Grandi <p...@aber.ac.uk> wrote:
>>>>>> On 7 Dec 1995 21:07:35 -0500, bytes...@aol.com (Bytesmiths)
>>>>>> said:
Bytesmiths> Civility has not been this thread's strenght, but I know of
Bytesmiths> several lawyers who would be glad to file a libel suit over
Bytesmiths> "If you dare to do so, quote it, liar. You are lying
Bytesmiths> shamelessly here." This is clearly malicious, and I don't
Bytesmiths> think many courts would believe that someone who is putting
Bytesmiths> together a national standard could be knowingly lying about
Bytesmiths> it.
pcg> It would be interesting if you could mention the context of that
^^^^^^^^^^^^^^^^^^^
pcg> quote, because what you report is news to me. I have been following
^^^^^ ^^^ ^^^^^^
pcg> this thread closely, and I have not seen anything like what you
pcg> describe
^^^^^^^^
James> I have been following this thread with, frankly, the attention it
James> deserves, but I had no difficulty locating the following quote
Please note that the point was not the quote, as you seem to imply by
innuendo, which was literal as I had acknowledged by calling it a quote,
but what Jan falsely _reports_ as the _description_ of _its context_,
which is what I in fact took issue with in the paragraphs that follow
the one you quoted.
James> (with some context):-
The literal context of the quote indeed proves that Jan engaged again in
malicious misreporting when he describes what I argue about:
Rick> I tried to point out papers in the referreed literature that
Rick> have proven that classes are insufficient to be used as types in
Rick> Smalltalk. [ ... ]
(the paragraph above I have added to James' quote, because it contains
another false claim by Rick, that he had pointed out papers in the
refereed literature -- I have not seen any such pointer, perhaps because
of problems with my main news provider).
pcg> It is also clear that the authors of the book quoted above are
pcg> talking the term 'class' and not the term 'type' is precisely the
pcg> reason why you and your friends are misled and ignorantly
pcg> conclude that classes are not types, more or less because the two
pcg> words, not the two concepts, are different.
Rick> But the concepts are different, a position for which there is more
Rick> than enough refereed literature to support.
pcg> If you dare to do so, quote it, liar. You are lying shamelessly here.
pcg> I have now quoted hundred of lines of Cardelli&Wegner and Meyer
pcg> and others that explicitly say that in Smalltlak-80 and in OO in
pcg> general classes are the concept as types in other languages.
The wilfully false (for as I wrote I had already quoted myself hundreds
of lines of suitable refereed literature, so the claim that such did
contradict my argument could not have been made unknowingly) claim by
Rick was that there was "enough refereed literature" to contradict my
notion that "the two words, not the two concepts, are different"
Hey, Cardelli&Wegner in "On Understanding Data Types, ..." never even
use the word 'class' when they describe Smalltalk-80's type system, so
obvious it is a synonym for 'type' according to their popular
definition I had mentioned.
Jan stated instead that the lie was about the future "national
standard", thus implying maliciously that the issue was the contents of
the (draft) national standard, which was in fact never even mentioned in
that discussion, thus not just a false description of the context, but a
totally gratuitous fabrication.
In the paragraphs that I had written following the one you quote above I
had clearly made this point about the misrepresentation being about what
Jan _describes_ as the _context_ of his quote of my words (the future
"national standard") when it was about something completely different
(the "refereed literature" being contrary to my argument, when I had
already quoted it as supporting that argument).
Thanks for providing the quote that demonstrates that Jan's description
of the context of the quote was the usual misrepresentation, but I would
have preferred for Jan, uncharacteristically, to provide it himself.
But of course if he did that he would spoil all the fun of writing lies
innuendo and insinuations as to what other people are arguing for or
against. I have challenged Jan and the other proven liars to provide the
quotes that would "support" their various misrepresentations, and this
challenge has not been met _once_: indeed we still have to see the quote
that proves that I have ever expressed the concept that "someone who is
putting together a national standard could be knowingly lying about
it", as Jan characteristically writes.
There have been in fact whole articles in which my arguments were
falsely described without a single line of quote of what I had actually
written. Now we have a line of quote and a false description of the
context, which is only a few more lines long. Evidently certain
newsreaders don't provide cut&paste, and typing in those few lines is
too much for some people (I don't have OCR but I have typed in hundreds
of lines from refereed literature by hand, so remove certain "doubts")
that have such poor memories that they cannot remember certain books
even if they have read them, and that cannot even remember correctly a
few lines above those that they get around to type in. :-)
But, as you have demonstrated, cut&paste is easy enough when the
newsreader supports it, and providing the quote belies the fabrication.
Dave Harris
Kennel) wrote:
> I think people are focusing on the wrong thing. "message calls" can look
> like subroutine calls.
>
> But, if 'messages' themselves may be manipulated as data values
> have something new compared to Fortran-subroutines.
So you're saying:
anObject doThis
should be called a procedure call, but:
anObject perform: aSelector
should truly be called a message send? Get outa here!
:-)
> So what is it exactly that you get [from being dynamic]?
I've hesitated before replying to your post because I don't understand
what you are saying in the context of the thread. Your example included 3
features:
o Choosing the message selector at run time.
o Binding the selector to an implementation at run time.
o Catching illegal cases ("Does not understand") at run time.
I thought it was a good example of how being dynamic enables wonderful
things. Of course, the 2nd pair are what we've already been discussing;
the 1st, the one you added, is something C and C++ can already manage
quite happily. It is the 3rd feature which C++ lacks: it catches "Does
not understand" at compile time.
Truly, you get a synergy from having all 3 at once, especially if you
also have ADTs. But as far as deciding when the new paradigm emerges, it
just muddies the waters. There is, as I said earlier, no clear line.
Piercarlo Grandi
Alan> It is standard practice in the OOP community to equate "type" with
Alan> "interface itself."
This is just your impression, without any evidence. I have myself
complained that _some_ authors do so, and that there are many common
misconceptions of which this is one, as you corrrectly represent me here:
Alan> You yourself imply that you are well aware of the common usages of
Alan> terms such as "type" in the OOP community, including the
Alan> newsgroups comp.object and comp.lang.smalltalk (the immediate
Alan> context) and in the OOP-related computer science literature.
not that it is a "standard practice", for that is rather debatable. So I
have chosen not to make of that an issue:
Alan> Admittedly, you characterize these usages as wrong and mistaken,
Alan> but you are clearly aware of them, and should know that they are
Alan> not just isolated behavior of a few random individuals but instead
Alan> the normative behavior of the majority.
This is just your unproven impression again. As to me it is far from
clear it the behaviour of the majority, and even less clear that it is
also "normative". Evidence please...
Alan> So you have no excuse for acting as though
I would have such excuse because according to my impression the correct
terminology is used by most people, except for a vocal minority, and
besides I am regularly against incorrect terminology even if popular.
But I not making an issue of the popularity of terminology, but in
passing, so let's this pass, but not this:
Alan> each such usage was the aberrant and/or ignorant behavior of
Alan> another misguided wrong way driver.
because you are misrepresenting me here: I have regularly correctly
called as ignorant the _confusion_ between the two notions of type, not
the usage of the incorrect one.
When I write an argument that I have been careful (because I know quite
a few people make the confusion honestly) to qualify it explicitly so
that it is clear that I am talking about the Cardelli&Wegner notion as
in most popular languages, and someboy "refutes" it, using the protocol
notion of type, the confusion is either dishonest (if the author of the
"refutation" knows the distinction but hopes that the other people read
this thread don't and he can get away with it), or ignorant _of the
distinction_ (as I remember/hope to have written as a rule).
In the doubt, without evidence that the confusion was not intentional, I
am bound to assume that people are ignorant when they use that sort of
argumentation, unless there is evidence (as in the case of the
"confusion" between type and type denotation by some) that this was
deployed as a debating trick.
So: to use "type" to label protocols is IMNHO merely wrong, unless the
benefit is proven. To use "type" as protocol to contradict an argument
about "type" as in most popular languages/Cardelli&Wegner is indeed
ignorant (or dishonest), especially after I had emphasized the
distinction many times, even weeks before.
Alan> When 1000 cars are coming toward you on your side of the freeway,
Alan> and you're the only one going the other way, you'd be crazy to
Alan> keep going just because you think the signs are in your favor.
Alan> Crash!
Thinking about that, those that use "type" as "protocol" don't even have
the signs in their favour :-), and probably (and I say probably just
because I am not so sure, while you are sure of the opposite above) the
majority of published literature, even in OO, is against, or at least
the few books I have read. :-)
However, let's go back a bit, to October 25th, when I wrote that
Perhaps you are thinking of "protocols" and of research related to
them like R. Johnson's "Typed" Smalltalk. In that case I have some
sympathy for their ideas, for indeed, as a wrote, I don't like the
idea of "type as tag", but of "type as equivalence class".
Unfortunately Smalltalk as it is does not have a "protocol" based
typing system, but a "tag" based one, for it is class based, not
prototype based.
(a rare stile where I had not written -80 as a matter of course)
I find actually mildy amusing to reread today (considering the hundreds
of lines of quotes on the subject that I have typed in) the whole
article:
In-reply-to: David N. Smith's message of 24 Oct 1995 23:07:37 GMT
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.c++,comp.lang.misc
X-Disclaimer: Contents reflect my personal views only
Reply-to: p...@aber.ac.uk (Piercarlo Grandi)
References: <46b6vu$g...@watnews2.watson.ibm.com> <46h9g7$4...@news4.digex.net>
<46ihua$2...@outlaw.zfe.siemens.de> <vwj68hg...@osfb.aber.ac.uk>
<46jrjp$h...@watnews2.watson.ibm.com>
Message-ID: <vwjd9bl...@osfb.aber.ac.uk>
From: p...@aber.ac.uk (Piercarlo Grandi)
Subject: Re: Types, types: static vs. dynamic -- classification
Date: 25 Oct 1995 20:25:17 +0000
>>> On 24 Oct 1995 23:07:37 GMT, David N. Smith
<dns...@watson.ibm.com> said:
David> In article <vwj68hg...@osfb.aber.ac.uk> Piercarlo Grandi,
David> p...@aber.ac.uk writes:
David> Dumb-ole-me always thought that variables had a 'type' to tell
David> the compiler what the bits meant (and how many bits there were).
pcg> This seems a terrible way to start investigating the notion of
pcg> type: for what is really interesting is that _values_, whether
pcg> denoted by variables or by other values, "have" a type.
David> Not in 'conventional languages' where values are a handfull of
David> bits fully dependent on what you tell the compiler they mean.
Well, you must be referring to PL/360, BLISS, BCPL, or languages of that
ilk, then, because values are bitstrings only in that sort of language
(MOHLL), which is what few people would call a "conventional" language.
In most languages used in the past twenty years values are *implemented*
as untyped bitstrings, but that's just the *compiler's* business: the
*language* defines values as typed entities (save for modest exceptions
like the ability to do bitwise operations on integral types in C).
pcg> Also it may be the source of confusion to regard as a value
pcg> "having" a type, as opposed to "belonging" to a type.
pcg> What happens in any languages is that values have a (compiletime or
^^^^^^^^^^^
pcg> runtime) *tag* that identifies a type [ ... ]
E.g. in Smalltalk the result of the 'class' "message" to 'Object'.
David> There isn't any kind of tag on words in modern hardware.
So what? I was not discussing tagged hardware. Can you find a single
line in my article where I mention it? I can only find mention of
compiletime (ala Pascal) or runtime (ala Lisp) tags over values.
David> then they always had the same type (object) and it wasn't
David> necessary to say anything explicit.
pcg> Let's rephrase this: they always have the type "pointer to class
pcg> Object", and since all classes derive from class Object, ...
David> NO! They all have the type "pointer to some object".
Yes, of course, 'pointer to some instance of class Object', which is the
same thing (the values are actually instances of some subclass of
Object).
David> A pointer to a subclass of Object is in no way a 'pointer to
David> class Object'. There is no instance of Object stuck on the front
David> (as there sort of is for parents in C++).
Perhaps you should revise your Smalltalk: all classes in Smalltalk are
derived from class Object, and therefore all objects are _also_
instances of class Object. That there is no data attribute in class
Object is rather irrelevant...
David> And dumb-ole-me thought that objects were a whole different kind
David> of thing in which the data described itself and types were
David> unnecessary baggage from the past.
pcg> It is a curious notion that objects are a whole different kind of
pcg> thing in which the data described itself. This is a description
pcg> that reminds me more of frames and semantics networks and KR than
pcg> of object technology (but then there are those that there is no
pcg> difference). To some objects are just values in a programming
pcg> system based on language support of ADTs/classes/...
David> It's not the least curious in Smalltalk, where that is EXACTLY
David> what happens.
Perhaps you should really revise your Smalltalk, for in no way in
Smalltalk "data describes itself" and "types were unneccessary baggage
from the past". For in Smalltalk data are described by classes (which
implement/are types) not by themselves, and Smalltalk is a strongly (if
latently) typed language. Again you seem to have forgotten the small
detail of the 'class' method of the Object class, which returns the,
ahem, "type" of a data object.
David> Any variable can hold ANY object. The variable contents are, as
David> you pointed out, just a pointer. All that distinguishes one
David> object from another is how it acts. Period.
I read in an entry levle smalltalk book, "A little smalltalk", by
T. Budd, on page 18, under the header "Finding out about objects",
examples like:
7 class
i <- 17
i class == Integer
i isMemberOf: Integer
i isKindOf: Number
Perhaps the 'class' method does a purely behaviour based classification
of values, and classes are a "virtual" concept in Smalltalk...
Perhaps you are thinking of "protocols" and of research related to them
like R. Johnson's "Typed" Smalltalk. In that case I have some sympathy
for their ideas, for indeed, as a wrote, I don't like the idea of "type
as tag", but of "type as equivalence class". Unfortunately Smalltalk as
it is does not have a "protocol" based typing system, but a "tag" based
one, for it is class based, not prototype based.
David> And you don't know until you try!
Try harder.
Try _even_ harder ;-)
Piercarlo Grandi
>>> ("Dave Harris") said:
Matthew> But, if 'messages' themselves may be manipulated as data values
Matthew> independently of the particular target and arguments, then you
Matthew> have something new compared to Fortran
I still have to understand why are some people comparing Smalltall-80
procedure calls to _FORTRAN_ procedure calls. Why FORTRAN, if not as
straw man? I personally would compare them to Eiffel procedure calls, or
to Scheme prcedure calls, or to POP-2 procedure calls.
Dave> -subroutines.
Besides even in FORTRAN one can manipulate 'selectors' independently of
particular target and arguments, by passing subroutines as arguments to
other subroutines. This is used to good effect in many a numerical
library.
Even in as simple a language as C one has the ability to manipulate
(pointers to) functions as first class values,and thus implement
(simulate) dynamic overload resolution using libraries.
But all these are rather variations on a theme...
Dave> I've hesitated before replying to your post because I don't
Dave> understand what you are saying in the context of the thread. Your
Dave> example included 3 features:
Dave> o Choosing the message selector at run time.
Dave> o Binding the selector to an implementation at run time.
Dave> o Catching illegal cases ("Does not understand") at run time.
Dave> I thought it was a good example of how being dynamic enables
Dave> wonderful things. Of course, the 2nd pair are what we've already
Dave> been discussing; the 1st, the one you added, is something C and
Dave> C++ can already manage quite happily. It is the 3rd feature which
Dave> C++ lacks: it catches "Does not understand" at compile time.
Actually people like Meyer argue that it is a feature it has, not a
feature it lacks. Cardelli&Wegner argue that the earlierone can do type
checking the better. I frankly disagree: while this seems an obvious
win, in practice it does not seem that type mismatches at runtime are a
particularly obnoxious source of problems, at least compared to
others, so I tend to comclude that while obvious it tends to be rather
small.
Dave> Truly, you get a synergy from having all 3 at once, especially if
Dave> you also have ADTs. But as far as deciding when the new paradigm
Dave> emerges, it just muddies the waters. There is, as I said earlier,
Dave> no clear line.
The point here is that all these are just variations on the idea of
procedure calls: simply more or less restrictive forms of procedure
calls. And Smalltalk-80 hardly has anything new or rare in the way its
procedures are defined and called; for example it lacks something rather
useful like partial application (what is called freezing in POP), and/or
currying like ML (which has both).
Moreover, if you want, the computational model (rather than the
paradigm) starts to shift not quite in Smalltalk-80 (despite it having
the ability to reflectively grab amd hold onto a context), but in
Scheme, where one can do non-nested control transfers with continuations
(call/cc), and really shifts in actor systems, where there is no
procedure-call like mechanism, but there is message sending in arbitrary
(non nested) patterns amoing active objects, which is very different
from nested call/return pairs among passive procedures like in
Smalltalk-80.
That one can do nested call/return pairs among procedures using several
different levels of sophistication and dynamicity does not change
computational model, or represents a paradigm shift, merely increased
convenience and flexibility.