[Types-sig] A late entry

John Viega John@list.org
Fri, 17 Mar 2000 17:26:08 -0800


On Thu, Mar 16, 2000 at 05:51:08PM -0500, scott wrote:
> On Thu, Mar 16, 2000 at 02:00:56PM -0800, John Viega wrote:
> 
> I'm not saying anything forces an OR construct, or even that one is a
> good idea.  I'm just trying to get the implications straight.  One of
> the implications of treating the type of None as a principal type is
> that a static type checker will be able to say "hey x might be None,
> but you're assuming it's a string!"  in code like the following:
> 
> x = {'foo': 'bar'}.get('baz')
> x = x + ''
> 
> That's a good thing, and allowing the type of x to be 'None | string'
> combined with the necessity of typecasing the result is one way of
> having a static type system understand this error.

It's one way.  Most languages don't find the problem worth fixing
statically, of course.  There's another, more natural way of modeling
the problem that does allow for static checking of this sort of thing.
Basically, for each object type, you have a second type which is
identical, with the exception that it can never hold null.  In your
above example, we'd then be able to give a type warning in the above
case.  The problem there is that you have to explicitly typecase (or
typecast) every time you make a call to get() and get back a valid
result.

No languages bother here.  Most languages just do an analysis, and try
to figure out which uses might perform illegal operations on the void
value, giving errors at only those points.  That kind of analysis can
be done statically, and leverages the type system, even though it
doesn't have any obvious manifestations in the syntax.


> > I got confused here for a second... this looks too much like an actual
> > tuple use for me. :) Whatever syntax ends up getting used, can we use
> > (x*y*z) to refer to the 3-tuple where arg 0 is of type x, 1 of y and 2
> > of z?  That's a very common notation.
> 
> hmm.  I don't want to get into syntax wars.  I'll use whatever syntax
> you like for this discussion.  The reason I used the above syntax is
> that it was proposed and used lots in previous discussions.  


I'm not so much concerned about the final syntax... I just got
confused seeing something that looked like a tuple, and not a type :)

> > Well, you're going to want to keep complete type information around
> > for the runtime to use anyway, so that doesn't really matter.
> 
> yikes.  I was hoping to avoid that, as it implies a major leap in
> difficulty.  It also seems like making this info available at runtime
> may imply that a static type system isn't really feasible until
> PY3000, which is a little disappointing.  We'll see, I guess :)

Why is that?  I don't see a major leap in difficulty myself...

> > There's been some work done in this area, but nothing that had
> > actually been implemented last I checked.  Why is it necessary? 
> 
> I'm just trying to understand the options, I don't have the knowledge
> to rule a whole lot of things out at this point, and I feel the need
> to understand things well enough to make those calls for myself.

Fair enough.

> >What
> > do you have against a poly catcall rule?
> 
> Nothing except that I don't know enough about it yet.  Just found a
> good description at
> http://www.eiffel.com/doc/manuals/technology/typing/paper/page.html
> 
> like I said before, I need to set aside more time to read!

Now that I'm thinking about it, another good thing to read is Meyer's
chapter on types in "Object-Oriented Software Construction" 2nd ed.

John