[Types-sig] Type-checked code calling unchecked code

[scott]

On Tue, Jan 25, 2000 at 12:24:23AM +1100, skaller wrote:
> scott wrote:
> 
> > > With Greg, you could write
> > >
> > > i = j() ! int
> > >
> > 
> > Just wanted to point out that in the case of '!', you get a runtime
> > error if you are wrong.  in the case of typecase, you get a compile
> > time error if it's wrong (typewise, of course).  I feel like I'm
> > repeating myself re: the runtime errors associated with !, but I think
> > it's important that it be pointed out, since the goal as I understand
> > it is greater compile time safety, and since the issue hasn't really
> > been addressed at all.
> 
> Greg Stein's semantics are NOT the ones I advocate -- 
> but the syntax is fine. I define
> 
> 	x ! y
> 
> as an assertion, and like all assertions in Vyper -- and indeed in
> Python
> -- if they are wrong, then the language translator is NOT required 
> to raise a TypeError, in fact, it can do anything it wants. 
> In particular, it can ASSUME that the assertion holds, 
> and optimise accordingly, and it can PROVE (perhaps) that the 
> assertion is false, and issue a compile time diagnostic.
> 
> So you're wrong: operator ! can yield compile time diagnostics
> if the semantics are suitably chosen; Greg simply didn't chose the
> right semantics. <g>

Ick.  either way, you are using this syntax to push what a type
checker should catch at compile time to runtime problems; regardless
if it 'can' cause compile time diagnostics *will* it?  The point of a
type checker at this stage of development IMO is to have safer code at
compile time.  Either semantic for this operator doesn't seem to me to
work toward that goal.  The issue of this operator failing to work
toward the goal of compile time safety is what needs to be addressed.  

Stating that a program is illegal since it raises an exception at
runtime does not address this issue.  Stating that the operator may be
assumed true by a translator does not address this issue.  If someone
can show that it doesn't reduce compile time safety compared to the
systems that don't have it, then it won't be an issue.  As it stands,
it is a problem, and needs to be addressed.

scott