[ruby-core:99436] [Ruby master Feature#15752] A dedicated module for experimental features

[ruby-core:99436] [Ruby master Feature#15752] A dedicated module for experimental features

[eregontp]

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


The existence of `RubyVM` prevents other Ruby implementations to be fully 100% compatible, because more and more gems start to rely on it.
So either:
* We move most of `RubyVM` to `ExperimentalFeatures` so that other Ruby implementations can implement it for compatibility (e.g., `AbstractSyntaxTree`, `InstructionSequence`).
  That also gives a nice way to experiment with not-yet-stable features/APIs.
* We are fine that other Ruby implementations have a `RubyVM` constant too. That will make it even less clear that `RubyVM` is experimental.

In practice, if CRuby exposes any API, then some gems might rely on it and with enough gems it becomes hard/impossible to remove it.
So if CRuby wants extra API for e.g. internal VM debugging, it should be added only with some special `./configure` flag.
That I think is the only way to prevent gems to (probably unknowingly) depend on CRuby-private APIs that are not meant to be used except for CRuby internal debugging.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-86891

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:99438] [Ruby master Feature#15752] A dedicated module for experimental features

[eregontp]

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


To clarify, by "move" I mean moving under `ExperimentalFeatures` but we could still e.g. have a deprecated constant under RubyVM to help transition.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-86893

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:99462] [Ruby master Feature#15752] A dedicated module for experimental features

[daniel]

Issue #15752 has been updated by Dan0042 (Daniel DeLorme).


Can I ask what would be so bad about having the `RubyVM` constant in other implementations? I mean, in itself the name is very general. Every implementation can be said to be a "Ruby VM".

If support for an experimental feature is indicated by `RubyVM.has_feature_xyz?`, an implementation can choose to return `false` for the moment. When the feature moves past the experimental stage the implementation can add it, and `RubyVM.has_feature_xyz?` can return true, and there's no need to move it out of the `ExperimentalFeatures` namespace.

_If_ the intention is to rename `RubyVM::AbstractSyntaxTree` to `AbstractSyntaxTree` once it's no longer experimental, then I agree it would make more sense as `Experimental::AbstractSyntaxTree`. But if `RubyVM::AbstractSyntaxTree` is intended as the final name then temporarily stuffing it into an `Experimental` namespace would be way more trouble than it's worth.

Honestly asking: what is the benefit of messing around with what seems to have become a de-facto standard?

(apologies in advance if I missed the point of all this)

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-86919

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:99463] [Ruby master Feature#15752] A dedicated module for experimental features

[eregontp]

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


Dan0042 (Daniel DeLorme) wrote in #note-18:
> Can I ask what would be so bad about having the `RubyVM` constant in other implementations? I mean, in itself the name is very general. Every implementation can be said to be a "Ruby VM".

It's a good question. My understanding is that `RubyVM` was really meant as the `JRuby` or `TruffleRuby` module of JRuby/TruffleRuby, i.e., a module specifically for CRuby-specific things.
I tried to rename it to CRuby for clarity in https://bugs.ruby-lang.org/issues/15743 but failed: https://bugs.ruby-lang.org/issues/15743#note-21

See also https://bugs.ruby-lang.org/issues/15743#note-7 which notes that about everything under `RubyVM` was meant to be CRuby-specific.
But since CRuby is the standard implementation, about any public API, including RubyVM will become used and depended on.
Even more so if the name doesn't imply "experimental/unstable".

I would like experimental APIs to be clearly marked as such, and RubyVM doesn't achieve that well at all.
In fact I would bet many users of RubyVM don't even know it's experimental, or don't even know it's CRuby-specific (I tried to document that, but people don't read the documentation all the time).

So if RubyVM becomes shared it will become clear it's no longer CRuby-specific experiments.
I'm fine with that, because RubyVM is already used in production by now (e.g., bootsnap).

I think as a result CRuby will no longer have a module for experimental features then.
Not necessarily a bad thing, as truly experimental APIs should probably be behind a `./configure` flag if developers are serious about not having gems depend on it.
And I think it's good that new APIs, even if experimental, consider about portability since we have more than 1 implementation in the Ruby ecosystem.


Adding `ExperimentalFeatures` would let CRuby and other implementations experiment in a shared namespace, which seems clearer for everybody.
It wouldn't prevent gems to depend on it, but at least the name clearly states the intention.

So, in summary I don't really mind either way.

I think if we make `RubyVM` a shared namespace then CRuby will need another module/way for experimental/CRuby-specific features.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-86920

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:99464] [Ruby master Feature#15752] A dedicated module for experimental features

[eregontp]

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


I think an important lesson the Ruby implementors have learned over time is that there are no CRuby-specific APIs, it's a myth.
Whatever was thought once as CRuby-specific will eventually be implemented on some other Ruby implementation, because they need it for compatibility.

There is definitely a need to introduce experimental not-yet-matured APIs.
RubyVM is not a great place for that, as experimental APIs might be completely unrelated to the VM.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-86921

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:99467] [Ruby master Feature#15752] A dedicated module for experimental features

[mame]

Issue #15752 has been updated by mame (Yusuke Endoh).


FYI: [Type-profiler](https://github.com/mame/ruby-type-profiler), which I'm developing for an experimental type inference tool for Ruby 3 types,  heavily depends upon `RubyVM::InstructionSequence` because it performs static analysis on MRI byte code.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-86923

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:99594] [Ruby master Feature#15752] A dedicated module for experimental features

[eregontp]

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


mame (Yusuke Endoh) wrote in #note-21:
> FYI: [Type-profiler](https://github.com/mame/ruby-type-profiler), which I'm developing for an experimental type inference tool for Ruby 3 types,  heavily depends upon `RubyVM::InstructionSequence` because it performs static analysis on MRI byte code.

Is there a reason to use bytecode instead of the AST (e.g., from `parser` or `RubyVM::AbstractSyntaxTree` which can be portable), which has more information?
It seems suboptimal to me to have any "Ruby 3 types project" depend on something like `RubyVM::InstructionSequence`, that will make it practically impossible to work on alternative Ruby implementations.
Also the bytecodes change regularly, so this will probably regularly break any project depending on it.

Note that it is orthogonal to this issue, any library using RubyVM could switch to ExperimentalFeatures easily (by `ExperimentalFeatures = RubyVM unless defined?(ExperimentalFeatures)`).

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-87071

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:99814] [Ruby master Feature#15752] A dedicated module for experimental features

[matz]

Issue #15752 has been updated by matz (Yukihiro Matsumoto).

Status changed from Open to Closed

As far as I understand, you want a place to separate features that do not only belong to `CRuby`, right?
But for example, we started `RubyVM::AbstractSyntaxTree` as a `CRuby` specific feature, it was natural for us to place it under `RubyVM`.
So it may be uncertain that the feature is implementation-specific or not from the start. So we have to discuss for each feature that can be shared among implementations (like `RubyVM::AbstractSyntaxTree`). We might give it a new name. In my opinion, we don't need a place like `ExperimentalFeature`, because it is not what we really need.

Matz.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-87336

* Author: Eregon (Benoit Daloze)
* Status: Closed
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:102278] [Ruby master Feature#15752] A dedicated module for experimental features

[eregontp]

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

Status changed from Closed to Open

See https://bugs.ruby-lang.org/issues/17500#note-8

I think it is very clear MRI (and other Ruby implementations as well) need a place to put new experimental APIs.

Right now, RubyVM is used for new experimental APIs, but that's unclear for users, and over time it won't be considered experimental or MRI-specific at all (see linked comment).
`RubyVM` can already not be considered experimental anymore, because e.g., `RubyVM::InstructionSequence` and `RubyVM::AbstractSyntaxTree` are used in gems.

So, how about adding an `Experimental` or `ExperimentalFeatures` module, and add new experimental APIs there, *instead* of in RubyVM?

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-90131

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:102281] [Ruby master Feature#15752] A dedicated module for experimental features

[naruse]

Issue #15752 has been updated by naruse (Yui NARUSE).

Status changed from Open to Feedback

We consumed about this topic too long. I want this topic as pending in a year.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-90133

* Author: Eregon (Benoit Daloze)
* Status: Feedback
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:102520] [Ruby master Feature#15752] A dedicated module for experimental features

[matz]

Issue #15752 has been updated by matz (Yukihiro Matsumoto).


Repeating myself, I don't think we need a place for experimental features. If we put experimental features in a certain place, we need to rewrite our programs when the feature graduated from the experimental state. It would be a pain for users who participate in experiments.

Matz.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-90416

* Author: Eregon (Benoit Daloze)
* Status: Feedback
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:102533] [Ruby master Feature#15752] A dedicated module for experimental features

[eregontp]

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


matz (Yukihiro Matsumoto) wrote in #note-27:
> If we put experimental features in a certain place, we need to rewrite our programs when the feature graduated from the experimental state. It would be a pain for users who participate in experiments.

This is already the case with RubyVM, which is currently used for at least some experimental features, so this argument is baseless (features that are under RubyVM and become no longer experimental should be moved too).

So I'm only asking that next time we think about adding some experimental feature under `RubyVM`, we add it under `Experimental` instead.
Does that sounds reasonable?
As I said, nobody knows if some API will always be MRI-specific, so RubyVM is a bad place anyway and has no advantages, it just confuses everyone.

If ruby-core doesn't want to do this, for me it's clear: RubyVM becomes de facto no longer experimental and no longer MRI-specific.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-90433

* Author: Eregon (Benoit Daloze)
* Status: Feedback
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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

[ruby-core:102898] [Ruby master Feature#15752] A dedicated module for experimental features

[naruse]

Issue #15752 has been updated by naruse (Yui NARUSE).


We consumed about this topic too long. I want this topic as pending in a year.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-90959

* Author: Eregon (Benoit Daloze)
* Status: Feedback
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



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