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

[snip]
> No.  If A1 wants to send messages to B1, it should NOT use a direct message
> send.  It should call one of the functions that module B has exported for
> this purpose.

I.e. instead of B1 ! {A1, ping}, somethign like B:ping(B1, A1)?

Hmmm. Ok, I guess.

There's some discussion of this in:

   http://www.erlang.org/doc/r8b/doc/design_principles/part_frame.html

(er..for other readers :)). It's been a while since I had looked at
that. The server one is making more sense....

[snip]
> 	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.
> 	
> No, I'm saying that the recommended way to design Erlang systems is to
> hide the message passing inside modules.

Right, gotcha. Hmm. I don't think we're *all* that far apart. Hiding the
message passing in modules won't help the wild syntax issue if modules
themselves have wild syntaxes. Contrawise, if the messages could be
exported to a standard syntax, then that it's *mesasge passing* rather
than function invocation shouldn't matter all that much.

>  The "invented syntax" here is
> the private protocol (set of messages understood by the processes that are
> managed by the module).   The "standard sequential syntax" is function calls
> (public protocol).

Yep. Gotcha.
 
> The rule of thumb is that a "naked" message send should normally be done
> only to a process that is managed by the module where the send lexically
> appears.

Whereas in Smalltalk-72 *only* naked message sends are available.

> One way in which this is relevant to Smalltalk is the distinction between
> "public protocol" -- interfaces you can use from outside a module and which
> are meant to be fairly stable -- and "private protocol" -- stuff you can
> do inside a module which can change completely from version to version.

Well, there's the "private" category, and the pvt prefix (which will
generate warnings).

> This is one thing that could improve in Squeak browsing.
> There's no way to tell, for example, which of the N hundred methods in
> Morph are meant for ordinary mortals to use and which of them are there
> to support other things and could be expected to change or disappear.

Yes. Some of this could be achieved by better organization, but I'd prefer
"hints", i.e., so I can "browse the newbie" methods. The Lexicon does a
good job of slurping *in* protocols (e.g., from up the class tree). It'd
be nice if it did more filtering *out* protocols.

Indeed, I'd love a "breadcrumb" trail. Just from familiarity with the
system, I often know where to start when untangling a class (i.e., with
a class side method, with the stepping methods, with...)...but not
always! It'd be cool if, as a documenation tool, I could specify "look
here to understand blah blah, then here, then...".

[snip]
> 	(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.)
> 
> The Prolog "limitation" lets you use forward chaining, backward chaining,
> top down parsing, bottom up parsing, left corner parsing, depth first
> search, breadth first search, iterative deepening, &c &c.  It's an
> adequate building block for _programming_ these things, and many others.

Yep. 

> Mozart/Oz may let you specify SOME different strategies, but whatever set
> they provide, there will be others that you DO have to code up.

Sure, but there seems to be some sort of different in having "hooks" where
you can plug in your engine, rather than, e.g., having to run it through a
metacircular intepreter. (Er..not that I know that Mozart/Oz let's you do
that.)

[snip]
> In the same way, Erlang provides a minimal _building block_.

Yep, but that building block ends up being somewhat priviledged.

[snip]
> If function call is cheap, and basic message passing is cheap, it doesn't
> _matter_ if other things _have_ to be coded up on top, what matters is that
> they _can_ be coded up affordably.  And then you stick them in the library
> and presto chango, a technique that nobody _else_ has to code up, but
> without building overheads into the primitive mechanism.

Well, maybe. I don't find a lot of prebuilt, ready to run alternative
search strategy libraries in the standard libs of the Prologs available to
me. I find lots of books detailing ways to code these things up
myself...but I end up trying to code these things up myself :)

> It's rather like the way Smalltalk doesn't build in multiple inheritance,
> but didn't stop people experimenting with it because it _does_ provide the
> hooks you need to do it yourself.

Well, yes and no. From what some folks tell me, DNU based MI was really
too slow to be of all that much use. Frank Adrian has mentioned to me
*many* a time his frustration that the MOP facilities in Smalltalk are
often too weak for *practical* systems...i.e., you need to dig into the VM
at some point.

SmallScript is interesting in this regard because the low level bits
themselves are (David says) rather modular. So, yes, you have to drop down
to C++ to code up a new object format, but its then coequal with the
standard SmallScript one.

(MOPs alone are no panacea, as the Common Lisp experience shows. The
vendors tune their implementations to the standard object system and
typical tricks and you can pay large speed prices if you diddle things in
an unanticipated way.)

But I do take your point about public protocols ;) And I do think that
being *able* to pop in an alternative to the builtin mechanisms at the
high level language level is a wonderful, wonderful thing.

I will point to CodA, which is an OO MOP:

	"In concrete terms, rather than having one meta-entity which
logically describes all aspects of object behaviour, CodA has many smaller
entities (meta-components) each of which describes one small, largely
orthogonal, aspect (behaviour) of an object. The important points here
are: 1) a relatively fine-grained decomposition and 2) realization of the
decomposition with objects (rather than methods)."

	http://web.yl.is.s.u-tokyo.ac.jp/members/jeff/research/coda.html


Cheers,
Bijan Parsia.