On Mon, 18 Feb 2002, Richard A. O'Keefe wrote:

> Bijan Parsia <bparsia at email.unc.edu> wrote:

>> I was reflecting on the problems you discussed at various points of
>> each class inventing syntax in Smalltalk-72, and wondered why it
>> doesn't seem to be a problem in Erlang.
>
> The answer is 

Well, I think there are several answers ;)

> that one of the design rules in Erlang is
>     HIDE THE PROTOCOL!

But this is one of them :)

> Typically, a process->process communication protocol is hidden inside
> a module.  From the outside, you call functions to get things done,
> and never see the protocol.  In effect, each class _does_ have its own
> syntax, but that doesn't matter because other classes never see it.

That's not quite right, is it? I mean let's say I have two processes, one
instantiated from module A (call it A1) and the other from module B (B1)
(following the Erlang book's mapping of classes to modules and instances
to processes, roughly).

So, I want A1 to send messages to B1. A1 has to know the right protocol
for B1. If I want B1 to send back to A1, B1 has to know A1's protocol.

Of course, C1 or the user process can stay clear and invoke functions from
Module A that generate processes (both A processes and B processes) and do
message sends, etc., but surely this isn't *advancing* matters any :)

At least, no more than my acoount, wherein the advantage to Erlang was the
relatively lack of message sending, i.e., a standard sequential syntax
which can carry a lot of weight.

This is pretty much, I take it, what you're saying, except you seem to be
saying that you can *hide* the invented sytnaxes behind the standard
sequential syntax. I'm not sure *that's* true.

> There is of course one major difference between Erlang and Smalltalk-72,
> which is that Erlang message-passing is rather like UDP (in fact, in at
> least one Erlang implementation it _is_ UDP)

Yes, I think Alan missed the point that Erlang *doesn't* send PIDs and get
returns out of the box. You have to code that explicitly. My take on
Smalltalk-72 is that returns happen automatically (I could be wrong!!!).

> so it's expected to fail from
> time to time, and you __really__ don't want to mess around with the details
> of a protocol that's designed to handle that.

I'm lost. I thought the issue was having to design (and later read) the
syntax of messages. Transport level issues seem a slightly different
thing.

(Of course, when you manually encode the PID, etc. you *are* layering a
transport (request/reply) on top of the ansych one...that seems to be a
bit of a lack in Erlang, rather the way Prolog limits you to one builtin
search strategy, whereas Mozart/Oz let's you specify different
ones without having to code them up.)

SOAP isn't so bad on this front, I might add.

>  Some protocols take the TCP
> route of trying to build reliability in at a fairly low level, and of course
> that is really best hidden.  (How many TCP users know about the three-way
> handshake at the start, or the slow start mechanism, or the four-way
> handshake at the end?  How many _need_ to know?)  The majority of Erlang
> code seems to rely on higher level protocols for fault recovery; since
> Erlang programs are supposed to keep on running when you start pulling
> boards out of the hardware (I've seen it done) low-level protocols aren't
> enough.

I haven't, but firmly believe it :)

> So the answers are
> 1. Encapsulation (no novelty in Smalltalk)
> 2. High level "behaviours" for fault-tolerance.

Is 2 the same as "High level 'protocols' for..."? The bit I *like* about
SOAP is that the message format and the transport/protocol stuff are
completely (well...) separate.

> 	That being said, I don't quite get all of the Smalltalk-72 model, though
> 	I'm diligently (for me) perusing the manual :)
> 	
> Where is that?

As Helge Horch posted:
	<http://www.spies.com/~aek/pdf/xerox/alto/Smalltalk72_Manual.pdf>

There's a version of Smalltalk-72 that ran on fairly recent Squeaks. I
intend to try it out on a more recent one soon.

Ooh, the Swiki sez (at http://minnow.cc.gatech.edu/squeak/989) that
there's a version that works with 3.2a. Good.

Playing with St-72 in Squeak is on my agenda for a SqueakNews column,
FWIW.

Cheers,
Bijan Parsia.