[Types-sig] A late entry

[scott]

On Thu, Mar 16, 2000 at 02:00:56PM -0800, John Viega wrote:
> On Thu, Mar 16, 2000 at 04:06:12PM -0500, scott wrote:
> > On Thu, Mar 16, 2000 at 11:24:19AM -0800, John Viega wrote:

> > The way I read what you say below, we're actually agreeing about
> > having a special type for the value None, it seems to work best to me
> > as a valid value in the set of values of any object type.  That's what
> > I meant by 'something like a null type' above.  By doing this, you
> > lose the ability of a type checker to distinguish when something
> > should be None and when it should not, but this approach makes lots of
> > things easier both for the programmer and the implementation of a
> > static type system.
> 
> No, most languages have a rule that variables cannot have the void
> type as their principal type.  This is no reason to allow OR-ing of
> types.  Note how it isn't an issue in pretty much every other
> language, either.  So I still don't see what you are seeing that
> forces an OR construct.

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.

But, as you argue, there are lots of tradeoffs to consider with
allowing OR's.  I personally don't think that it's worth it to
introduce OR's for cases like this (I used to, but trying to build a
static type system with this construct made me change my mind).  The
idea does have it's proponents, so it's definitely worth mentioning
that there is a tradeoff to be considered.

> > This seems like a good approach, and if None is treated specially as
> > above, then recursive types such as:
> > 
> > typedef IntTree (IntTree, int, IntTree)
> > 
> > aren't a problem either (atleast in terms of the need for OR).
> 
> 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.  

[...]
> 
> > > Well, any time you have to dynamically cast there's going to be a
> > > performance hit.  I'm not really worried about matching, though.  You
> > > can do it fairly efficiently, plus it satisfies the principal of
> > > localized cost... the feature costs the programmer nothing unless he
> > > uses it.  
> > 
> > This is true so long as extra information isn't carried around and
> > kept up to date at run time in order to make matching more efficient. 
> 
> 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 :)


> > > To get it right, you would essentially be doing the same thing that
> > > the global validity approach does.  In particular, you have the exact
> > > same problems in that a "closed world" assumption is required.
> > > Incremental checking is far more useful, and I think that the
> > > polymorphic catcall rule is simple enough (though not if you call it
> > > "polymorphic catcall" when you report an error to the end user!).
> > 
> > I'll look into that more, as well as potential means for making the
> > global validity approach work more incrementally.
> 
> 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.

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

scott