[Types-sig] Optionality and performance

[Paul Prescod]

Greg Stein wrote:
> 
> > Optionality of type checking is not about it being enabled or disabled.
> > Even when it is enabled, type checking any particular method must be
> > optional. This whole discussion should presume "enabled". But
> > optionality is still important.
> 
> I'm assuming that we type-check a module at a time -- that we don't have
> the kind of fine-grained checking you're assuming. If a person doesn't
> want find-grained checking, then they just shouldn't add type annotations
> there.

Here's the issue I tried to address in RFC 1.0 under the term "safety
declarations".

def foo() -> String:
	# 10,000 lines of code
	return str( abc )

This function is guaranteed to meet its type signature if it completes,
but it is not necessarily type-safe in the Java sense. Anywhere within
it, an integer could be added to a string or a ".foo" invoked on a
float. 
For ERR it is important to be able to say that this function is
type-safe if there is some important reason that it really should not
fail. The type system can't guarantee termination but it can at least
ensure that TypeError and AttributeError will never be triggered by this
code. For a big part of our target audience, this assertion is the
reason for the exercise.

For OPT it is important to be able to say: "I need this code to run like
a bat out of hell and I believe that there are no string lookups or
runtime type checks required. Please verify that for me." So we need

"decl type-safe foo"

or something like that.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things see no end: A loop with exit code done wrong
A semaphore untested, and the change that comes along
http://www.geezjan.org/humor/computers/threes.html