Loose type checking in E

[Tyler Close]

At 10:48 PM 10/13/98 -0700, you wrote:
>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?

The JGL can be found at http://www.objectspace.com/jgl

I have a lot of bigger problems with the design of this library (some of
which they have corrected with newer versions) other than its inheritance
structure, but I'll stay on topic.

The iterator inheritance tree is 6 levels deep. Compare this with the C++
STL, which has no inheritance tree.

I believe something closer to the C++ version could be coded in E.

I wasn't expecting this thought to be so difficult to express. Let me explain.
All of the serious coding that I have ever done has been in statically
typed languages. I had never even thought about not having a type system,
but because of E, I thought about it. When I realized that no types meant
that templates were no longer necessary, and that they in fact existed to
solve a problem which wouldn't otherwise exist, I thought "Hey, that's neat!"

Well, since I'm already teetering on the edge with this point, I might as
well jump off the cliff.

An interesting perspective on this would be to consider E to be a fully
parameterized language rather than an untyped language. Think of the
runtime checks on method name / # parameters to in fact be a sort of
runtime compiler that is doing the expansion of the parameterized method.

If one were to add optional static typing to E, then one could imagine a
compiled version of E where the untyped methods were treated as templates
to be expanded.

This would be very neat indeed. You would have both models seamlessly under
the same language, it would just depend on who was compiling the code.

With optional static typing, you could further imagine a situation where
you do your exploratory programming / rapid prototyping without types and
then, once you've figured out what your object diagram is supposed to look
like, you pass through filling in the type information (or to stick with
the above analogy, showing the compiler what the only expansion of the
template will be).

Well, I think I am now in freefall. Please, no more need to hammer away at
me on this point.

>
>
>>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.

No, we need to find ways to incorporate and embed more discipline. More
ambitious projects will necessarily be more complex. We need more
sophisticated methods for dealing with this complexity. This
sophistication, to be widely disseminated, must be embedded into the way
that we naturally interact with our tools.

>
>
>>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.

Well, currently I am the only user of my GUI and my database and there is
no documentation.

That said, the interaction of the two is quite simple to lay out. It's the
one liner I laid out below. Don't introduce dependencies between any of
your tools by grabbing locks in one and then the other. This is just good
sense for multithreaded programming. Even the most moronic of developpers
that you wish to conjecture should be able to hang on to that one piece of
advice. I don't think this is too high a price to pay for the functionality
I'm providing.

>
>
>>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?

Only if you repeat it out loud several times.

>
>
>>[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.

Thank you, I love my design.

I think I know where you are venting from. Asking the user to not give a
widget a capability outside of its Apartment is totally reasonable and in
sync with your own work. I just like saying the work moron now and again.

>
>
>>>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 suppose the debugee should send the current scope to the debugger at the
breakpoint and then wait for a ping from the debugger. The debugger pings
the debugee whenever it feels like it.

This isn't a situation where you're sharing access to a common resource.
It's more a matter of inter-thread communication.

>
>
>>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.

Your a smart alec aren't you. See my reply to your reply to my reply.

>
>
>>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.

Well, I've only got a start so far, but I can see why your interested in it.

Thanks for sharing the knowledge.

ciao,
Tyler