[Types-sig] Re: Static typing considered ... UGLY

[Greg Stein]

On Tue, 14 Dec 1999, Edward Welbourne wrote:
>...
> On the other hand, if you want an object whose attributes are of
> pre-decided kinds, or a namespace in which certain names are reserved
> for certain values, use a setattr hack (or, if you're feeling very
> brave, some variant on the wrapper defined by
> URL: http://www.chaos.org.uk/~eddy/dev/toy/class.py).

setattr hacks work great for class instances. Try to apply them to module
namespaces...

:-)

This is a pretty old request to Guido: provide a setattr hook for modules.

>...
>  ... I've now read the Greg/Fred/Sjoerd attack and I like that: let !
> be a new binary operator with grammar
> 
>    anyvalue ! typechecker
> 
> the value of the expression being that of the given value, but

Ah. Right. I didn't make that explicit, but yes.

> evaluating it'll raise an exception if the typechecker didn't like the
> value.  Now that's a much nicer way to go.  Of course, this effectively

Yes, and I think so, too :-)

> just amounts to implementing ! as an in-expression assert mechanism ...

Yup. The proposal doesn't even introduce new bytecodes... it could use the
same pattern as the assert statement, allowing the Python VM to optimize
it during a -O invocation.

> and I'm not entirely sure how it helps the compiler-writer - is that why
> you insist on the typechecker being a dotted name, not an arbitrary
> expression ?

Correct. The compiler is going to have a hard enough time with dotted
names, let alone arbitrary expressions.

The type assertions help the compiler because the compiler can then make
assumptions on how to *use* that value. For example:

  if x!Int:
    ...

If you compile this, then you know that you can do a simple integer test,
rather than check for an instance and possibly calling __nonzero__. While
no biggy for compiling to the Python VM, this is a *huge* win if you're
compiling to something like C or the JVM.

In the statement:

  a = 5!String

The compiler now knows that <a> will contain a string and can optimize the
uses of <a> as appropriate.

> Type-checking applies to values ;^)

:-)

I believe one of the differences is how a person views "type-safety". I
don't regard "<a> must only contain integers" as an interesting
requirement. "the second param of foo(a,b) must be an integer" is
interesting, and asserting specific return types is interesting.

Problems with types almost *always* occur at boundaries (function
arguments and return values). Type problems just don't occur within a
single function (Guido's CP4E system might disagree, tho :-). As a result,
I think restricting (variable) names is not nearly as interesting as
asserting that your func args/returns are "correct."

> Of course, obstreperous as I am, I immediately want to meddle with the
> scheme: specifically, though the *default* behaviour might be (in
> effect)
> 
>     if not isinstance(value, typechecker): raise TypeError
>     else: yield value
> 
> I'd argue for the semantics to say: evaluate the expressions `value' and
> `typechecker', look for a __check__ method on the latter: if present
> invoke it on the value, else use isinstance as above; on false return
> (no problem) the !-expression yields the given `value', otherwise
> TypeError with parameter the true value returned.  Then we can implement
> weird and devious __check__ methods for fiddly type-checks (instead of
> needing to change isinstance in the way proposed - which would conflict
> with my pet tweak to that, which allows isinstance(value, thistype,
> thattype, othertype) for when I've got several types I'll accept).

I think altering isinstance() to accept a callable is preferable to
introducing a __check__ method. A callable implies that you can use
builtin types to implement type-checkers. You could still use the
__check__ concept with builtins, but you would need to add new slots to
the type structures (which is, IMO, to be avoided).

There is no problem with saying that isinstance() can take more than two
parameters, where 2..n can be a type, a class, or a callable.

[ and note: it should be apparent that you check for a class before a
  callable :-) ]

> Please Greg/Fred/Sjoerd, can you write a proposal which starts where
> http://www.foretec.com/python/workshops/1998-11/greg-type-ideas.html
> ends (reading the first 9/10 of that was ... illuminating in hindsight,
> but off-putting on the way there).  It looks pretty promising ...

I'm peripherally interested here. Not enough to go writing :-). I've got
about three other projects on my "over the next couple months" plate. An
email here or there... sure, I'll do. An "emphatic discussion"... sure.

That page was definitely just a series of notes. I think somebody could
easily distill a one-page proposal from it. Please feel free!

Cheers,
-g

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