in operator
Ruby allows calling include? on a collection to determine whether an item is in that collection. In essence, we can think of this as: container operator item
But there is nothing to do that in reverse order, syntactically speaking: item operator container
The issues I perceive are these:
if [MS, AL, VA, TX, NJ, NY].include? state ...include?).Make the (existing) keyword in represent an operator in a syntax-sugar fashion.
Just as for x in y is syntax sugar that invokes the standard iterator each, let x in y be syntax sugar that invokes the method include? on the operand.
In other words, x in y would always mean exactly the same as y.include? x, even when y does not define an include? method.
By analogy, note that for x in y will fail if y does not define each.
Note that in is already a reserved word in Ruby (which Matz has said "will not go away"). We therefore don't have to add a new keyword.
Existing code will not break, as the tokens x in y are not meaningful in Ruby currently.
Use of the operator would be optional at the programmer's discretion, just as for may or may not be used in place of each.
I envision this expression always returning true or false, since as far as I know, that is what include? always does.
Obviously common uses might be in loops and conditionals:
words << (ch = STDIN.getc) until ch in ['.', ';', '!', '?']
or also
if digit in 0..4 then...
The biggest question I am aware of is: What should the precedence of this operator be?
I favor putting it at the same level as the comparison operators. Note the following:
x in array1 + array2x in array1 & array2x in array1 | array2in would bind more tightly than assignment, making it easy to assign a Boolean:flag = x in listin would bind more tightly than && and ||, simplifying such constructs as:if a in x || b in y ... if num > 1000 && num in primes...in is already a keyword; I would expect we could assign it a precedence, add some yacc rules, and add a bit of code calling the include? method.
It also seems a little incongruous for it not to be a method, specifically a '?' method. I'm not saying it isn't reasonably clear, or couldn't be learned, but it feels like "a.include?(x)" and "x in a" are cut from excessively different cloths. I actually like "x.in?(a)" better (and yes, for the minimalists out there, I do know it involves typing more characters :-)
-- David Black
I like the proposal. While I understand David's points, I feel that "for x in y" and "if x in y" are so similar that it makes sense for the latter to be in the language.
However, I do get by just fine with
class Object
def in?(enum)
enum.include? self
end
end
(This is in the extensions project: http://entensions.rubyforge.org)
-- Gavin Sinclair
"[...] x in y would always mean exactly the same as y.include? x, even when y does not define an include? method."
... then "for x in y" should read as "for true" or "for false" (?), so I disagree that there's any similarity between "for x in y" and "if x in y".
While I agree with the perceived problem, I had to vote against the proposed solution.
-- daz
elem == any('.', ';', '!', '?')
or flgr/ruby-style
elem == ['.', ';', '!', '?'].any
Junctions solve lots of other problems as well, withouth requiring any syntax change, and with a clear sound ".. elem is equal to any of .." -- gabriele renzi
I'm not opposed to the functionality, just the horrible syntax.
-- Hal Fulton
(1..10).include? x
would become
x in 1..10
Of course, that tidbit is not likely to sway anyone who hates this idea. :)
I just think that since we have for/in (and it's not going away), 'in' makes a nice complement to it.
I don't miss the dot and the question mark any more than I miss them when I say
x == y
rather than saying
x.==? y
But it's just my opinion.
-- Hal Fulton
The result of...
if x in y
...should be similar to that of
for x in y
To be consistent, the 'if x in y' version should assign the first element of 'y' or nil to 'x'.
if x in y # if (x = y.first)
The operator proposed, if accepted, should be consistent with 'include?', thus the name should be something like 'is_included?' or just 'included?'. I don't see a benefit here and, speaking in terms of linguistics, I think in this case it's not worthy the passive voice (placing the direct object as subject).
-- Michel Martens
I have never seen nor imagined a language in which "if x in y" would perform an assignment operation.
As for passive/active, relational operators correspond to linking verbs in human language, not action verbs.
-- Hal Fulton
Let's see both expressions expanded:
for [each element] x [that has a value assigned from an element] in [collection] y
print x
end
Note that 'x' has no value before the 'for' expression is evaluated. At each loop, a value from collection 'y' must be assigned.
Bellow is the 'in' as used in the proposal:
if [a value equal to that of element] x [exists] in [collection] y
print x
end
Here, 'x' MUST have a value before the evaluation occurs, and no assignment is ever done.
To be consistent, an assignment should occur. It doesn't mean that I want to see that kind of operand, we already have one, but another wording should be used instead.
-- Michel Martens
It's the nature of a for-loop to assign successive elements of a collection to a control variable. The "in" in this case is almost a meaningless particle (like the "then" following an if). I don't believe it makes any sense to say that "in" denotes assignment. The "for" itself implies assignment.
"in" as an operator works the way I've shown in Pascal, learned by millions for over thirty years.
Though I don't know Python, my understanding is that it works the same way.
I've seen this used in algorithmic notation in my discrete structures class. And I've even heard my calculus professors (orally) read the "is a member of" operator as "in" or "is in."
So I think this usage is well-supported and very intuitive for most people.
-- Hal Fulton
Pascal and Python use 'in' as shown in this proposal, and it may be very intuitive for most people, you are right. I like the way Ruby handles this need (the OO way of include?) and prefer iterators and "object.boolean_functions?" over constructs like those exposed (the Python and Pascal way). I won't be mad if enough people vote in favor of this syntax sugar and it gets included in the language, I just saw a chance to look for a better word. Sadly for this case, I'm a native spanish speaker so chances are I won't come up with a great precise word to use. -- Michel Martens
That is fascinating, I would have assumed you were a native English speaker, but I see now that "Michel" is spelled without an "a." Do you know Mauricio Fernandez (batsman)? He also speaks excellent English. Maybe Americans should go to Spain to learn English? :)
Anyway, I can understand why you would want a different word. But if it were a different one, I think that would tend to make me *oppose* the idea. If 'in' had not already been a keyword, I would not have made the suggestion. I think we don't want too many keywords in Ruby.
-- Hal Fulton
I agree with David Black. It seems to break the elegant symmetry to use the keyword and not the method in?. Additionally, I feel that x.in? y is actually clearer. One of the things that attracted me to Ruby is its excellent use of question marks, and it works wonderfully with in?.
I would also argue that "x in y" does *appear* to change the meaning of the keyword. Although on close inspection "in" may be a meaningless particle in the context of for-loops, its position between the variable name and the elements being assigned may cause people to view it as different sort of assignment operator. It makes more sense for the assignment operator to be between the elements rather than in front (Lisp users excluded!) I have that impression, and it seems so did Michel Martens. I also share his wariness for new constructs. It would seem, at the very least, that using the keyword in this context would change "in" from being a meaningless particle to a meaningful one.
--David Chen
Back to RCRchive.
RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog