[Types-sig] Re: evaluating '!'

scott scott@chronis.pobox.com
Wed, 26 Jan 2000 13:14:46 -0500

On Tue, Jan 25, 2000 at 07:32:36PM -0800, Greg Stein wrote:
> On Wed, 26 Jan 2000, skaller wrote:
> > scott wrote:
> > > ... stuff about '!' constraining the system we can build ...
> >
> > ... John responding that '!' can exist in *addition* to another system ...
> I was going to respond to Scott and say the same thing, but I think John
> said it much better. 

>It is untrue that '!' will limit our type checking
> system in *any* fashion. 

That's not really what John said.  I would paraphrase by stating that
he thinks a mitigating factor of the drawback it presents is that one
could add it to any system -- indeed even any system that had no need
for it.  Then, one could create code without even using it and, for
that code,  attain the qualities of a type checking system without it.

But, it limits the type checking system in the following fashion:

if the system has a !-like construct, and you run it's compile time
checker on some random code, and you are presented with no errors,
then you know *nothing* about the relative type safety of that
program, because it is possible that each and every check the program
makes has been forced to be correct by the !-like construct, when in
fact those checks are wrong. 

A system without a !-like construct does not have this quality.

Does that quality sound desirable to you?  To me, the word undesirable
is understatement in the extreme.  We *can* know things about programs
that pass a compile time checker without errors.  Exactly what we
could know is currently being discussed while we address the things
that worry you below, and is algo-dependent for sure.  But the more we
know from a clean compile time check, the better.

>It is a (IMO) a great addition and will
> definitely help any other system that we might design. To me, it is a
> no-brainer place to start. Adding certain forms of "decl" and certain
> forms of syntax for type declarators are also no brainers. I just get a
> bit more worried about complex type declarators, parameterization, typedef
> mechanisms, and interfaces. Those will take a bit more discussion to reach
> a solid, consensual basis on their syntax, semantics, and benefits.

The no-brainer quality I see in your ! construct is not the ease of
implementation, but the effect on the system.  

I'm happy to agree to disagree on whether we want a system with this
quality, on whether you think the pros outweight this con, etc; but I
can't stand by and watch !-propoganda that seems factually incorrect
to me (like your statement above).


PS - have you tried to compile your grammar for type declarators into
python and run it yet?  I  have compiled an altered grammar into
python and ran into a few issues you might want to know about:

1) inline function delcarations as you wrote the grammar cause all
lambda usage to be a syntax error.

2) out of line function declarations produce hard-to-work-around
ambiguities in python's parser when you have 'def' [ NAME ':' ]
<whatev> instead of 'def' <whatev> [':' NAME ] because <whatev> can be
a name too.

3) adding words in hidden parts of the grammar, such as 'intrinsic',
causes the word 'intrinsic' to become a keyword.  The workarounds are
viable, but not clean by any means and probably not very easy either.