Issue #19772 has been updated by mame (Yusuke Endoh). kddnewton (Kevin Newton) wrote in #note-13:
Going forward, the only people that will be using the Ruby API of the parser will be tool developers. (For example, formatters like Syntax Tree, linters like Rubocop, static analysis tools like Steep.) In order to provide a good experience for them, we will need to be able to provide bug fixes and features outside of the Ruby release cycle.
What changes are you thinking of providing outside of the Ruby release cycle? If it is a critical bug fix that involves parsing results, we need to cut a patch release of Ruby in any way. For other fixes and improvements, there is no need to rush, so a patch release (or minor release for new features) is still acceptable, I think. It is great to provide a good experience for tool developers, but we should keep in mind that it is a trade-off for stability. I think the current discussion is likely to provide a built-in Ruby API like `Ruby::Parser`. But any changes to it should be under the Ruby release cycle. In other words, in principle, bug fixes should be done in patch releases, and improvements and new features should be done in minor releases. In fact, the `ruby_3_3` branch is only writable by the branch maintainers, and changes are made by requesting backports from the branch maintainers. It would be difficult to change this system for YARP. I think the following is simplest for Ruby developers (except YARP developers) and Ruby users: * yarp.gem supports multi-version as the parser gem does:`YARP::Ruby33.parse`, `YARP::Ruby34.parse`, `YARP::Ruby35.parse`, ... and `YARP::CurrentRuby.parse`. * Ruby 3.3 links with only the C implementation part of `YARP::Ruby33`. Ruby itself does not provide a Ruby API like `Ruby::Parser`. While this is more work for the YARP developer, it has the advantage of eliminating the need to go through backports to change and improve the Ruby API. ---------------------------------------- Misc #19772: API naming for YARP compiler https://bugs.ruby-lang.org/issues/19772#change-104388 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal ---------------------------------------- We are working on the YARP compiler, and have [the first PR ready](https://github.com/ruby/ruby/pull/8042) which introduces the YARP compile method. Our only outstanding question before merging it is about naming. How should we expose the public API for YARP's compile method? Potential suggestions: 1. YARP.compile 2. RubyVM::InstructionSequence.compile(yarp: true) 3. RubyVM::InstructionSequence.compile_yarp 4. Any of the above options, with a name other than yarp (please suggest an alternative) Regarding option 1, which would mirror `YARP.parse`, is the top level constant `YARP` acceptable? cc @matz @ko1 -- https://bugs.ruby-lang.org/