On 7/16/05, Daniel Brockman <daniel / brockman.se> wrote:
> Devin Mullins <twifkak / comcast.net> writes:
> 
> > Mark Hubbart wrote:
> >
> >> However, it's true that you can't use it directly in parameter lists.
> >> You can get around it like this:
> >>   assert((not foo))
> >> The extra parens make the 'not foo' evaluate separately from the
> >> parameter list, and it works.
> >
> > Also, oddly,
> >   assert (not foo)
> 
> Yes, I know 'not' is a keyword and I know you can work around the
> problem like that.  That doesn't mean the current behavior of raising
> a syntax error when seeing not in a parameter list is useful.

I agree... I prefer using the english "not, "and", and "or" boolean
operators in almost every case. There was a thread on this exact
subject a while back, though I can't find it at the moment, which
focused more on the use of "or" and "and". There wasn't a resolution
to it that I remember, though.

But, 'assert(not(foo))' just looked bizarre to me. If 'foo' were an
expression, and there was a space between 'not' and the first paren,
it wouldn't look so odd, I suppose: 'assert(not (foo or bar))

> The best workaround is to simply use '!', but I prefer the spelled-out
> boolean operators, and I don't see why it should be disallowed here.
> 
> I realize that 'not foo not bar and not baz' would be confusing.
> But I maintain that there is only one way to parse 'assert not foo?',
> and that it looks better than 'assert !foo?'.

I wonder if giving a syntax error in these cases was a design
decision, a parser limitation, or just an oversight?

cheers,
Mark