Re: Proposal: An OOC Package Tool

[Dirk Muysers <dmuysers@capgemini.fr>]

>From time to time traffic flares up on the Lagoona list, and then goes back
into lethargy for some time. This is annoying as it spoils the show and
makes the project loose momentum. It also encourages people to make their
own way into language design. Or then, it would have been better to keep it
secret until maturity.

There are two (often contradictory) aspects of language design: The
theoretical, purely academic face of the coin, and the reverse which says
that languages are made to be *used* to build systems. And here, as a
language customer, I often feel that my (highly practical) needs are not
catered for by most language
designers.

As a practitioner, I enjoy to peep into ongoing experiences and assess their
usability. I have followed the Oberon bandwagon from its inception, and
while I have always been a bit allergic to Java, I had a serious
look at Lucent's Inferno and the way it can be used advantageously.

Here, I learnt several points: To have (at least the possibility) of several
implementations of a same module
interface is definitely an asset. In fact, Oberon itself relies heavily on
that pattern, look at all those

        intel.win32.Kernel.... etc.

Only, they do it by manually copying the interface. Now is that really any
better?

An other point learned from Limbo (the Inferno brand of "modular C"), is
that while it may be very challenging for a scientist to reason about the
soundness of parametrical polymorphism, the Limbo people took themselves be
the hand and simply added a couple of  *built-in* generic constructed types,
such as "list of",
and "channel of",  in addition to the ubiquitous "array of". And I grant
you, that this caters to 80% of all situations where a programmer would wish
to have genericity. A very good and powerful candidate would be John Gough's
SEQUENCE OF proposal (for Modula 2) which subsumes lists as well as
extensible arrays.

Limbo BTW, once more, denies us enumerated data, which is one of the
gimmicks most commonly requested by practising programmers!

Now about some theoretical aspects of Lagoona. I continue to feel uneasy
with the ambiguity between messages and functions. At one hand the Lagoona
message is said to be a function, but it does not allow for returning data.
Why? If it is really a function, then I do not see any reasonable
implementation that would
allow to *RESEND* it, lest you begin tampering with the stack. To say the
least, it could not be significantly more efficient than copying the parms
and reissue the same function again and again. Or then, you reify the
message, and then, de facto, we could end up with "VAR sometype" in a record
field. A horror vision, isn't it?

This makes me think of two of the remaining evils in Oberon: Aliasing, and
other backdoor magic. Oberon boasts making everything visible to the
programmer and yet it allows VAR args, and thus, the transmission
of hidden parameters, such as a record type, or array dimensions. The
solution would be to ban BYREF parameters for records and arrays, and allow
a function to return more than one result (and also structured
results). This has been done in Limbo.

The idea of separating the concepts of typing and classing is old, and
already has a tremendous amount of literature, but wherever you look, be it
B.Liskov and the Theta effort, Kim Bruce's, R.Ierusalimschy's, or
L.Cardelli's papers, to mention only these which come to my mind, there is
always question of interface functions, never of reified messages. Why
should we have these? System 3 nostalgia? Have the cake and eat it? M.
Franz, in one of his papers said that message broadcast could solve some of
the iterator/rider problems by applying a message/function to a collection
while hiding its implementation. What about closures and higher order
functions (mapcar) which are conspicuously absent in Oberon (as well as all
other non-functional)languages?

I agree that inheritance is an evil in a world of components, but type
extension is a useful commodity.Chase the biest and it reenters by the
backdoor: Limbo had done away with extensible records (and inheritance),
only to reintroduce, in version 2, guess what? Variant records, and TAGCASE
OF....!

The fact is that you can not conceive of, to take an example, healthy AST
manipulation without record extensions. Look at Hanson and Frazer's
outstanding lcc compiler code (a pleasure to read), and see the length to
which they had to go, to put an extra opaque pointer into the nodes and
introduce backend-dependant "extension" structs which makes 20% extra code,
only because C has no extensible records.

I know, I know, Lagoona is a research project, etc. But Oberon, after a
number of years of usage, needs badly a major revision, and why not take the
occasion, and get more than one thing right.

And please, dont forget the language customer!

This is no flame war, but a couple of ideas to ponder.

/dm

-----Original Message-----

>   Hold your horses, Chris! Currently Lagoona does not require separate
>interface and implementation modules (regarding source form) and I am not
>fully convinced yet that this is needed. :-)