[Types-sig] Re: Pascal style declarations

[Greg Stein]

On Tue, 14 Dec 1999, Golden, Howard wrote:
>...
> I'll admit that Python already uses the ":" character where Pascal does, but
> so what?  You can still specify the return type in other ways.  The most
> obvious (to me) is to use the ":" character twice, e.g.,
> 
>     def funx(x : int, y : string): int : ...
> 
> While I'm not a parsing expert, I believe this would still be parsable.  Of

It isn't "easily" parsable :-)

"int" is a valid expression, which is valid on the same line after a
function definition. For example:

  def funx(x, y): foo() ; return 5

The parser wouldn't know whether the expression is part of the function
body or a return type declaration until hitting the ':'. That would
require an arbitrary look-ahead or some funkiness in the grammar.

> course, any other available character could be used instead of the ":", if
> this would be preferable.  (Again, I'm not trying to dictate the final
> syntax, just suggest a starting point.)

Yes, another character would be used. But which? What construct looks
Pythonic? I don't disagree with the basic notion here... just that it is
tough to retain Python's clean feel.

While we didn't necessarily like the '!' choice for the operator, we felt
that the basic concept imposed very little change on Python's clean feel.

> > This was one reason that Fred/Sjoerd/myself moved away from ':'-based
> > declarations, and eventually fell into expression-based type checking.
> 
> I am suggesting using declarations, rather than expression-based type
> checking, since that is familiar in other languages.  As a declaration, it
> is clear that I am talking about an invariant assertion, not a dynamic one.

As I've mentioned in my other email, expression-based checkin also defines
an invariant. The compiler can make assumptions based on type declarators
in a function or when it sees a type-assert operator.

> Expression-based type checking should also be available, since it is needed
> when static checking is impossible.  I don't think it has to be either/or.

We already have expr-based (the "assert" statement) -- we can assert types
on expressions anywhere. It is just a little less convenient since we must
place the expression value into a temporary variable, assert the type of
that, then continue with the expression. The "type-assert operator"
simplifies this process dramatically.

Cheers,
-g

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