[Types-sig] Optionality and performance

[Greg Stein]

Good point. I think that I kind of described this difference in a previous
email, but you've stated it much more clearly.

I see type-safety as a second generation step, building on top of
type-checking. Can we defer these issues to a V2 system?

In general: I'd be happy with adding a "typesafe" keyword, but I think it
would behoove us to keep things small and simple. Let's just do
type-checking and defer type-safety and assignment enforcement.

Cheers,
-g

On Sun, 19 Dec 1999, Paul Prescod wrote:
> Greg Stein wrote:
> > ...
> > I'm saying we don't declare a need for type-safety. I'm saying that
> > type-safety checking is preconditioned on two things:
> > 
> >   1) type-checking is enabled when the module is compiled
> >   2) type annotations are present
> 
> And I'm saying that there are times when "as many as possible" is not
> enough. It is my presumption that this function will *always* pass the
> type checker:
> 
> def foo() -> String:
>       # 10,000 lines of code
>       print "abc"+eval( raw_input() )
>       return str( abc )
> 
> Its declaration is correct. Sure, it may raise TypeError but Python
> isn't Java and we should make it easy to write partially type-safe code.
> The return value is verifiably correct and that is all that matters.
> 
> But the same function would *never* pass the type checker if it was
> declared type-safe:
> 
> decl type-safe foo
> 
> Because its declaration is *incorrect*. Even though it returns what it
> should it is NOT typesafe because it can trigger one of TypeError or
> AttributeError. type-safe means safe in the Java/C++ sense which is a
> very different issue.
> 
> There is no reason to require foo to be moved to a separate module if it
> is the only function that requires that level of safety. I can think of
> no interesting reason to require all functions in a module to have the
> same safety level.
> 
> 

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