Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CS.WASHINGTON.EDU!wgg
From: wgg@CS.WASHINGTON.EDU (William Griswold)
Newsgroups: comp.lang.icon
Subject: Re:  type coercion
Message-ID: <9004121824.AA15180@june.cs.washington.edu>
Date: 12 Apr 90 18:24:22 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 39

>
>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