Professional Web Applications Themes

No difference between .. and ... flip/flop operators? - Ruby

I thought .. meant inclusive and ... meant 'not including matching lines'. Why do these snippets both do exactly the same thing: irb(main):032:0> File.open('filename') {|f| irb(main):033:1* f.each_line{|l| irb(main):034:2* puts l if l=~/BEGIN/ .. l=~/END/ irb(main):035:2> } irb(main):036:1> } Output: 10 BEGIN PATTERN eleven 12 thirteen 14 END PATTERN irb(main):026:0> File.open('filename') {|f| irb(main):027:1* f.each_line{|l| irb(main):028:2* puts l if l=~/BEGIN/ ... l=~/END/ irb(main):029:2> } irb(main):030:1> } Output: 10 BEGIN PATTERN eleven 12 thirteen 14 END PATTERN Both .. and ... produced the same output. I would have expected the output of the second snippet to be: eleven 12 thirteen ??? Phil...

  1. #1

    Default No difference between .. and ... flip/flop operators?


    I thought .. meant inclusive and ... meant 'not including matching lines'.

    Why do these snippets both do exactly the same thing:

    irb(main):032:0> File.open('filename') {|f|
    irb(main):033:1* f.each_line{|l|
    irb(main):034:2* puts l if l=~/BEGIN/ .. l=~/END/
    irb(main):035:2> }
    irb(main):036:1> }

    Output:
    10 BEGIN PATTERN
    eleven
    12
    thirteen
    14 END PATTERN


    irb(main):026:0> File.open('filename') {|f|
    irb(main):027:1* f.each_line{|l|
    irb(main):028:2* puts l if l=~/BEGIN/ ... l=~/END/
    irb(main):029:2> }
    irb(main):030:1> }

    Output:
    10 BEGIN PATTERN
    eleven
    12
    thirteen
    14 END PATTERN

    Both .. and ... produced the same output. I would have expected the
    output of the second snippet to be:

    eleven
    12
    thirteen

    ???

    Phil
    Phil Guest

  2. #2

    Default Re: No difference between .. and ... flip/flop operators?

    When constructing ranges of values (such as Fixnums), ... excludes the
    end, while .. includes it.

    So:

    (1..10).each { |i| puts i }

    prints 1 - 10, while:

    (1...10).each { |i| puts i }

    prints 1 - 9.

    As far as I know, .. and ... are identical in flip-flops (which I
    thought was in the Pickaxe, but I
    can't find it right now, so maybe I just read it here a while ago).

    However, regarding this and your last mail, I believe Matz is
    considering taking out flip-flops
    in the future (in Rite, maybe?), so you may want to look into other ways
    of doing stuff (if you're
    worried about it running in 2.0 and beyond, that is).

    - Dan


    Dan Guest

  3. #3

    Default Re: No difference between .. and ... flip/flop operators?

    Dan Doel wrote:
     

    Which is a darn shame.


    Michael Guest

  4. #4

    Default Re: No difference between .. and ... flip/flop operators?

    On Jan 31, 2004, at 09:38, Michael campbell wrote:
     
    >
    > Which is a darn shame.[/ref]

    previous.sub(/a darn shame/, 'wonderful')

    This rubyist will be much happier when the flip-flop is _buried_.


    Nathaniel

    <:((><



    Nathaniel Guest

  5. #5

    Default Re: No difference between .. and ... flip/flop operators?

    Nathaniel Talbott wrote:
     
    >>
    >>
    >> Which is a darn shame.[/ref]
    >
    >
    > previous.sub(/a darn shame/, 'wonderful')
    >
    > This rubyist will be much happier when the flip-flop is _buried_.[/ref]

    Why? If you didn't like it, why would you use it?


    Michael Guest

  6. #6

    Default Re: No difference between .. and ... flip/flop operators?

    On Jan 31, 2004, at 10:58, Michael campbell wrote:
     
    >
    > Why? If you didn't like it, why would you use it?[/ref]

    An interesting question; I'll try to give a coherent answer. First of
    all, I have to read other people's code, and if they use obscure,
    hard-to-understand constructs that I have to look up every time, it
    makes it much harder to grok what's going on. Since I learn most
    libraries by reading their code (and I often do that even when they
    have top-notch docs - I'm just that kind of guy), opaque language
    constructs are particularly biting.

    Secondly, and really more importantly, is the issue of aesthetics.
    Every bit of syntax, whether I use it or not, affects and reflects the
    language as a whole. One of the things I like about Ruby the language
    is that the syntax tends to explain itself. I don't use or even see for
    loops very much in Ruby code, but when I run across one, it's pretty
    obvious what's going on. The flip-flop gives me no external clues as to
    its modus operandi, and I don't like the way affects Ruby, by making a
    bit of the gem opaque, and how it reflects Ruby, when someone sees it
    and goes, "WHAT IN TARNATION IS THAT THING?!?" and I have to explain
    that Ruby unfortunately gained a few of the "P" language's bad points
    along with a lot of its good points.

    That's why I personally would like to see it gone, and good riddance.
    You, of course, are welcome to root for a pardon, but I just wanted to
    make sure the other side of the aisle was represented :-)

    Just my $0.02,


    Nathaniel

    <:((><



    Nathaniel Guest

  7. #7

    Default Re: No difference between .. and ... flip/flop operators?

    Nathaniel Talbott wrote:

     

    I don't find it either of those.

     

    nor do I have to do that.

     

    I understand and respect your point here, but is it not a nicer way of saying "I find hard to grok, so it should be restricted from _everyone's_ use"?




    Michael Guest

  8. #8

    Default Re: No difference between .. and ... flip/flop operators?

    On Jan 31, 2004, at 12:37, Michael campbell wrote:
     
    >
    > I don't find it either of those.
    >

    >
    > nor do I have to do that.[/ref]

    Point taken. But then, I know from talking to others that my opinion on
    it's clarity and my need to look it up are not isolated occurrences.

     
    >
    > I understand and respect your point here, but is it not a nicer way of
    > saying "I find hard to grok, so it should be restricted from
    > _everyone's_ use"?[/ref]

    Well, I'd phrase it more as, "It's hard for a lot of people to grok, so
    we should find a better construct for it." I don't think the
    functionality should go away, but I think it should be implemented as a
    library function, not a piece of the syntax. Or, if it is syntax, that
    that syntax should be more inherently self-apparent.

    I'd also add the sentence, "I find it dog-ugly, so I will do everything
    within my power to see that it DIES!" It's this that really drives
    me... the aesthetics of the construct just make me want to wretch. It's
    an amalgamation of several different pieces of the language that just
    don't make sense together. Oh, and it has internal state that those
    various pieces don't. It just doesn't seem to fit in. Now if I was the
    only one who had this opinion, then it should certainly stay... but
    apparently matz agrees with me at some level. I'm bummed that some
    people will miss it, but that's the fun of language design - you get to
    "Tick off all of the people, some of the time." I'm glad he's the
    designer and not me :-)


    Nathaniel

    <:((><



    Nathaniel Guest

  9. #9

    Default Re: No difference between .. and ... flip/flop operators?

    In article <cwru.edu>, Dan Doel <cwru.edu> wrote: 

    identical as in there is no difference in behavior between them?
     

    taking out flip-flops?! But they seem so useful in certain situations.
    Why get rid of them? (Matz?)

    Phil
    Phil Guest

  10. #10

    Default Re: No difference between .. and ... flip/flop operators?

    In article <ws>,
    Nathaniel Talbott <ws> wrote: 
    >>
    >> Which is a darn shame.[/ref]
    >
    >previous.sub(/a darn shame/, 'wonderful')
    >
    >This rubyist will be much happier when the flip-flop is _buried_.
    >[/ref]

    Why? Care to elaborate? If you don't like them, you don't have to use
    them, right? But if you do like the feature it saves a good bit of
    coding.

    Phil
    Phil Guest

  11. #11

    Default Save the flip/flop op!

    In article <ws>,
    Nathaniel Talbott <ws> wrote: 
    >>
    >> Why? If you didn't like it, why would you use it?[/ref]
    >
    >An interesting question; I'll try to give a coherent answer. First of
    >all, I have to read other people's code, and if they use obscure,
    >hard-to-understand constructs that I have to look up every time, it
    >makes it much harder to grok what's going on. Since I learn most
    >libraries by reading their code (and I often do that even when they
    >have top-notch docs - I'm just that kind of guy), opaque language
    >constructs are particularly biting.
    >
    >Secondly, and really more importantly, is the issue of aesthetics.
    >Every bit of syntax, whether I use it or not, affects and reflects the
    >language as a whole. One of the things I like about Ruby the language
    >is that the syntax tends to explain itself. I don't use or even see for
    >loops very much in Ruby code, but when I run across one, it's pretty
    >obvious what's going on. The flip-flop gives me no external clues as to
    >its modus operandi, and I don't like the way affects Ruby, by making a
    >bit of the gem opaque, and how it reflects Ruby, when someone sees it
    >and goes, "WHAT IN TARNATION IS THAT THING?!?" and I have to explain
    >that Ruby unfortunately gained a few of the "P" language's bad points
    >along with a lot of its good points.
    >
    >That's why I personally would like to see it gone, and good riddance.
    >You, of course, are welcome to root for a pardon, but I just wanted to
    >make sure the other side of the aisle was represented :-)
    >[/ref]

    And just what would you replace that functionality with? It seems to me
    that it would take several lines of code to replace the following
    functionality:

    f.each_line {|l|
    if l=~/BEGIN/ .. l=~/END/
    #do something in this range of lines
    end
    }

    If you know the meaning of what '..' is doing here, it seems quite clear.
    It's also clear to anyone coming from Perl to Ruby as to what is
    going on here. Without the flip/flop op that code code has to become
    something like:

    #untested
    begin_state = false
    f.each_line {|l|
    if l=~/BEGIN/
    begin_state = true
    elsif l=~/END/
    begin_state = false
    end
    if begin_state == true
    #do something in this range of lines
    end
    }


    I've got to introduce a state variable and more conditionals and my one
    line has grown into 5. Add another flip/flop operator to your parsing
    code and you add another state variable and a bunch more lines. It's not
    uncommon to use several of these when parsing.

    Save the flip/flop!

    Phil
    Phil Guest

  12. #12

    Default Re: No difference between .. and ... flip/flop operators?

    In article <ws>,
    Nathaniel Talbott <ws> wrote: 
    >>
    >> I don't find it either of those.
    >>
    >> 
    >>
    >> nor do I have to do that.[/ref]
    >
    >Point taken. But then, I know from talking to others that my opinion on
    >it's clarity and my need to look it up are not isolated occurrences.
    >

    >>
    >> I understand and respect your point here, but is it not a nicer way of
    >> saying "I find hard to grok, so it should be restricted from
    >> _everyone's_ use"?[/ref]
    >
    >Well, I'd phrase it more as, "It's hard for a lot of people to grok, so
    >we should find a better construct for it." I don't think the
    >functionality should go away, but I think it should be implemented as a
    >library function, not a piece of the syntax. Or, if it is syntax, that
    >that syntax should be more inherently self-apparent.
    >
    >I'd also add the sentence, "I find it dog-ugly, so I will do everything
    >within my power to see that it DIES!" It's this that really drives
    >me... the aesthetics of the construct just make me want to wretch. It's
    >an amalgamation of several different pieces of the language that just
    >don't make sense together. Oh, and it has internal state that those
    >various pieces don't. It just doesn't seem to fit in. Now if I was the
    >only one who had this opinion, then it should certainly stay... but
    >apparently matz agrees with me at some level. I'm bummed that some
    >people will miss it, but that's the fun of language design - you get to
    >"Tick off all of the people, some of the time." I'm glad he's the
    >designer and not me :-)
    >[/ref]

    Not only will it be missed, it will break a _lot_ of code if it's removed.
    I wasn't at RubyConf2003, so I'm not sure, but rumor has it that Matz
    isn't worried about breaking code in Ruby 2.0 (Rite), similar to what the
    Perl folks are doing with Perl6.0, but it would be nice to have some sort
    of mechanism where we can discuss the proposed changes that will break
    things. At least in the case of Perl6 there will be a way to run legacy
    code (Pony and/or a translator). Will this sort of approach be available
    in Ruby 2.0? This issue needs more community discussion.


    Back to the flip/flop issue:
    What exactly do you propose to replace it with?

    If you propose to replace this piece of syntax with a library function,
    where should that function live?

    Maybe in File or IO somewhere? (like so):

    File.open("filename") {|f|
    f.each_line_between(/BEGIN/,/END/) {|l|
    #do something between BEGIN, END
    #but what if you want to nest another one in here?
    end
    }

    However, that doesn't help when you've got several flip/flops (or
    nested flip/flops) looking for
    several different ranges of lines in a file like:

    File.foreach("filename") {|f|
    f.each_line {|l|
    if l=~/BEGIN/ .. l=~/END/
    #between BEGIN and END
    if l=~/def/ .. l=~/end/
    #between def and end inside BEGIN .. END block
    end
    end
    }
    }

    I don't see any way that an 'each_line_between' type method would be able
    to do this since it lives in File. Perhaps we should introduce an
    'each_line_between' for simple cases, but I don't see how it can replace
    the flip/flop op for the nested case (which is commonly done).

    I really hope Matz will reconsider.

    Phil
    Phil Guest

  13. #13

    Default Re: Save the flip/flop op!

    Phil Tomson wrote: 
    > And just what would you replace that functionality with?[/ref]

    Phil,

    I'm with Nathaniel. Save the functionality but please KILL the
    syntax. Only a perler could love it. (No offense meant.)

    I haven't thought this through yet. But let's do it with a
    method call.

    #untested
    f.set_context(/BEGIN/,/END/)
    f.each_line do |l|
    if f.in_context
    # do something with l...
    else
    # whatever
    end
    end


    Comments, Phil? Nathaniel? Others?


    Hal



    Hal Guest

  14. #14

    Default Re: Save the flip/flop op!

    In article <com>,
    Hal Fulton <com> wrote: 
    >> And just what would you replace that functionality with?[/ref]
    >
    >Phil,
    >
    >I'm with Nathaniel. Save the functionality but please KILL the
    >syntax. Only a perler could love it. (No offense meant.)[/ref]

    Not everything in Perl was bad (No offense taken). Matz obviously got a
    lot of inspiration from Perl. It's a good thing, actually, because these
    sorts of things attract a lot of Perl people looking for something better.
    They find some familiar things to make them feel at home and some
    different things to make it seem worthwhile to switch. Given that Perl
    has the most users, this can be a good thing for Ruby to gain more users.

    The flip/flop operator is a powerful piece of syntax. Just because
    something isn't well understood doesn't mean we should just get rid of it,
    it probably means it needs to be doented better for those who aren't
    familiar with Perl. To those of us who came from Perl (and I suspect
    that's a lot of us) it seems pretty natural and so far I have yet to see
    any good way of replacing it. The attitude I'm hearing is that since some
    peole don't understand it, even those who do shouldn't get to use it which
    certainly doesn't see fair to those who gain a lot of benefit from it.

    Certainly I can agree, for example, that the $* vars need some synonyms in
    English (and I think most of them already have them), but I also think they
    should still be available for legacy sake.
     

    The same question remains: is it nestable? Would I be able to do:


    #untested
    f.set_context(/BEGIN/,/END/)
    f.each_line do |l|
    if f.in_context
    # do something with l...
    f.set_context(/def/,/end/)
    if f.in_context
    #do something between def and end inside of BEGIN END block
    end
    else
    # whatever
    end
    end

    It doesn't seem like it. If not, then we've lost a lot of functionality.

    Also, I would suggest that whatever new mechanism is introduced that there
    still be a way to use the old one, even if it means something like:

    require "pre2.0"
    #...
    if line=~/BEGIN/ .. line=~/END/

    #...

    ....problem is that in this case we're talking about some syntax being
    deprecated and you can't get that back with a require in this case AFAIK.


    Phil
    Phil Guest

  15. #15

    Default Re: Save the flip/flop op!

    Hal Fulton wrote:
     
    >> And just what would you replace that functionality with?[/ref]
    >
    >
    > Phil,
    >
    > I'm with Nathaniel. Save the functionality but please KILL the
    > syntax.[/ref]

    Well, I like the syntax, because I've trained my brain to understand it. Would Ruby be as easy to read as it is now if all the reserved words were not in English (or in ANY known "natural" spoken language)? My point here is that anything you dont yet understand, take the time to understand it. The reason Ruby is easy now is only because you have the understanding of the context in/for which it was designed.

    That said, if there were some method call which can do all of what (scalar)".." does, then fine. The beauty of this operator is that each one has its own state (that I don't have to burn a variable to maintain on my own), so you can nest them, have several going at once, use them completely outside of the common per-line file processing model, etc.

    I THINK Hal's solution might work outside the file-by-line context

    Every solution presented thus far assumes I want to use it only for processing text files line by line, when in reality, I might need it for many other things, totally unrelated to that.
     

    Playing devil's advocate...By extension then, I propose to also put up all the unixism's as candidates for removal too, as only people who are familiar with unix could love those too. I have to read others' code, and I just have to grab a manual every time I see Enumerable#grep.



    Michael Guest

  16. #16

    Default Re: Save the flip/flop op!

    Michael campbell wrote: 

    Well, it runs counter to the rest of Ruby.

    Since x..y is a range, and never evaluates to false or nil, I would
    expect it always to be true.
     

    That may be. (My solution of course was extremely half-baked.) In that
    case, I'd suggest a class for that purpose. A class as general-purpose
    as possible.
     
    >
    > Playing devil's advocate...By extension then, I propose to also put up
    > all the unixism's as candidates for removal too, as only people who are
    > familiar with unix could love those too. I have to read others' code,
    > and I just have to grab a manual every time I see Enumerable#grep.[/ref]

    I see your point, but I don't admit the correspondence. (My turn to play
    devil's advocate.)

    I didn't mean it was ugly and obtuse because it came from Perl. Many
    Perlism are easy to grasp. I'd be lost without =~ and regex literals.

    I meant it was ugly and obtuse, and no one would ever think otherwise
    unless he was used to Perl.

    As for the Unixisms: There are some I have trouble with, and I have used
    Uniux off and on since the early 80s.

    I don't know if you're serious about "grep" or not. My only complaint
    with it is the name. A unixism which has a nonintuitive name should
    perhaps have an intuitive alias.

    This reminds me of a BBS I was designing with a friend back in 1990 or
    so. We wanted to put in a scheduling mechanism for the sysop, and we
    debated how to implement it and what to call it. "Call it 'cron'," he
    said. "We are *not* calling it 'cron'," I told him.


    Hal



    Hal Guest

  17. #17

    Default Re: No difference between .. and ... flip/flop operators?

    Phil Tomson wrote:
     
    Yes, that's what I meant.

    As for all the stuff about what to replace it with and such (not just
    the parent post, but many others)...

    Some of the examples given can be done almost as easily without flip
    flops, as long as you don't insist on doing things within a loop.
    I realize this isn't the general case, but sometimes they turn out
    that way, for instance:
     

    This can be done by something like this (borrowing from your modified code):

    File.open("filename") do |f|
    str = f.readlines
    m = /\n\n/.match str
    in_header = m.pre_match
    in_body = m.post_match
    end

    This is as short as your flip flop code, and in fact, I can eliminate 1
    line.

    I also cooked up a little magic in an attempt to reproduce flip flops on my
    own. It, of course, doesn't work as well as real flip flops. Here's my code:

    module Kernel
    def between(a, b, &blk)
    within = false
    proc do |l|
    within = true if a === l
    blk.call l if within
    within = false if b === l
    end
    end
    end

    With this, the following two pieces of code produce identical output:

    lines.each { |l|
    puts l if l=~/BEGIN/ .. l=~/END/
    }

    lines.each &between(/BEGIN/, /END/ { |l|
    puts l
    }

    Further, you can technically chain together #between calls to make
    nested flipflops, but it looks very ugly. It's not as general as
    flip flops, nested or otherwise, either, so I'll let this stew for
    a while and see if I can come up with any hideous code that makes
    homebrew flip flops look nice.

    As for the devil's advocate talking about Unix idioms as methods,
    I'd point out that I can define my own #grep and use it, so you'd
    have to look it up anyway. I cannot define my own Ruby syntax based
    on other languages. Just a little devil's advocate back at you. :)

    I, for one, don't have a strong opinion about whether flip flops
    should be in the language. From the perl code posted, it looks like
    that's where it's taken from. Matz is also considering taking out
    some other perlisms, I believe (like certain $ variables), so
    maybe this is something else he took from perl that he wishes he
    didn't. However, I'd note that taking this out isn't a catastrophe.
    Most languages don't have such an idiom, and they do fine. And,
    maybe we can even figure out something to replace it that isn't
    too bad from either side's perspective, given that Ruby is quite
    able to be modified by itself for things like this.

    Sorry for the long post.

    - Dan


    Dan Guest

  18. #18

    Default Re: No difference between .. and ... flip/flop operators?

    Dan Doel wrote:
     

    I can't speak for Matz, but my impression is that the perlisms
    belonged in there, but are now wearing thin. Ruby is approxmiately
    ten years old, and there are many things that are acceptable for
    five-year-olds but not ten-year-olds. :)

    As for the swearing variables, I have never liked the idea of
    changing the behavior of a piece of code or a library function by
    altering the value of a global. After all, why are global variables
    usually considered bad?

    As for the flipflop issue, I favor a solution that makes sense in
    terms of normal Ruby syntax and semantics.

    Given that only false and nil are false, and a range is never nil,
    why should

    if x..y
    puts "yes"
    else
    puts "no"
    end

    ever print "no"?


    Just my opinion.

    Hal



    Hal Guest

  19. #19

    Default Re: No difference between .. and ... flip/flop operators?

    On Jan 31, 2004, at 16:51, Dan Doel wrote:
     
    > Yes, that's what I meant.[/ref]

    Actually there is a difference... see:


    http://sean.chittenden.org/programming/ruby/programming_ruby/
    language.html

    Search for "Ranges in Boolean Expressions" (this was missing from the
    online pickaxe at rubycentral.com - not sure why).

    If someone can explain the difference in a meaningful way, I'd be
    grateful... I have enough trouble with the flip-flop as it is, and now
    this!


    Nathaniel

    <:((><



    Nathaniel Guest

  20. #20

    Default Re: Save the flip/flop op!

    Hal Fulton wrote:
     

    I have no stance to debate that, but I'd wager that for virtually every construct in ruby 1 person considers within "the ruby way", there would be a set of people who disagree.
     

    That I can concede as an inconsistency.
     
    >
    >
    > That may be. (My solution of course was extremely half-baked.) In that
    > case, I'd suggest a class for that purpose. A class as general-purpose
    > as possible.[/ref]

    I'm open to that. As I said, so far, the people who have disliked the operator have only provided solutions to the stated examples of its use, not a general solution replacement.

     

    *chuckle* I realized what you were saying...about 30 minutes too late so apologies there. That said however, how many weeks on ruby-talk do you see pass WITHOUT a question re: regexs of some sort? What exactly about the regex syntax is within the sphere of "the spirit of ruby", where a scalar ".." is not? Which is easier to learn? To read?

     

    More so than regexes?
     

    No, not serious in the slightest, except from a purely academic standpoint.

    The point I'm attempting to make is along the lines of "whose ox is getting gored?"

    ".." in a scalar context is ugly and obtuse, and yet people are willing to put up with names like "grep", regexs, and a myriad of other things that they would accept as perfectly natural, and only because that's their personal context and area of familiarity.


    Michael Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. flip flop operator and assignment
    By Phil in forum Ruby
    Replies: 15
    Last Post: February 4th, 09:25 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139