On Fri, 2005-07-01 at 21:53 +0700, Constantine Plotnikov wrote:
> "Statefull interface" also contradict other usages of word
> "interface". "Stateful" is an implementation property. I was not happy
> with stateful modules either, but I'm still waiting for memory model
> specification before I can comment on the issue.
I was hoping that MarkM would respond to this, but since he has not...
Let me try to provide a rationale for statefull-interface, but let me
begin by saying that I also have mixed feelings. I agree that
statefullness is an implementation property. The reason that we have the
distinction between statefull-interface and interface is to encourage
programming in a more secure idiom. It really has very little to do with
the memory model specification.
The origins of "interface" vs. "statefull-interface" come from the E
programming language. In E, the key idea may be stated as follows:
Communication between subsystems should arise only as the result
of introduction. The mere fact that two compilation units A and
B both import a third compilation unit C should NOT imply that
there is now a communication path between A and B.
E does not permit the declaration of top-level mutable objects, and E
does not have mutable "class variables". E permits only the declaration
of constants. If you want two objects to be able to communicate, the
piece of code that instantiates those two objects must provide one with
a pointer to the other.
So state sharing is possible, but the language deliberately introduces a
situation where it takes extra effort.
Contrast this with Java, where global mutable state is straightforward.
Because shared mutable state is the programming idiom that everyone has
been trained to use, people actually DO use these features, with the
consequence that Java class libraries are generally unsecurable.
In a perfect world, BitC would have simply adopted the E position, and
the distinction between INTERFACE and STATEFULL-INTERFACE would not
arise.
Unfortunately, there are a small number of critical programs that will
be written in BitC that are intensively statefull -- most notably the
Coyotos kernel. We have not been able to discover a practically
effective way of expressing these programs in deeply non mutating form,
so we cannot take quite the pure position that E has taken. Instead, we
are attempting to take a position where both the developer and the user
of statefull code is explicitly aware of the possibility that importing
a statefull model may introduce a shared communication path.
So:
In BitC, importing an INTERFACE is guaranteed NOT to introduce a new
communication path. Importing a STATEFULL-INTERFACE *may* introduce a
new communication path. We hope very strongly that STATEFULL-INTERFACE
will *not* become the common idiom.
This is a (relatively small) experiment. If it doesn't work, we can
remove the excess baggage pretty easily with fairly minimal disruption.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
