goer@SOPHIST.UCHICAGO.EDU (Richard Goerwitz) (04/11/90)
Consider the following:
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. In Icon as well as such expressions as these it is
possible to check the type of a value at run time and act according
to this information. I have used this myself to obtain the
behaviour of variant types. For example:
if type(x)=="integer" then x+1 else 0
Expressions such as this are quite foreign to languages with static
type checking. 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.
I don't disagree that expressions such as this are foreign to languages
with static type checking. What I wonder is whether a thing like optional
static typing might be applied to variables, and not expressions. In
this scenario,
if x = 0 then "small" else 1
would be fine.
Just curious.
-Richard L. Goerwitz goer%sophist@uchicago.bitnet
goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goerkwalker@CS.ARIZONA.EDU ("Kenneth Walker") (04/12/90)
> 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
wgg@CS.WASHINGTON.EDU (William Griswold) (04/13/90)
> >Does anyone know how this compares to other languages with flexible >type systems? Are there pitfalls I haven't anticipated? > The problem that I can anticipate right off is that structural equivalence when only some variables are typed could be expensive, unless you do some precomputation and type inference. For example if you have the declaration: local L : list of list of table of (integer | real) What will you have to do to check an assignment to L coming from an untyped variable. What about assignments to any of its subcomponents? Are pointers to substructures of L a problem? Also, suppose you wanted to allow for typed recursive structures (there is plenty of evidence that you want truly self-referencing structures in Icon): type tree-node : list of (integer | tree-node) Is this hard to type check? Seems no harder than the above, but again, how does one check modifications to substructures with pointers running around? Also, what if it isn't a tree, i.e., you have a loop? Structures would probably have to be marked during the traversal of the check. Name equivalence would make the checking easier, but it would be far too restrictive and meaningless in Icon. I'm not knocking the idea of this flexible typing. I would *love* to have it. But I see some (interesting!) problems when only some of the objects are typed. I think the feature could be very useful during development, because it allows the gradual introduction of types where needed for testing, and they can be ``turned off'' after development if they cost too much to check all the time. Bill Griswold