[Types-sig] updated proposal (fwd)

[Greg Stein]

Great comments. Thanx for the feedback.

I made a few more updates just recently (a new section on typedefs and
added some notes to sections that need some updates). I've checked into
CVS, so future changes can be more easily tracked -- you won't need to
re-read the whole doc looking for changes :-)

I'll send out CVS info later...  Later is now... look at the bottom of the
document. There is a link to an online viewer that can display changes.

The URL again: http://www.lyra.org/greg/python/typesys/type-proposal.html

Now to the comments:

I've recorded some of your thoughts in the proposal. Take a look to ensure
that I've properly specified your position.

On Tue, 4 Jan 2000, scott wrote:
>...
> """
> I propose the the use of the __interfaces__ attribute, although Jim Fulton's
> Scarecrow Proposal uses the __implements__ attribute, so that may be the
> preferred attribute. 
> """
> 
> I like __interfaces__ better too.

Noted in the document.

> what operator to use as type-assert operator:  
> 
> I prefer 'isa' or 'asa'.  If I still used emacs, I'd _hate_ to have to
> wait for python-mode.el to catch up to understanding the colons in
> type-assert operators, short of that, I prefer the colon, it looks
> familiar.

I don't think that anybody has suggested using the colon for the
*operator*. It is grammatically ambiguous.

Could you clarify your position, and I'll mark the tally in the proposal.
Thx.

> In compile-time changes, you wrote:
> """
> Check that the left-hand side of a type-assert operator may sometimes
> succeed. If it can never succeed, then an error is flagged. 
> """
> 
> Is there any way (ie restrictions on variable name usage, etc) to make
> this more strict?  I'd much prefer that it be able to check that the left
> hand side of a type assert operator must succeed and follow some
> reasonable guidelines to make it do so than have this whole category
> made so wisshy-washy at compile time.

Given the following code:

  decl a: Int
  b = a ! String

The compiler will know that it will always fail. So it can flag it. In the
following:

  decl a: Any
  b = a ! String

It has no idea. So it lets it pass, to be evaluated at runtime. The
operator *is* a runtime operator. The reason it is important to the
compile-time checker, however, is that the checker now knows that "b" is a
String. It cannot be anything else (or the exception would prevent the
assignment).

I'm not sure this could be called "wishy washy". I definitely should
document the operator better in the proposal. I've left myself a TODO for
this. If there is still something wishy-washy about it, then please
clarify so that I can address the issue.

> regarding a new namespace to place interface/type info into... I'd
> suggest leaving that open for the time being, or just defining that
> access is available at runtime via a function call such as:
> 
> 	interfaces() -> [ all known interfaces in current namespace ]
> 	interfaces(x: Any) -> [ all known interfaces that x implements ]
> 
> this would allow 'implementors' to put the darn info wherever they
> want and define a flexible enough interface to getting the interfaces
> to allow for variable underlying implementations.  (sorry for
> mouthful...) 

Interesting thought, but I feel confident that we don't need another
namespace, so I don't really see a reason to make the above compromise.

I've noted this idea in my document.

> Re: 'associating interfaces with a module':  I don't see any reason to
> define interfaces so that modules can't have them:  python is good at
> module-level interfaces, I use them more frequently than I've seen
> others do (don't like big files, no matter what editor or tags stuff
> I'm using).

I've recorded this as a tally.

> Re:
> """
> I am unsure whether interfaces should include the notion of class
> versus instance attributes, or whether separate interfaces should be
> defined and used. If
> separate interfaces are to be used, then we would probably want a
> __class_interfaces__ attribute to list the interface(s) that the class
> object conforms to. 
> """
> 
> Ouch, I like to KISS, an interface is an interface is an interface...
> if the definition of it isn't good enough, then we better make it
> better (ie make the notion of interface understand class vs instance
> variables because they're different and both contribute to an
> interface).

I'm inclined to agree. Noted in the doc.

> There should be interfaces for all objects, and those we can't make
> right off the bat we should try to make sure we don't put off in such
> a way that they will become unduly tricky down the road. I think this
> is a key concept we should strive for... in the long run, all built-in
> objects should have a set of interfaces, and those interfaces should
> be defined in terms of atomic (resolved) types wherever possible.

Agreed.

I've been thinking about this quite a bit, so that I can add more code to
the type checker to properly deal with operators (e.g. addition). Let's
say you have the following interface:

  interface Foo:
    decl member __add__: def(self:Foo, value:Foo)->Foo

Class instances supporting the Foo interface are capable of being added.
They *also* have an "__add__" attribute.

Consider a builtin type: it can be added, but it does not have an
"__add__" attribute. How do we resolve this? I believe we do it this way:

  interface Int:
    decl intrinsic __add__: def(self:Int, value:Int)->Int

This tells the checker that Int understands addition, but it does NOT
actually have an __add__ attribute.

Thoughts?

> re:
> """
> The change to varargslist allows a lambda's arguments to have type
> declarators. I haven't thought this fully through, but is this
> entirely necessary?
>       Do we need to actually type-check those? Lambdas are typically
>       not used in cross-unit interfaces where the type checking is
>       most needed. 
> """
> I say trash 'm if there really a problem grammatically.  We can still
> do the same with nested defs, which are generally more efficient
> given the choice of doing either anyway.

Vote tallied.

> re:
> """
> One other possible syntax change would be to introduce an interface
> keyword. This would lexically replace the class keyword in Python
> code, and its body
> would be similar to a class body except that attributes could be
> declared but not assigned and functions could have doc strings, but no
> code body. I'm not sure that
> this buys us anything over just using a regular class and adhering to
> those rules. 
> """
> 
> I like the interface keyword, even if it only happens inside a decl
> statement so it won't have to be a keyword:  the reason is that I can
> see it being much simpler to name interfaces and classes the same
> thing in many cases where ``KlassInterface'' would just jumble up the
> namespace with two different names.  Basically, I'd like the ability
> to follow C-style declarations here where you can name interfaces the
> same thing as the actual thing, and I think that should extend to
> classes.  It would help to tighten the bond between the frequent 1-1
> relationship between interfaces and classes.

C/C++ has distinct namespaces for certain names. That option isn't really
available to Python. When a name is used, it resolves to a particular
object. Within an ordered set of namespaces (local, global, builtins), 
name resolution is context independent. A name in an expression is the
same as one in a function argument.

I don't think that we can provide for an interface and a class to share a
name.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/