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

[Greg Stein]

On Wed, 5 Jan 2000, Paul Prescod wrote:
>...
> I agree with you 100% philosophically and if a new keyword "runtime" is
> an acceptable compromise then I would be willing to do it. It's an added
> complication but only people trying to do complicated stuff would bump
> into it.

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?"

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

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.

a = get_an_interface()
def foo(x: a):
  ...

That is much better than what I can do today. The type-checker can't deal
with it, so it leaves it to the run time. *IF* the user turns on -Wall, or
maybe just -Wunknown-typedecl, then the checker will warn/error on this
kind of construct. If the user does:

a = get_an_interface()
typesafe def foo(x: a):
  ...

The type-checker will flat-out refuse to allow this.

Allowing the complex typing construct cannot hurt us -- it can help us.
Leave the flexibility to the programmer to decide how they want to handle
these things -- stop trying to legislate so hard.

>...
> We might think of extending this keyword to other contexts where things
> that would otherwise be expected to be compile time:
> 
> runtime import somedbadapter
> 
> The compiler wouldn't try to look up somedbadapter at compile time and
> names from that namespace would be invisible at compile time.

Presumably "somedbadapter" has no interface information, so why add the
"runtime" to it? The two situations are the same -- whether it doesn't
find it or you tell it not to look for it. Granted, if the user happens to
use -Wunknown-modules, then they get a warn/error on an import where no
interface information can be produced.

> Greg, is this a workable compromise?

It requires the programmer to know too much about the type-checker. I
think we have the runtime/compile-time issue covered without this.

> I would like to say that one could think of typedef and runtime as
> inverses but it doesn't quite work out...Greg's model is that "typedef"
> gives access to new syntax, but is sometimes evaluated at runtime.

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.

Cheers,
-g

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