[Types-sig] Optionality and performance

[Greg Stein]

On Sat, 18 Dec 1999, Paul Prescod wrote:
> Greg Stein wrote:
> > 
> > Skip Montanaro wrote:
> > > I humbly assert this train of thought rates a *bzzzt*.  I thought one core
> > > requirement was that all type declaration stuff be optional.  The worst that
> > > the type checker/inferencer should do in the face of incomplete type info is
> > > display a warning.
> 
> > My entire post was pre-conditioned on the assumption that type-checking
> > has been enabled.
> 
> 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.

> > IMO, type checking is NOT enabled by default. I believe it will impose a
> > noticable performance penalty and I'm not willing to pay that in the
> > general case. 
> 
> I don't see how we can logically treat type checks differently than
> array bounds checks, overflow checks and so forth. It needs to be on by

The latter are runtime checks. I do agree that *runtime* type checks will
always be generated by the compiler (per my other emails) and that the
runtime check will always be performed (well, not with -O, just like
regular asserts are not enabled when -O is provided).

> default and we'll just need to figure out how to minimize its impact.
> Most type checks should involve quick pointer comparisons and that will
> be covered up by the other performance enhancement.

Again: runtime. I was referring to compile-time, static checks. I do not
believe those will always be enabled.

> In particular, when you declare conformance to a class or interface,
> method calls should no longer be string-dispatched. That means you need
> interfaces to be like vtables so the type checker's job is to find the
> right vtable. The type check actually comes "for free" in implementing
> the name lookup optimization.

Different issue (and a good/valid one!). I would recommend adding this to
your list of issues and deferring it for now.

Tim rightly points out: taking on too much right now will just cause
another self-destruction.

Cheers,
-g

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