Issue #15743 has been updated by Eregon (Benoit Daloze).


mame (Yusuke Endoh) wrote:
> I'm negative against the rename for some reasons.

Thank you for your feedback. I will reply inline.

> 1) CRuby/MRI is a popular name, not an official name.  In fact, `RUBY_ENGINE` is `"ruby"`.

Yes, `ruby`, not `Ruby`. For me `Ruby` means the language, and `ruby` is CRuby/MRI's executable.
So `RubyVM` feels wrong to me, because it does not mean (at least in the current situation), a general-purpose "Ruby language VM namespace".

Maybe we should have such a common namespace for experimenting with portable experimental features, but that is another discussion.
It certainly shouldn't be named `RubyVM` as that would introduce a lot of confusion.

> 2) A casual user is not recommended to use RubyVM.  You, a designer of JRuby, TruffleRuby, etc., can (or should) ignore a library that is using RubyVM.

But we cannot, end users use whatever is available in MRI, including RubyVM. Some gems use RubyVM.
Thinking end users will only use what they should is a dream, the reality is alternative Ruby implementations need to implement as much as possible like CRuby for compatibility.
And it's not always obvious `RubyVM` makes their code non-portable, so they should only use it as last resort,
knowing it will likely never work that way on other Ruby implementations.

Similarly problematic: `TracePoint#instruction_sequence`, which is a core method, returns a RubyVM::InstructionSequence, which can only work on CRuby.

> 3) Some APIs in RubyVM, e.g., RubyVM::AbstractSyntaxTree, might be compatible among some implementations, if you want.

Let's see:
* RubyVM::InstructionSequence is a representation of the MRI/CRuby/YARV bytecode. I don't think we can reproduce this on e.g., TruffleRuby, where there is no Ruby bytecode involved.
* RubyVM::AbstractSyntaxTree exposes the internal CRuby AST. I'm pretty sure other Ruby implementations have a slightly different AST while parsing. Ripper seems the portable version of this.
* RubyVM::MJIT is obviously specific to MJIT, not a general JIT (e.g., RubyVM::MJIT.pause doesn't make much sense without MJIT).
* RubyVM::OPTS, DEFAULT_PARAMS and INSTRUCTION_NAMES all return MRI-specific information, which make little sense for other Ruby implementations (e.g., INSTRUCTION_NAMES with no bytecode?).
* RubyVM.stat returns a Hash containing MRI-specific values, such as `global_method_state`, which simply doesn't exist on TruffleRuby.

This is very clear: basically none of these APIs were designed with Ruby implementation portability in mind.
And this is fine, I am not against MRI experimenting with MRI-specific APIs,
but I would like them to be clearly marked as such, and RubyVM doesn't achieve that.

> If the namespace is split, a user must follow them.

I think that is a good thing, implementation-specific parts would be clear in the code.

> 4) The name of CRuby is already used: https://rubygems.org/gems/cruby

I think we can ignore that, we're not creating a gem, and that seems an old unmaintained rubyforge project.

> Of course, JRuby, TruffleRuby, etc. are all "Ruby VMs". I think you can use the namespace "RubyVM" as you like.

I think that would be confusing, as currently basically everything under `RubyVM` is MRI-specific (and not implementable on TruffleRuby).
Anyway, I'm fine to define things on the TruffleRuby module for now,
my real concern is it's not clear for users and even for us that RubyVM is CRuby-specific, and I want to fix that.

> A library that is truly serious to use `RubyVM` will (or should) check `RUBY_ENGINE`.  Or, if you are still worried, you may want to use a namespace `RubyVM::JRuby` and `RubyVM::TruffleRuby`.

But I would expect many don't, because they think `RubyVM` makes sense for "the Ruby language" while it's actually only meaningful on CRuby.

----------------------------------------
Bug #15743: RubyVM should be renamed to CRuby
https://bugs.ruby-lang.org/issues/15743#change-77456

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: Next Major
* ruby -v: ruby 2.6.2p47 (2019-03-13 revision 67232) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
My understanding is that `RubyVM` is supposed to only exist on MRI/CRuby, and not on any other Ruby implementation.
In fact, almost all features under `RubyVM` are not realistically implementable on other major Ruby implementations (JRuby, TruffleRuby, Rubinius).

Unfortunately, the name doesn't reflect that it is specific to CRuby, e.g., JRuby/TruffleRuby/Rubinius are also "Ruby VMs".
And as a result it is not clear for many Ruby users that RubyVM is CRuby-specific.

The documentation is also unclear:
```
The RubyVM module provides some access to Ruby internals. This module is
for very limited purposes, such as debugging, prototyping, and research.
 Normal users must not use it.
```

So I propose to rename RubyVM to CRuby.
That way, it is clear for everyone that this module is CRuby-specific.
It's also consistent with the JRuby module, the TruffleRuby module and the Rubinius module.

Proposed migration path:

* Introduce CRuby as an alias of RubyVM on `trunk`, and deprecate the RubyVM constant on `trunk` (for 2.7).
* Remove `RubyVM` in Ruby 3.0.

What do you think?

cc @ko1 @k0kubun @headius



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>