[Types-sig] compile/run -time (was: syntax and compile/run -time)

[Paul Prescod]

Greg Stein wrote:
> 
> The "runtime" keyword presumes too much knowledge on the programmer's
> part. How are they supposed to know the full bounds and limitations of the
> type checker? If you say, "you must insert 'runtime' in places where the
> type checker can't figure out something at compile-time," then they're
> next question will be, "okay. when is that?"

That's *exactly* my point. Now we are getting to the nub of the problem.

I know exactly what the Java type checker will and will not check at
compile time. The rules are simple enough that I can fit them all in my
head. If we develop a type system that does not allow a typical
programmer to fit all of the rules in their head then we have, in my
opinion, failed.

> Instead, allow all the forms and make the type-checker do its best. The
> code will always work properly.

"Doing its best" is not good enough. I'm turning on type checking
because I want it to do its job completely and properly and give me a
big fat error message if it cannot.

> If somebody marks a function as "typesafe", then the checker should raise
> an error if it cannot determine a particular typedecl condition (like with
> the "a=get_an_interface()" example). If a function is not marked as
> "typesafe", then we will not have lost any functionality over 1.5, but we
> certainly have gained: the argument will be checked on function entry.

The problem is that the semantic distance between the place where they
made the mistake and the place where they run into a problem could be
quite long. If I write a typesafe function that depends on an interface
that depends on an interface, that depends on an interface, that depends
on an interrace that uses runtime types, I have a lot of backtracking to
do. Instead, the "runtime" keyword should be contagious so that as soon
as you use it, you KNOW.

You can't use runtime types without knowing that you are doing so
because you are going to run into an error message sooner or later.
Therefore requiring the user to understand the issue sooner rather than
later is doing them a favor.

> a = get_an_interface()
> def foo(x: a):
>   ...
> 
> That is much better than what I can do today. 

No, not really:

a = get_an_interface()
def foo(x):
	if not a.check( x ):
		raise TypeError

If it can't be checked at compile time, it's syntactic sugar for stuff
we can do already.
> It requires the programmer to know too much about the type-checker. I
> think we have the runtime/compile-time issue covered without this.

Programmers should know all about type checkers. That's their job. It's
our job to make things simple enough so that they can do their job.

> a = typedef Int or String
> 
> is always evaluated at runtime. It creates a typedecl object and assigns
> that to "a". The question is whether the type-checker can do anything with
> it at compile-time. In most cases: yes, it can understand the situation.
> In atypical cases: no, it can't and bugger on those people.

I don't see the type checker as a side effect that sometimes works and
sometimes doesn't. The type checker is the main event. It's what we are
here to design. New runtime features are the side effect.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
The occasional act of disrespect for the American flag creates but a 
flickering insult to the values of democracy -- unless it provokes 
America into limiting the freedoms that are its hallmark.
           -- Paul Tash, executive editor of the St. Petersburg Times