|
|
|
|
|
New for 4th Edition
|
|
We are considering the following changes to Limbo:
- Buffered channels
An application would be able to allocate chan [N] of ....
This is mainly intended to improve throughput by reducing
context switching in some specialised applications, but there are other
applications. For instance,
if the reply channels in file2chan were chan[1], a server
could reply without fuss even if the client had vanished.
Status:Done
- Allow many alts to be ready to send or receive on the same channel simultaneously
This change would remove an old implementation restriction.
The restriction is annoying because it
reduces modularity: for a process to alt on a channel shared
with a module it must currently make assumptions how that module's implementation uses it internally.
Status:Done
- Constrained parametric polymorphism(!).
The programming language CLU first devised this approach to making
functions (and types) independent of the types with which they are
instantiated. Types and functions can have type parameters, but each
type parameter is constrained by a set of operations (functions) that
any type that is an actual parameter must satisfy. This allows type
checking to be done statically, and any instantiation of a
parametrised type can be checked independently of its implementation.
The details for Limbo are closest to the way
that the scheme originally used in CLU was adopted and further refined
in the Theta database programming language. That is, in Limbo terms,
adt types, member functions, and module-level functions can be
parametrised by constrained types. Unlike CLU and Theta, there can be
more than one implementation of a parametrised type in use at once,
since their implementations appear in Limbo modules.
Here is an example (without constraining the underlying type), of
a general function to reverse a list of any reference type,
returning a list of the same type as the parameter:
rev[T](l: list of T): list of T
{
n: list of T;
for(; l != nil; l = tl l)
n = hd l :: n;
return n;
}
The above generates precisely the same code as is generated if T
were replaced by `string', but can reverse lists of strings, lists
of arrays, etc.
To call it, simply write rev(alist) for alist of any suitable list type;
the compiler does type unification so there is no need to parametrise the call
(eg, we do not write rev[string](stringlist)).
Status:
Initial implementation complete for experiment
22 May 2003
|
|
|
