Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ucbvax!CS.ARIZONA.EDU!kwalker
From: kwalker@CS.ARIZONA.EDU ("Kenneth Walker")
Newsgroups: comp.lang.icon
Subject: Re:  type coercion
Message-ID: <9004121514.AA25491@megaron.cs.arizona.edu>
Date: 12 Apr 90 15:14:52 GMT
References: <9004111306.AA07853@sophist.uchicago.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 83

> Date: 11 Apr 90 10:22:29 GMT
> From: zaphod.mps.ohio-state.edu!usc!samsung!munnari.oz.au!bruce!alanf@tut.cis.ohio-state.EDU
> 
>Static type checking is not realistically possible for a language such as Icon.
> Consider the expression:
> 	if x=0 then "small" else 1
> The type of this expression may be impossible to determine until run time.
>   ...
> Perhaps what you need is some kind of "lint" program like that
> which the C programming language has.  For programs which can be statically
> typed it could warn of any type clashes and coercions that will occur, for
> other programs it could just indicate that static type checking was not
> feasible.

It is possible to perform type inference on Icon programs. Type
inference assigns a type to each expression, but some types may be
of a form like "string or integer", as in the example. In addition
to assigning types which an expression might actually produce,
it is sometimes necessary for a type inferencing scheme to make
conservative estimates, so the assigned type may include types which
the expression would never take on in any possible execution. A
compiler can use information from type inferencing to eliminate
much of the run-time type checking from a program, improving
execution speed.

I implemented a prototype type inferencing scheme some time ago
and was able to infer unique types for about 90 percent of all
operands where type checking is normally needed. I am preparing
to implement a type inferencing scheme in an experimental
optimizing compiler for Icon. It will be interesting to see what
kind of speedups result from using the type information in the
code generator.

> Date: Wed, 11 Apr 90 08:06:19 CDT
> From: Richard Goerwitz <goer@sophist.uchicago.EDU>
> 
> What I wonder is whether a thing like optional
> static typing might be applied to variables, and not expressions. 

This seems like a nice idea. Adding optional type information to
declarations is quite easily. You could do something like

   local x:integer, y: string | record r

x could then be assigned only integers and y could be assigned only
strings or records of type r. Variables with no type information
would simply be "any type", allowing the current style of typeless
variables to still be used. This scheme would require some run-time
type checking at assignments (and type coercions?), but that is not
a serious problem, though it might take some thought as to how to
implement it efficiently. This scheme effectively moves type
checking from the uses of a variable to the assignments, but 
run-time checking at assignments is only needed when the type
of the value being assigned cannot be statically determined.

I would also like to be able to have a declaration like

   global x: list of integer

This means that any list assigned to x must be restricted to contain
only integers. It would be necessary to have some way of creating
type-restricted structures. Ideally the method would be a simple
extension of the current methods for creating structures.

You probably also want a way of creating named types.

   type foo: list of (integer | foo)
   global x: foo

Type equivalence would be structural. In the following example, x and
y have the same type.

   type str_set: set of string
   local x: str_set
   local y: set of string
   
   x := y

Does anyone know how this compares to other languages with flexible
type systems? Are there pitfalls I haven't anticipated?

  Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  +1 602 621 2858  kwalker@cs.arizona.edu {uunet|allegra|noao}!arizona!kwalker