strings combine
in [Ruby]
|
Prev: Help : Error in scrubyt
Next: DXF Writer?
From: Robert Klemme on 19 Feb 2010 16:13 On 19.02.2010 21:24, Justin Collins wrote: > Raul Jara wrote: >> Roger Pack wrote: >> >>>> I think you misunderstand what I was saying. I was not asking what the >>>> differences between the parser and the runtime are. I was asking for a >>>> rationale. If Matz believed that strings, when placed together without >>>> any punctuation between them should be concatenated, why didn't he make >>>> it standard operating behavior? I can't imagine it would have been so >>>> difficult for when the parser sees two variables in a row to treat it as >>>> equivalent to a concatenation call on the first variable with the second >>>> variable as an argument. If Matz didn't think that two strings should >>>> be concatenated, why program that behavior into the parser? >>>> >>> Yeah it ends up being pretty hard to generate a parser that will do >>> both. >>> -rp >>> >> >> I'm not sure why, though. The parser is able to turn >> >> x + y >> >> into >> >> x.+(y) >> >> >> What would be so hard about having the parser turn: >> >> x y >> >> into >> >> x.+(y) >> >> ? >> >> Or if you only think strings should work that way, and not numbers: >> >> x.concat(y) >> > > Because > > x y > > already means > > x(y) Exactly my point. robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Raul Jara on 19 Feb 2010 17:02 Justin Collins wrote: > Raul Jara wrote: >>>> be concatenated, why program that behavior into the parser? >> into >> x.+(y) >> >> ? >> >> Or if you only think strings should work that way, and not numbers: >> >> x.concat(y) >> > > Because > > x y > > already means > > x(y) > > > -Justin But the parser knows what's a method and what's a variable, right? (I'm asking. I assume so but I really don't know.) If it knows what is a variable and what is a method, it can define x y as x(y) when x is a method, and x y as x.+(y) when x is a variable. Right? I'm not trying to prove a point, or anything. I'm just trying to understand if there is a rationale behind this decision that I'm not seeing. -- Posted via http://www.ruby-forum.com/.
From: Rick DeNatale on 19 Feb 2010 19:59 On Fri, Feb 19, 2010 at 5:02 PM, Raul Jara <raul.c.jara(a)gmail.com> wrote: > But the parser knows what's a method and what's a variable, right? (I'm > asking. I assume so but I really don't know.) If it knows what is a > variable and what is a method, it can define x y as x(y) when x is a > method, and x y as x.+(y) when x is a variable. Right? No. First - In the expression x y It sees x as a method because of the form of the expression. Just as it does for the expressions x(y) or self.x y and if we have: a = 'x' b = 'y' a b is the same as: self.a b not 'x' b def a(arg) "My arg is #{arg}" end a = 'string 1' b = 'string 2' a b # => "My arg is string 2" Second, variables in Ruby are untyped references to objects, and not objects themselves. So what would the compiler to do with def two_args(x, y) x y end two_args('a', 'b') two_args(1, 2) Third, the interpretation of 'a' 'b' as 'ab' Is not really a parser thing, it's a lexical analyser thing. It's just a rarely used form of string literal which allows for quoted strings separated by whitespace (or escaped newlines) to be coalesced before the parser even sees them. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale
From: Brian Candler on 20 Feb 2010 06:09 Rick Denatale wrote: > In the expression > > x y > > It sees x as a method because of the form of the expression. And to prove this: irb(main):001:0> x y NameError: undefined local variable or method `y' for main:Object from (irb):1 That is: ruby has already decided from *parsing* that x could only be a method name. Actually x is neither a method nor a local variable right now, but when parsing it doesn't know this. So it's parsed as x(y), and the first thing it errors on when trying to execute that expression is that y is undefined, as you evaluate all the args before performing the method call. irb(main):002:0> y = nil => nil irb(main):003:0> x y NoMethodError: undefined method `x' for main:Object from (irb):3 So: x y is unambiguously saying x is a method, y is arg self.x is unambiguously saying that x is a method x() is unambiguously saying that x is a method The only time where ruby has to probe further is an expression like this: x Then it looks to see if there has been a previous expression of the form x = ... in the current scope. If so, x is a local variable. If not, x is a method. So the current rules let us know unambigously that puts "hello" is always a method call, without having to think any further. Even the following oddball example works in a fairly understandable way: puts = "abc" puts "hello" puts puts If you decided to change the parsing just to allow concatenation of adjacent items it would become horrendously complicated to read ruby source. For example, the line puts "hello" *might* be a method call, or it *might* be concatenation, depending on whether puts was a local variable or not. That means you couldn't understand any source without continually looking back at the previous lines in the method. In any case, just look at the C language for an example where concatenating adjacent string *literals* is implemented, but it would make no sense at all to concatenate two adjacent expressions, because the language doesn't even have a string concatentation operator. char *c0 = "abc" "def"; // 7 bytes, abcdef\0 I suspect this is where Ruby inherited this feature from. -- Posted via http://www.ruby-forum.com/.
From: Raul Jara on 20 Feb 2010 11:49
Ahhh. I had assumed that the ruby parser kept a running list of defined methods/defined variables. Thanks for clearing that up. -- Posted via http://www.ruby-forum.com/. |