Note how the error message for problem 0x00 doesn't tell you that the ' at the end of the line is *wrong*, instead what it tells you is that the string literal (which it started to try to parse as soon as it saw the " symbol) was never terminated:

    
    examples/hello.rb:1: syntax error found (SyntaxError)
    > 1 | puts "Hello World'
        |                   ^ unterminated string meets end of file
    
  

This is because it's technically just fine to have a ' inside of a double quoted string,
for example "It's a wonderful world".

And so the parser doesn't try to make sense of what the ' means at all in this code, it just looks for a " to end the string and never finds it, so it hits the end of the file.

Having a mental model for how the parser will apply a particular rule is helpful.

In the case of single quoted string literals, it's "keep scanning forward in the file until you hit either a backslash or a closing single quote, treating everything else as raw unprocessed text.

In problem [0x01] the intention is clearly to make use of string interpolation.

But in a single quoted string, nothing is treated as a special character except the backslash which is used for escaping purposes (e.g. 'It\'s a wonderful World')

So the string parses fine because it doesn't know or care what's in it, even though it leads to the wrong output by not actually doing the interpolation operation.

This also explains why the parser actually does not immediately fail to complete the string with the missing ' in problem [0x02], but instead, completes it in the wrong place. It happily includes a bunch of lines of code as raw text in the string, only stopping once it hits an unrelated ' farther down the file.

In isolation, the accidental use of else instead of end in add_item method is easy to spot:

def add_item(item)
  @items.push(item)
else

But if it's invalid code, why does the colorization seem to work as normal? Because in fact, else is a valid keyword to use within a method definition, it just needs to follow a rescue segment.

def coin_flip
  [:heads, :tails].sample == :heads && raise
rescue
  "The coin landed on heads"
else
  "The coin landed on tails"
end

How often is this feature used? To be honest, I can't remember the last time I've seen it in the wild. So I'd guess not often at all.

But it's still a valid language construct, and so it's part of what the parser will look for when trying to break a method definition down into its parts.

Things get even more complicated when you throw into the mix the bit of trivia that method definitions technically can include other method definitions, which do not get applied until they've been executed at runtime:

def coin_flip
  [:heads, :tails].sample == :heads && raise
rescue
  "The coin landed on heads"
else
  def lucky_method_call
    puts "You got lucky!"
  end
  "The coin landed on tails"
end

puts coin_flip

puts lucky_method_call

This code will either print "The coin landed on heads" and then crash because lucky_method_call was never defined, or it'll print "You got lucky!" followed by "The coin landed on tails."

Either way, it would most likely make others reading your code scratch their heads, so it is not recommended.

However, because it is possible to write this program, the parser must allow for it in its ruleset.

Just for good measure, throw in one more Ruby feature that is sometimes not obvious how it works even though it comes up often... the ability to write arbitrary expressions anywhere within a class definition.

class Flipper
  include SomeMixin  #1

  p rand(1..100)     #2
end

When written in macro-like style as shown in #1, it isn't obvious from the outside in that include is actually a method call, not some special keyword.

In fact, it's just an ordinary Ruby expression, so writing something like #2 right in the middle of the class definition is also totally acceptable.

I've used a contrived example here to not get too bogged down in details, but this feature is useful at times -- it's just not one that you'd typically reach for daily, so it might not be front of mind while reading code until something forces you to focus on it unexpectedly.

Taking all three of these Ruby features into account, and changing the indentation of the file to be closer to what the parser "sees" in [0x03], a different shape emerges:

class Bag
  # ...

  def add_item(item)
    # ...
  else
    def take_item
      # ...
    end
  end

  bag = Bag.new
  # ...

Looked at this way, it becomes logical why Ruby crashes with error messages about the else keyword not being valid without a rescue, and the missing end for the Bag class rather than for the add_item method.

The more you understand the range of features Ruby supports, the easier it will be to cut through the noise when you see feedback from the parser that doesn't match your intentions.

But simply being aware of the fact that the scope of possible valid programs is far broader than the scope of reasonable and useful programs will go a long way in breaking your mind's tendency to focus on what it meant to write rather than how code actually works.