`not' in parameter lists

[Daniel Brockman]

I just noticed that all of the following give syntax errors:

* assert not foo

* assert not(foo)

* assert(not foo)

* assert(not(foo))

I would like them all to be equivalent to the following:

assert !foo

At the _very_ least, the fully-bracketed one should work,
but it would be great if they all worked.

 

[Mark Hubbart]

I just noticed that all of the following give syntax errors:
=20
* assert not foo
=20
* assert not(foo)
=20
* assert(not foo)
=20
* assert(not(foo))
=20
I would like them all to be equivalent to the following:
=20
assert !foo
=20
At the _very_ least, the fully-bracketed one should work,
but it would be great if they all worked.

First, remember that 'not' is a keyword, not a method. So it won't
work as a method call.

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.

cheers,
Mark

 

[Devin Mullins]

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)

Devin

 

[Daniel Brockman]

Also, oddly,
assert (not foo)

Yes, I know =E2=80=98not=E2=80=99 is a keyword and I know you can work ar=
ound 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.

The best workaround is to simply use =E2=80=98!=E2=80=99, but I prefer th=
e spelled-out
boolean operators, and I don't see why it should be disallowed here.

I realize that =E2=80=98not foo not bar and not baz=E2=80=99 would be con=
fusing.
But I maintain that there is only one way to parse =E2=80=98assert not fo=
o?=E2=80=99,
and that it looks better than =E2=80=98assert !foo?=E2=80=99.

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Devin Mullins]

I realize that =E2=80=98not foo not bar and not baz=E2=80=99 would be co= nfusing.
But I maintain that there is only one way to parse =E2=80=98assert not f= oo?=E2=80=99,
and that it looks better than =E2=80=98assert !foo?=E2=80=99.
=20

Well, I agree with you. There's only one way to parse `assert puts foo`=20
that I know of, too. Also, I like the ability to do a LISP-with-commas=20
syntax, though Ruby disallows it sometimes. But whatever.

Devin

 

[Daniel Brockman]

Well, I agree with you.

Good to hear.

There's only one way to parse `assert puts foo` that I know of, too.

Yes, I'd like to see this

foo bar baz, moomin snufkin

become shorthand for this,

foo bar(baz), moomin(snufkin)

and what's the deal with this being disallowed?

foo bar(baz, moomin snufkin)

Also, I like the ability to do a LISP-with-commas syntax,

Hmm, for a while I thought I had invented that.

though Ruby disallows it sometimes.

When does Ruby disallow it?

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Devin Mullins]

Hmm, for a while I thought I had invented that.


When does Ruby disallow it?

OK, maybe I'm crazy. I thought I had seen Ruby complain about it once,
but I can't get it to happen now. Nevermind!

Devin

 

[Mark Hubbart]

=20
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.
=20
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

 

[Daniel Brockman]

We could always do this:

class Negator
instance_methods.each { |x| undef_method x if x[-1] =3D=3D ?? }
def initialize object
@object =3D object end
def method_missing name, *args, &block
name.to_s[-1] =3D=3D ?? or super
not @object.__send__ name, *args, &block end end
=20
class Object
def not
@__negator__ ||=3D Negator.new self end
alias_method :does_not, :not
alias_method :do_not, :not end

assert pet_class.ancestors.do_not.include?(Monster)
@pet =3D pet_class.new
assert @pet.does_not.respond_to?roar!)
3.times { @pet.feed Apple.new }
assert @pet.not.hungry?

(Finally a context in which the name =E2=80=98respond_to?=E2=80=99 sounds=
right.)

It would be nice to be able to get rid of those pesky parens, though:

assert pet_class.ancestors.do_not.include? Monster
assert @pet.does_not.respond_to? :roar!

Is there any word on the chances of this becoming allowed in the future?
I mean, is it definitely ruled out, or is there room for persuation?

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[gwtmp01]

Is there any word on the chances of this becoming allowed in the
future?
I mean, is it definitely ruled out, or is there room for persuation?

Personally I don't like this sort of "change" to a language or library.
There are certain *core* ideas in a programming language (or library
or framework) that should be obvious to every single programmer using
that system. Flexibility in a language is important but should only
be used to augment the core language. When the flexibility is used
to obfuscate the core ideas via a "dialect" the result is often only
of use to the original author.

Here is a function from the Version 7 Bourne Shell that was
notorious for its abuse of C macros:

INT pathopen(path, name)
REG STRING path, name;
{
REG UFD f;

REP path=catpath(path,name);
PER (f=open(curstak(), O_RDONLY))<0 ANDF path DONE
return(f);
}

What exactly is going on here? What is REP, PER, ANDF, DONE?


Gary Wright

 

[Daniel Brockman]

Is there any word on the chances of [=E2=80=98assert foo.respond_to? b= ar=E2=80=99]
becoming allowed in the future? I mean, is it definitely ruled
out, or is there room for persuation?

Personally I don't like this sort of "change" to a language or
library. There are certain *core* ideas in a programming language
(or library or framework) that should be obvious to every single
programmer using that system.

The =E2=80=9Ccore idea=E2=80=9D in this case being... what?

Flexibility in a language is important but should only be used to
augment the core language.

Are you still talking about =E2=80=98foo bar baz=E2=80=99, did you change=
subject to
my tounge-in-cheek =E2=80=98foo.not.bar?=E2=80=99 hack, or was that sente=
nce just a
random assertion?

When the flexibility is used to obfuscate the core ideas via a
"dialect" the result is often only of use to the original author.

In this case, what flexibility is being abused?

Here is a function from the Version 7 Bourne Shell that was
notorious for its abuse of C macros: [gibberish]

Your point being... that C should not have had macros?
That the Version 7 Bourne Shell should not have abused them?
Or is the analogy that this is all well and good,

assert foo.respond_to?bar)

while the following looks like the Bourne Shell gibberish?

assert foo.respond_to? :bar

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[gwtmp01]

The =93core idea=94 in this case being... what?

negation of a truth value

I guess I missed the tongue-in-cheek nature of your
posting.

Regarding:

assert foo.respond_to? bar

I think that having too much flexibility in a
grammar leads to confusion and different "dialects".
Ruby has a nice balance right now. IMHO. That doesn't
mean that it can't be made better.

If I follow you correctly, you are suggesting that
not only should parenthesis be optional in method
calls but that the commas should be optional also and
while you are at it you want the not keyword to be parsed
syntactically as an operator/method even though it doesn't
behave as one.

My gut feeling is that these changes introduce too
much flexibility into the grammar such that it *could*
become difficult for programmer A to understand
programmer B's code. Just my opinion of course.

I also have a feeling from a human-factors point of
view that punctuation is important to improving the
readability of code. While I think a lisp-like
syntax is immensely powerful from a programatic standpoint
I think that it can be difficult for a human
to read and understand quickly.

Here is a function from the Version 7 Bourne Shell that was
notorious for its abuse of C macros: [gibberish]

Your point being... that C should not have had macros?
That the Version 7 Bourne Shell should not have abused them?
Or is the analogy that this is all well and good,

My point was that C macros provide a huge amount of syntax
flexibility and that can be abused to the point where it is
hard to read the code.


Gary Wright

 

[Devin Mullins]

I also have a feeling from a human-factors point of
view that punctuation is important to improving the
readability of code. While I think a lisp-like
syntax is immensely powerful from a programatic standpoint
I think that it can be difficult for a human
to read and understand quickly.

My feeling is the exact opposite. I think
assert foo.respond_to? bar
is immensely more readable than.
assert(foo.respond_to?(bar))

The punctuation just leads to clutter, and in a block of 100s of other
lines like that, the line ends up looking like this to me when I try to
skim it:
asse oo.respond_to r

But I realize that's just personal preference. However, I don't see how
a language that allows both syntaxes is going to kill you any more than
a language that doesn't place any significance in whitespace.

Devin
Actually, my favorite syntax would have to be
assert (foo.respond_to? bar)
Anyways...

 

[Devin Mullins]

When does Ruby disallow it?

Well, discourages, but not disallows.

---
ruby -we'p (File.exist? "")'
-e:1: warning: (...) interpreted as grouped expression
false

ruby -we'p(File.exist? "")'
-e:1: warning: parenthesize argument(s) for future version
false

 

[Michael Campbell]

My feeling is the exact opposite. I think
assert foo.respond_to? bar
is immensely more readable than.
assert(foo.respond_to?(bar))

And others will disagree. =20

I don't like e e cummings, either.

--=20
I tend to view "truly flexible" by another term: "Make everything
equally hard". -- DHH

 

[Daniel Brockman]

negation of a truth value

I guess I missed the tongue-in-cheek nature of your
posting.

Regarding:

assert foo.respond_to? bar

I think that having too much flexibility in a
grammar leads to confusion and different "dialects".
Ruby has a nice balance right now. IMHO. That doesn't
mean that it can't be made better.

If I follow you correctly, you are suggesting that
not only should parenthesis be optional in method
calls

The parentheses are already optional in method calls.
It's just that nested method calls currently need them.

but that the commas should be optional also

Hmm, I don't think I ever suggested that.

and while you are at it you want the not keyword to be
parsed syntactically as an operator/method even though it
doesn't behave as one.

How does the =E2=80=98not=E2=80=99 keyword not behave as an operator,
and why shouldn't it?

My gut feeling is that these changes introduce too
much flexibility into the grammar such that it *could*
become difficult for programmer A to understand
programmer B's code. Just my opinion of course.

That is a valid point. Programmer B would have to use his
best judgement, and not write things like the following:

not foo not bar and not baz

(I don't think I have to point out that if B wants to write
code that is difficult for A to understand, there's really
nothing we can do to stop him if we still want Ruby to be
the powerful language it is.)

I also have a feeling from a human-factors point of
view that punctuation is important to improving the
readability of code.

My feeling is that punctuation is important sometimes,
but not necessarily all the time. First of all, this

assert not foo.bar?

can only be parsed one way. You can't say =E2=80=9Cbut I thought
it meant =E2=80=98(assert not) foo.bar?=E2=80=99,=E2=80=9D because that d=
oesn't even
make sense. Second of all, there are many examples of
methods in Ruby being thought of as language constructs =E2=80=94
one example being =E2=80=98assert=E2=80=99.

As such, it can seem strange that the above gives a syntax
error, while this works:

if not foo.bar? ...

Actually, I now realize that this is exactly the reason why
the =E2=80=98assert=E2=80=99 example should *not* be allowed.

Consider these two examples:

assert not foo.bar?

assert not foo.bar? and not baz.quux?

I don't think it would be acceptable to have the former work
as intended, while the latter would siletly misbehave.

So I am now convinced that the current syntax is correct.
Had I thought of the above issue earlier, I might not even
have started this thread.

While I think a lisp-like syntax is immensely powerful
from a programatic standpoint I think that it can be
difficult for a human to read and understand quickly.

I would have to agree.

Here is a function from the Version 7 Bourne Shell that was
notorious for its abuse of C macros: [gibberish]

Your point being... that C should not have had macros?
That the Version 7 Bourne Shell should not have abused them?
Or is the analogy that this is all well and good,

My point was that C macros provide a huge amount of syntax
flexibility and that can be abused to the point where it is
hard to read the code.

But would you want to give up that flexibility?

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Daniel Brockman]

When does Ruby disallow it?

Well, discourages, but not disallows.
[...]

ruby -we'p(File.exist? "")'
-e:1: warning: parenthesize argument(s) for future version
false

Yes, I too do not see the point of this warning. What will
happen to code like this in a =E2=80=9Cfuture version=E2=80=9D?

assert(foo.respond_to? bar)

Another tongue-in-cheek suggestion: If this

assert foo.respond_to? bar

is too confusing and ambiguous in the light of this,

assert foo.respond_to? bar, baz

we could borrow the =E2=80=98$=E2=80=99 operator from Haskell:

assert $ foo.respond_to? bar

This operator always means the same thing as an opening
parenthesis with a corresponding closing one at the end of
the expression. As I said, tounge-in-cheek.

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Austin Ziegler]

And others will disagree.
=20
I don't like e e cummings, either.

I think that this could be readable, but we're probably reaching for
SmallTalk at this point:

assert: foo.respond_to? bar

The problem, ultimately, is that you can't meaningfully do:

foo bar baz, moomin snufkin

There's too many possible meanings for that:
foo(bar(baz), moomin(snufkin))
foo(bar(baz, moomin(snufkin)))
foo(bar(baz)), moomin(snufkin)

I am not particularly fond of the idea that arguments to a method
would bind to the nearest method.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)