Loose type checking in E

[Mark S. Miller]

At 10:05 PM 10/12/98 -0400, Tyler Close wrote:
>>Could you give a small example that cannot be coded well in Java using
>>only inheritance-based polymorphism?
>
>That's not the point. As was demonstrated by the JGL, it is possible to
>code an STL like library in Java using inheritance-based polymorphism. As
>was also demonstrated by the JGL, this library will suck.

Can you give a small example from the JGL, or a URL to some online JGL
javadoc, of an abstraction would could be elegant in E or a system with
parameterized types, but could not be elegant in Java -- whether or not
it's elegant in JGL?


>Again, you seem to arguing that if you take an undisciplined approach you
>will land yourself in trouble.

I'm arguing about how much discipline, and how many separate disciplines,
are necessary to stay out of trouble.  Our ability to follow complex
disciplines is bounded.  In order to create more ambitious systems, we need
to increase the functionality we can make work in exchange for a given
amount of discipline.  Flipping this around, we need to seek ways to build
a given amount of functionality at a lower cost in discipline.


>Why should client code hold locks in the GUI while it is executing a
>transaction in the database? Don't do it, you're asking for trouble that
>you don't need.

What do you say in the documentation of your GUI library so that your
clients know not to do this?  Remember, under our scenario you and Joe (the
database creator) don't know about each other, your clients know about both
of you, but their widgets might be composed both in the same GUI and in the
same database, despite the fact that they don't know about each other.
This is a good test of whether the abstractions really enable
composition-by-contract.


>If you're asking for a global convention, it's "Coupling is Bad: Don't
>introduce dependencies that you don't need!"

May I quote you to yourself?


>[description of GUI concurrency design]

I like the design you describe, and I agree (in this context) that your
case of lack of serializability is probably reasonable.  But I must comment
on:

>... unless some moron gave the widget a pointer into an outer ...

Until you change this attitude, you *cannot* be allocating costs properly
between abstraction design and abstraction use.  From your user's point of
view, your abstractions are tools to get their jobs done, and these jobs
already have plenty of their own intrinsic complexity.  From everything
else you say, I think we agree on this, but I had to vent.


>>The one step we can take is to allow *one* globally known acyclic locking
>>convention.  Having allowed it, we need to prohibit the others -- the first
>>one uses up our capacity for such a convention.  Unfortunately, I think
>>I've got an inescapable need for one -- one vat debugging another.  The
>>debugee gets suspended pending action by the debugger.
>
>Which locks must the debugee and the debugger share?

Debugee waiting on a breakpoint.


>I am having a lot of difficulty accepting that a single computer should be
>treated as a distributed environment. See my reply to Chip Morningstar's
>post. I expect that your reply is going to be that you want a homogeneous
>environment; however, this ignores the fundamental truth that your
>execution space is not a homogeneous environment. Designs that ignore
>fundamental truths make me nervous.

See my reply to your reply.  My three other examples went against similarly
fundamental truths.


>Thank you for the links. I greatly appreciate this.

You're very welcome, I'd love to have more people around who know this
literature!  Btw, the "Lambda the Ultimate" papers are not about
concurrency per se, since they are about Scheme.  But Scheme can be thought
of as a non-concurrent subset of ideas from Actors (indeed, this is the
history), so these papers help one understand Actors in general.


	More, asynchronously, later,
	<- MarkM