[Ruby] Improve keyword scopes

[deathaxe]

This PR applies the #1228 and tries to find proper solutions for some special keywords/situations where needed.

[FichteFoll]

If I'm correct and this depicts a class method (idk Ruby), then shouldn't this be storage.modifier?

[deathaxe]

I found examples the following example, which says something about to use that notation class << self just to avoid repetition of the class name in the method declaration.

Not sure whehter it should be scoped differently in such a situation.

class TestClass
  # bad
  def TestClass.some_method
    # body omitted
  end

  # good
  def self.some_other_method
    # body omitted
  end

  # Also possible and convenient when you
  # have to define many class methods.
  class << self
    def first_method
      # body omitted
    end

    def second_method_etc
      # body omitted
    end
  end
end

[FichteFoll]

Okay, that is weird, to say the least. Looks more like a keyword.control.context than a class declaration, though.

[deathaxe]

Yep. But I am unsure about using different scopes for the same keyword.

[FichteFoll]

Using different scopes for the same keyword is no problem for the in operator (or keyword) in Python, for example. We prioritize semantics over syntax anyway and the alternative scope would still be a keyword.

[FichteFoll]

Are you sure about that? in is imo a good example,
because it behaves entirely different.

for a in b:
    if 1 in a:
        pass

Unless you didn't mean to argue for the general case but about class in particular here.

[deathaxe]

Off Topic: I saw several languages scoping in as keyword.operator. While keyword.operator.logical makes sense I am not sure about the use case in the for statement.

In class << self the class keyword has the same meaning as with or using. It would then need to be scoped as keyword.control.[block|context].

Sorry, but I still don't feel comfortable with keyword.control.[exception|resource] as discussed in #1228 because the former alternatives seem to be a more general approach, which can be applied to more situations/languages without sematical conflicts (see python or the keywords below).

[djspiewak]

I generally am pretty happy to scope the same symbol differently in different contexts. A great example of this is => in Scala:

val f: Int => String = i => i.toString
//         ^^ keyword.operator.arrow
//                       ^^ storage.type.function.arrow.lambda

I think it's not at all unprecedented. (also, continuing my ongoing gripe with the names of scopes, the left arrow above is a type while the right arrow is a keyword indicating a lambda, but the scopes applied above are conventional and appropriate according to the guidelines)

Ruby is complicated and weird because it has things that are functions but behave like keywords, things that are keywords that behave like functions, and things that are neither that behave differently in different syntactic contexts. In general, I would say that the solution to the specific problems raised here (class and in) should be to scope them differently in the different contexts, biasing toward the differing semantics rather than toward the identical characters.

[FichteFoll]

keyword.control.[exception|resource] has been replaced by keyword.control.context.[exception|resource] in my mind (or, ideally, keyword.context.[exception|resource]). I just haven't made a definitive statement on that yet because I was collecting input on a new second-level scope.

Edit: Ignore exception in this post. This was probably just a mixup on my part.

[FichteFoll]

@djspiewak, you can add keyword.declaration to the second arrow, via #2156 (comment).

[wbond]

So the general consensus is that this is good to merge?

[deathaxe]

The two questions which we might need some feedback for are:

1. What do you think about the keyword.control.block as a general scope for the keywords do, begin and end? We also discussed keyword.control.context or @FichteFoll even suggested something within a new 2nd level scope keyword.context. There are some comments about it at [RFC] Add new scopes to "jumping" flow control keywords/statements. #1228. The discussion started with [RFC] Add new scopes to "jumping" flow control keywords/statements. #1228 (comment) about keywords like using, with, ... which open a new block of code or manipulate the context for identifier lookups. It continued with this PR at [RFC] Add new scopes to "jumping" flow control keywords/statements. #1228 (comment) when it turned out we need something really general for that.

2. The question about the scope for class << is still open. I currently decided to use storage.type.class keyword.declaration.class, but from the sematic aspect a scope from 1.) would be appropriate as well.

[FichteFoll]

We might also want to consider (also in the context of #1228) whether die and panic (and exit in other languages) do the same and should be unified to a subscope of keyword.control.flow instead of using keyword.control.flow.<keyword-name>. But that's not as significant and can be talked about later.

[wbond]

@deathaxe I like keyword.control.block for 1. For 2 keyword.control.context seems most appropriate since I am familiar with the mechanics of Ruby. That said, I would also be okay with storage.type.class keyword.declaration.class.

@FichteFoll If I had to pick, I'd do something like keyword.control.flow.termination.

[wbond]

On second thought, I think storage.type.class keyword.declaration.class is much more correct. While class is being passed a block, it is really re-opening the definition and using the block to append the definition.

[deathaxe]

So everything would be ready to merge then, if keyword.control.flow.termination is addressed to die, panic, etc.

I've choosen keyword.control.flow.throw for throw, raise and fail here.

[wbond]

Thanks @deathaxe and everyone who spent time reviewing!