[Types-sig] typedefs (was: New syntax?)

Greg Stein gstein@lyra.org
Fri, 17 Dec 1999 11:02:04 -0800 (PST)


On Fri, 17 Dec 1999, Martijn Faassen wrote:
> Tim Peters wrote:
> > [GregS]
> > > ...
> > > In fact, I don't even like Tim's notion of declaring a function since a
> > > "def" is more than adequate for doing that.
> > 
> > I thought it would be easier to get one new stmt than to modify existing
> > stmts, and *much* easier to write a dirt-simple tool to strip them out again
> > (vis a vis Guido's requirement).
> > 
> > In real life I would certainly prefer annotating "def" stmts directly.  I
> > think a declaration statement needs the *ability* to specify full function
> > signatures, though; e.g.,
> > 
> > decl handlerMap: {String: def(Int, Int)->Int}
> > 
> > handlerMap = {"+": lambda x, y: x+y,
> >               "*": lambda x, y: x*y,
> >               ...
> >              }
> 
> I think inline type declarations like def(Int, Int)->Int may not be necessary
> if you allow typedefs. People often give the advice to avoid Lambdas in Python
> anyway; why not avoid a lambda like construct in our type definition language
> as well?
> 
> typedef Footype(int, int):
>     return int
> 
> var handlermap = {string: Footype}

I see typedefs as a way to associate a typedecl with a name. In your
example here, I'm not sure how to do a typedef of something like
List<String>. You seem to have pegged typedef to only do function
typedefs.

Per the GFS proposal, I would recommend that "typedef" is a unary operator
keyword. The operand is a typedecl, in the form that we see to the right
of a "decl" statement. The result of the operator is a typedecl object.
This typedecl object can, of course, be used in further typedecl
constructions. For example:

HandlerMapType = typedef {String: def(Int, Int)->Int}
decl std_handlers: [HandlerMapType]

def foo(m: HandlerMapType)->Int:
  ...


In any case, I think using "def" inline to define a function typedecl is
fine. A typedef is merely used to create an alias, to clarify a later
declaration.

Cheers,
-g

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