[Types-sig] challenge response (was: A challenge)

[Greg Stein]

On Wed, 15 Dec 1999, Skip Montanaro wrote:
>     Greg> Line 7: per caveat #1, assume the compiler can access the
>     Greg> find.find() function. From that, it knows the signature. The first
>     Greg> parameter has a matching type, but the second (PyObject) does not
>     Greg> match the required type (String), so an error is raised. If caveat
>     Greg> #5 is resolved, then the second parameter matches. It is also
>     Greg> possible to avoid the error by rewriting:
> 
>     Greg>     list = find.find("*.py", dir!StringType)	# 7
> 
>     Greg> "list" is now a ListType, based on the find.find() return
>     Greg> value. (see caveat #5 -- it could be possible to refine this
>     Greg> knowledge).
> 
> I humbly assert this train of thought rates a *bzzzt*.  I thought one core
> requirement was that all type declaration stuff be optional.  The worst that
> the type checker/inferencer should do in the face of incomplete type info is
> display a warning.  I don't think you can flag an error unless the
> programmer sets some sort of PY_ANAL_TYPE_CHECKING_AND_I_REALLY_MEAN_IT
> environment variable.

My entire post was pre-conditioned on the assumption that type-checking
has been enabled.

IMO, type checking is NOT enabled by default. I believe it will impose a
noticable performance penalty and I'm not willing to pay that in the
general case. Periodically, I'll turn it on and run it over my code (and
in that sense, type-checking as a lint-like tool is probably okay with
me; I'm more interested in typing for its (OPT) features).

As a side note: pulling in my Strawman from another thread, re: when to
insert runtime checks -- the determination is entirely based on syntax,
rather than a type analysis (or failure thereof). In other words, even if
we disable compile-time checking, we still end up with the same output
(which includes runtime checks where applicable).

Cheers,
-g

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