Re: Functional Language with Processes
- Curses! I thought that space was public just because the server
said so! Why didn't I test it?
OK, for now, let's try
I have to pick a better web space to publish in.
- On Sun, 1 Feb 2004 06:31 am, Jack Waugh wrote:
> How would you like a language characterized by the operations IWhat is the rationale for having copyable and non-copyable data types?
> describe in
> ? If you can't understand my (quite abbreviated) presentation,
> please pose questions for clarification.
> What is the rationale for having copyable and non-copyable datatypes?
One can't so much as calculate factorial without copying a number.
The question becomes, then, what is the rationale for having non-
copyable data types.
You definitely cannot copy an oracle. The thing I call an "oracle"
is really (or contains, among other things) an infinite tree of what
I'll call "primitive oracles". Primitive oracles are what other
writers call oracles (e. g., in the Fudgets paper). Each primitive
oracle "knows" the outcome of one race. The primitive oracle is
going to be used where that race ends, so you have referential
transparency. If you had a "function" that returned, say, a list of
its two arguments, and their order in the list were supposed to be
the order the arguments were available, the "function" wouldn't be a
true function because its results don't depend wholly on the
arguments. But if the function also took a primitive oracle,
referential transparency would be restored because we can pretend
that the primitive oracle knows which of the other inputs will be
available first. If you copied the oracle and used it in two of
these function applications, the copies would have to be predicting
the same thing as to whether the first argument or the second
argument were going to be available first. But that might conflict
with reality. So you can't go around copying primitive oracles.
And one of my composite oracles is a tree of primitive oracles and
if you copied the tree you'd be copying all the primitive oracles.
Process handles conceptually contain oracles, so they can't be
By the way, I currently have some design issues with the language.
One is that I realized I have not made sure that every process
handle gets drained. They can be destroyed by being acquaintences
of a process (that is, being in the state of a process) after the
handles to that process are all drained. I haven't provided for a
process to be informed when it has becomes garbage (a "finalization"
path), which could be designed by the programmer to drain any
uncopyable arcs. A possible solution for this problem is to say
that the initial behavior of a process gets attached to the
process's handles not on the input end of the graph of message
sends, but on the output end at draining. This would imply that
instead of an operator to split handles, there would be one to join
Another issue is oracles may be an unnecessary complication. I came
across a reference to a paper that is said to explain a way to get
nondeterministic behavior in a pure functional language without
oracles. It has something to do with a set type, where each set is
represented by a single element. I can't find the paper online;
have to look for it in dead-tree format at my nearest university
library where they have computer science. The reference is John
Hughes and John O'Donnell, "Expressing and Reasoning about Non-
deterministc Functional Programs", in proceedings of the 1989
Glasgow workshop on Functionl Programming, pages 308 through 328.
A final issue is how do I assure that someone doesn't stuff a
noncopyable value into a method and then copy the method? I suspect
static typing of noncopyable vs. copyable data may make sense, while
keeping dynamic typing of types within each of those categories. I
like the dynamic typing in Smalltalk and Self.
Error handling in general is a question; I have been thinking it can
be done with an operation, via oracles, that given some graph would
try to evaluate it but wrap the result in something that says OK or
error. In the case of error, a diagnostic would be nice; that could
be contained in the error value.