[Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it.

[Jeremy Hylton]

>>>>> "PP" == Paul  <prescod@prescod.net> writes:

  PP> On Fri, 3 Dec 1999, Jeremy Hylton wrote:
  >>  If you're going to develop a static type system to describe
  >> Python programs (optional or otherwise), then I think you can't
  >> punt on all the things you want to punt on.

  PP> Forever, no? For a first draft? Yes. Type systems can be
  PP> extensible. C didn't forsee objects but C++ added them and C++
  PP> doesn't support parameterized types (at first) but added those
  PP> two.

And Java didn't support them at first, but lots of people gripe about
it and several people have proposed solutions.  If we learn a lesson
from C++ and Java here, it is that parameterized types are an
important part of the type system.

  PP> I'm always torn on these design issues between trying to get it
  PP> all right the first time and doing it incrementally. There are
  PP> big risks either way but insofar as we never get anywhere when
  PP> we try to do it all at once...that seems like the bigger risk.

I think I see where you're coming from now.  I might agree that some
of the issues (e.g. parameterized types) aren't important for the
first draft.  They will need to be added at some point before the work
is complete, so that SIG charter shouldn't specifically exclude them.

Bill Janssen made a different and good suggestion about what the
product of the SIG would be:  a specification and a mechanism to type
check the use of a module.

A potentially interesting variant of that is to type-check the use of
Java object by JPython programs.  Which is one reason why I think
interfaces, for example, need to be part of the type system.

  BJ> Note that, contrary to Jeremy's assertion, this doesn't
  BJ> explicitly mention interfaces, and doesn't necessarily involve
  BJ> them.  Of course, defining a module always implicitly defines an
  BJ> interface, so one could argue that interfaces are always a
  BJ> factor. 

We want to be able to say something like: "Method expects a file-like
object as its second argument."  Specifying "file-like object"
requires something like an interface.

[tangent?] I've looked very briefly at MzScheme, a Scheme
implementation done by the PLT group at Rice.  It supports objects and
interfaces, and units (modules) and signatures.  At first glance, it
appears to be a carefully thought-out way to add type checking to an
object-oriented, dynamically-typed language.

Jeremy