🚀 go-pugleaf

liberte@ncsa.uiuc.edu (Daniel LaLiberte) writes:

 >I am also interested in the various ways languages that support
 >*optional* static typing limit the extent of static typing one can do,
 >and why.  First of all which languages support optional static typing?

There is an experimental language called AMBER designed by Luca
Cardelli, AT&T. (Cardelli signs also for the MODULA-3 Type System).

AMBER supports this kind of record inclusion polymorphism, i.e.
having a record r={a: Int, b: Int} then both the records r1={a: Int}
and r2={b: Int} are implicitely supertypes of r, i.e. every function
accepting r1 resp. r2 accepts also objects of type r.

AMBER is weak functional like Standard ML, i.e. it supports assignments
but updatable objects have to be typed appropriate.

The point now according to your question is that AMBER has a type
"Dynamic". Every value can be made dynamic using the expression
"dynamic e", where e is an expression. The statically known type
information belonging to e is paired with the value of e, resulting
in an entity of type Dynamic. Dynamic values can be coerced back
to a known type using the expression "coerce e to t" which 
produces a run-time error if e has not type t. There are also
possibilities to inspect the type of dynamic values: there is
a type "Type" and a function "typeOf: Dynamic -> Type" for this
purpose. Objects of type Type are descriptions of the
type information usally known to a compiler.

The introduction of dynamic types of this kind seem to cause no
extraordinary problems in a primarily statically typed environment. 
Run-time type errors are limited to the construction "coerce e to t".
Its a matter of taste to call AMBER dynamically typed since such
run-time errors may occure at all.

AMBER has been implemented for the Mac, but dont ask me where to
get this implementation and the language description. Probably there 
is a FTP side anywhere.

--
Wolfgang Grieskamp 
wg@opal.cs.tu-berlin.de tub!tubopal!wg wg%opal@DB0TUI11.BITNET