[Types-sig] lambdas, classes, tuples, default arguments, map

Tony Lownds Tony Lownds <tony@metanet.com>
Thu, 20 Jan 2000 20:46:37 -0800 (PST)


Here is my 2 cents on the proposal, which looks really good to me overall.

1. Requiring a return type on typed lambdas could help disambiguate

decl f_pair: def((any,any)) -> any
decl f_2: def(any,any) -> any
f_2 = lambda x,y: ...		# ok
f_pair = lambda (x,y): ...	# ok
f_2 = lambda (x,y)->any: ...	# ok
f_pair = lambda ((x,y))->any: ...	#ok

2. The way I read the proposal, class definitions themselves are valid if
each assignment made in the class suite is valid wrt its bases. You can
use a class as a type in a decl. Type checks involving such a decl only
look at inheritence, not structure. I'm guessing there would be some kind
of fundamental base class for the special python methods - __len__ etc.
__init__ would have to be treated a bit specially, because subclasses'
constructors are usually incompatible with superclass' constructors.
Is this right? And can one specify that a subclass' constructor should
indeed be compatible with a superclass' init? 

3. On the How to spell a tuple issue - the proposal mentions (str*), how
about (*str)...

decl def f(*args:(*str)) -> int

4. How do you specify default values for parameters in decls? The simple
answer is to use "= value" 

decl def foo(a: int, b: int|None = None) -> int

But for cases where the default is a complicated object thats going to be
a problem. 

5. map has a function signature that is pretty hard to declare, even with
parameterization of functions. I hope it will be special-cased rather than