[Types-sig] Re: syntax and compile/run -time

Paul Prescod paul@prescod.net
Mon, 03 Jan 2000 18:26:09 -0500


Greg Stein wrote:
> 
> Dividing the language into pieces is simply dividing it. I see no rational
> reason for doing so, but many reasons to keep everything clean and
> integrated.

Dividing the language is inevitable. The question is whether to do it
"up front" or subtly through cryptic error messages.

> > This, for instance, is not legal:
> >
> > a = doSomething()
> > b = typedef a
> 
> It certainly can be legal. But the type-checker would say "I can't help
> you here."

I don't want the type-checker flagging valid code with warnings (unless
you turn -Wall) and I don't want it silently ignoring code like the
above because it doesn't understand it.

You are setting up three levels of conformance:

1. Checked at compile time.
2. Seems like it *might* be checked at compile time but you get a
warning telling you that it doesn't.
3. Checked at runtime.

I vote to remove the middle option by clearly flagging which things fall
into the former and latter categories.

Also, what do you do about forward declarations? They are not a problem
with my syntax.

> I believe this distinction is unnecessary and is on the wrong track. I do
> not believe there is a requirement to create a partitioning of the
> language and its semantics. It is much better to leverage the existing
> semantics of Python than to create a whole new set.

The partitioning is not avoidable. Some objects are evaluated at 12:35
when the static type checker runs. Other objects are evaluated at 12:27
when the code starts to interpret. You can hide that and then issue
warning messages but all you have done is *hide it*. I think "be
explicit" is more Pythonic.

> Specifically, in your example: if "a" or "b" was used in a later typedecl:
> 
>   def foo(x: a)->None:
>     ...
> 
> We Could issue a warning that might read, "The type information
> represented by <a> is not available at compile time; compile-time checking
> is not enabled for parameter <x> in the function <foo>, nor for calls to
> <foo>."
> [ well, some suitable word-smithing is needed there :-) ... but you get
>   the idea. ]

I don't think word-smithing will help. The problem is that you've taken
an unavoidable, temporal distinction, papered it over, and then
re-introduced it through warning messages. That is unavoidably
confusing.

 Paul Prescod