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.
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.
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
On 7/16/05, Daniel Brockman <daniel@brockman.se> wrote:
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 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)
Devin
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.
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?’.
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.
Daniel Brockman wrote:
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?’.
Well, I agree with you. There's only one way to parse `assert puts foo` that I know of, too. Also, I like the ability to do a LISP-with-commas syntax, though Ruby disallows it sometimes. But whatever.
Devin
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
On 7/16/05, Daniel Brockman <daniel@brockman.se> wrote:
Devin Mullins <twifkak@comcast.net> writes:
Daniel Brockman wrote:
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?’.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?
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.
We could always do this:
class Negator
instance_methods.each { |x| undef_method x if x[-1] == ?? }
def initialize object
@object = object end
def method_missing name, *args, &block
name.to_s[-1] == ?? or super
not @object.__send__ name, *args, &block end end
class Object
def not
@__negator__ ||= Negator.new self end
alias_method :does_not, :not
alias_method :do_not, :not end
assert pet_class.ancestors.do_not.include?(Monster)
@pet = 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 ‘respond_to?’ 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?
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.
Daniel Brockman wrote:
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?
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
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
On Jul 17, 2005, at 1:20 PM, Daniel Brockman wrote:
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?
Daniel Brockman wrote:
Also, I like the ability to do a LISP-with-commas syntax,
though Ruby disallows it sometimes.
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
---
I'm confused... what mistake do they think I'm going to make?
Devin
gwtmp01@mac.com writes:
Is there any word on the chances of [‘assert foo.respond_to? bar’]
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 “core idea” 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 ‘foo bar baz’, did you change subject to
my tounge-in-cheek ‘foo.not.bar?’ hack, or was that sentence 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
On Jul 17, 2005, at 1:20 PM, Daniel Brockman wrote:
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.
Devin Mullins <twifkak@comcast.net> writes:
Daniel Brockman wrote:
Also, I like the ability to do a LISP-with-commas syntax,
though Ruby disallows it sometimes.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
---I'm confused... what mistake do they think I'm going to make?
Yes, I too do not see the point of this warning. What will
happen to code like this in a “future version”?
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 ‘$’ 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.
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.
The “core idea” 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
On Jul 17, 2005, at 2:34 PM, Daniel Brockman wrote:
gwtmp01@mac.com wrote:
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...
gwtmp01@mac.com writes:
The “core idea” 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
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 ‘not’ 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 “but I thought
it meant ‘(assert not) foo.bar?’,” because that doesn't even
make sense. Second of all, there are many examples of
methods in Ruby being thought of as language constructs —
one example being ‘assert’.
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 ‘assert’ 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?
On Jul 17, 2005, at 2:34 PM, Daniel Brockman wrote:
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.
And others will disagree.
I don't like e e cummings, either.
On 7/17/05, Devin Mullins <twifkak@comcast.net> wrote:
My feeling is the exact opposite. I think
assert foo.respond_to? bar
is immensely more readable than.
assert(foo.respond_to?(bar))
--
I tend to view "truly flexible" by another term: "Make everything
equally hard". -- DHH
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
On 7/18/05, Michael Campbell <michael.campbell@gmail.com> wrote:
On 7/17/05, Devin Mullins <twifkak@comcast.net> wrote:
> 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.I don't like e e cummings, either.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca