[scott@chronis.pobox.com: Re: [Types-sig] updated proposal (fwd)]

[scott]

In my usual habbit, I forgot to address this to the list.

scott

----- Forwarded message from scott <scott@chronis.pobox.com> -----

Date: Wed, 5 Jan 2000 15:11:02 -0500
From: scott <scott@chronis.pobox.com>
To: Greg Stein <gstein@lyra.org>
Subject: Re: [Types-sig] updated proposal (fwd)
X-Mailer: Mutt 0.95.7i
In-Reply-To: <Pine.LNX.4.10.10001041950430.412-100000@nebula.lyra.org>

On Tue, Jan 04, 2000 at 08:26:35PM -0800, Greg Stein wrote:
> Great comments. Thanx for the feedback.

thanks for the code and web page :)

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

I was confused about what exactly was meant by type-assert operator.
Please disregard :)

[...]

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

how would it compromise anything about where type info is stored?

[...]

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

I like it.  nice easy way to add lots of interface info to built-in
objects.  One question, though Is there built-in functionality that
would be useful to consider as part of an interface that does not have
a corresponding '__magic__' object in python? I can't hink of any
off-hand, but it would seem prudent to pose the question.

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

hmm, i see the complication, and could live with this either way, but
I'm not convinced that there does not exist the possibilty of a way to
make interfaces and classes share names that is reasonable, just that
it's unlikely that one exists.  thanks for clarifying.

scott

----- End forwarded message -----