[Types-sig] New syntax?

[skaller]

Greg Stein wrote:
 
> I think that we definitely want to be able to construct and use typedecl
> objects at runtime. That's why I prefer the typedef unary operator over
> your "sub-language."

Are these options mutually exclusive?

I've implemented operator ! in Viper now, x!t checks type(x) is t, 
and returns x if it is, otherwise it raises a TypeError. 
The precedence is one level tighter than Greg recommended, 
mainly because that was slightly easier for me to implement quickly. 
Here is some code I wrote using it:

  def append(self,object,value):
     object.list.append(value ! self.Type)

which is quite terse, seems readable and 'pythonic',
and works as I expected. Without this operator,
the code would read:

  def append(self,object,value):
     if type(value) is self.Type:
       object.list.append(value)
     else:
       raise TypeError

My current feeling: I quite like it -- but the above
is the only use I have tried, other than specifically 
for testing it. My feeling, also, is that in those
circumstances where the test would fail, then the
program should be considered in error (that is,
it is not legitimate practice to catch and handle
the TypeError, so that if a compiler can prove it would
be raised, it is entitled to reject the program,
and a lint like checker, to issue a diagnostic.
[The explicit test, like in the second example above,
should be used if it is desired to catch and handle
the raised TypeError]

This means that the x!t can be optimised to x,
without affecting strictly conforming program
semantics.

Comments? Greg?

-- 
John Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850