[Types-sig] parameterized typing

Greg Stein gstein@lyra.org
Tue, 21 Dec 1999 11:21:43 -0800 (PST)


On Sun, 19 Dec 1999, Paul Prescod wrote:
> Greg Stein wrote:
> > ....
> > Paul: does this sufficiently address your desire for parameterized types?
> > Others: how does this look? It seems quite Pythonic to me, and is a basic
> > extension of previous discussions (and to my thoughts of the design).
> 
> Without thinking every detail through it looks good to me for handling
> parameterized classes. I think that parameterized typedecls and
> functions are still an issue.

True.

> Also, was it your intent that the _ be required or would the fact that
> the param was declared obviate that. I am thinking that there may a more
> general syntax that allows us to parameterize various sorts of things.

The "_" was just following Tim's lead. Certainly, there shouldn't be a
requirement. Maybe not even a convention (e.g. "self" is a convention
rather than a requirement).

I kind of like the leading underscore as it differentiates the param from
regular arguments.

> interface (a,b) foo: ...
> class (a, b) foo: ...
> def (a, b) foo(a) -> b:
> decl foo(a,b) = typedef ...

This has possibilities.

Remember, though: I believe that parameterization is only useful for the
type-checker. The Python runtime doesn't need it. In other words, our
basis for choosing to do parameterization is based solely on a need for
type checking. Is that need sufficient?

I'm on the fence with parameterization altogether. The problem is that I'm
not sure we can defer this one to a second phase because the type
declarator syntax will probably be affected dramatically by the
requirement for parameterization. i.e. we have to design it now to get the
long-term type decl syntax correct :-(

So: your idea for parameterization is nice, but I'd like to understand
whether there is a strong feeling for having it in the first place.
(before spending a lot of brain-cycles on the issue)

Cheers,
-g

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