[Types-sig] New syntax?

[Tim Peters]

[Martijn Faassen]
> I think inline type declarations like def(Int, Int)->Int may not
> be necessary if you allow typedefs.

I like typedefs fine too, but couldn't make sense of a system in which a
typedef was *essential* for spelling a concept.  typedefs are traditionally
shorthands for things that may be (at worst) clumsy to spell without them.

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

Hmm.  These have nothing in common with lambdas apart from having an
argument list -- as do all functions and methods.  Indeed, from the type
expression

    def(Int) -> Int

we have no clue whether it's *defined* via a lambda or def.  And the
declaration should not expose that, so all is well (strictly, the word
"lambda" makes marginally more sense than "def" in the above, but I don't
want to encourage a lambda mindset <wink>).

> typedef Footype(int, int):
>     return int
>
> var handlermap = {string: Footype}

If I had a lot of binary integer functions to declare, I would probably use
a typedef, a la

    decl typedef BinaryFunc(_T) = def(_T, _T) -> _T
    decl typedef BinaryIntFunc = BinaryFunc(Int)
    ...
    decl var intHandlerMap: {string: BinaryIntFunc}
    decl var floatHandlerMap: {string: BinaryFunc(Float)}

etc.  The "deep" problem I have with your "Pythonic" notations is that while
Python excels at expressing imperative algorithms, type specification is a
purely declarative task.  Type *expressions* allow for a convenient, precise
and concise calculus of type-specification "equations".  As in the above
example, the common parts of common patterns can be factored out and resued
with ease.  This is useful!

You're not going to get the same level of expressiveness in an
imperative-style Python syntax:  it's the right tool for the wrong job.  A
type-expression sublanguage with one operator ("|") should suffice.

[on varargs]
> Me neither. Perhaps something like:
>
> decldef foo(first=int, second=string, *[int]):
>     return int
>
> i.e. all the extra arguments must be ints.

Hmm!  You and Greg both seem to think varargs get implemented as lists
<wink>.

> Note that I'm currently in the out-of-line camp with Paul. :)

Aren't we all?  This has been an intense week for the Types-SIG!  The good
news is that Paul must be taking most of it out on his family & not us
<wink>.

i-asked-sinterklaas-and-we're-*all*-getting-nice-presents-ly y'rs  - tim