Re: Idle musings on doing E over again

Paul raised the question of an ocap version of Scala about a month and
a half ago. Here's a very late reply with some thoughts on that.

Here are two overall strategies to keep in mind:

1. Use a compiler plugin to restrict the language to what is allowed.
This is one of the two places where a compiler plugin shines (the
other one being to refine the type system).

2. Start with Joe-E, modified for the Scala syntax. That will already
be a very reasonable language, and you could work out from there,
adding one restricted feature at a time after you analyze it for
ambient authority.


Here are some thoughts on the language itself:

1. It looks valuable to restrict case classes be real data holders, at
least unless they have some kind of @Unsafe annotation on them (do
other ocap variants have such an escape hatch?). I recall there was
some exploration in E of various kinds of frozen and transparent
data-holder objects. Similar things can be done in Scala-E by
restricting case classes: no mutable vars, no non-sealed non-final
classes, no overriding of compiler-generated methods such as equals().

2. The general nesting in Scala is likely to be helpful. When I tried
to make an ocap version of Smalltalk, I foundered on the inability to
put classes inside methods.

3. Scala has good concurrency primitives in its "Akka" framework,
including message passing and promises. Definitely mine out as much of
Akka as will make sense, so as to make Scala-E fit better in the
existing Scala ecosystem.

4. The type system can help! Upcasting and downcasting can potentially
be used like seal and unseal. Upcast is seal, downcast is unseal. So
long as the subclass is local and/or private, it is possible to
control what code can do the downcast, and thus what code can unseal
the treasure box and access what's inside.


Lex Spoon