From: "Eregon (Benoit Daloze) via ruby-core" Date: 2023-09-21T08:05:31+00:00 Subject: [ruby-core:114859] [Ruby master Misc#19772] API naming for YARP compiler Issue #19772 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-29: > He came up with an idea to enable a user to use multi-version yarp gems at a time by Namespace on read (#19744) in the future. So he said that the yarp gem doesn't have to support multi-version. That's an interesting way to solve it but this seems clearly not for the near future (I think that is several years): * This feature is not merged yet, it might be difficult to implement reliably (there are so many shenanigans with symbol loaders/linkers/etc and inconsistencies between platforms, if the approach works on one platform it might not on another platform) * It might be even more difficult to implement on some other Rubies like JRuby and TruffleRuby. Both of these use the FFI gem and not the C extension for yarp, and I'm really not sure it's possible to load 2+ librubyparser in the same process with FFI without everything conflicting or segfaulting (and even if it happens to work for 2 versions on some platform, how to be confident it will be the case for other versions/platforms?). Until that is figured out I think we should assume this approach to be non-viable for other Rubies than CRuby which I think should be a blocker. * This would require extensive changes in RubyGems and Bundler, which might take a while as well and might be difficult for compatibility reasons. I'm not sure many Rubyists want a Bundler that feels like `npm`/`node_modules` with every dependency duplicated N times (+ of course the longer bundle times, etc). We should probably ask the opinion of RubyGems & Bundler maintainers in #19744. Also, until all the above is done, this doesn't solve that e.g. the parser gem couldn't rely on yarp and add it as a gem dependency then, and the same for all other tools which want to use yarp but don't want to force a given version (and if they do they will then be incompatible with other tools). So I think this solution is unrealistic for the near future. OTOH there seems to be a lot of work on yarp to also worry about multi-versions support now. So maybe multi-versions support in yarp could be added later, e.g. after the CRuby 3.3 release. Until then YARP can only parse the "Ruby 3.3" dialect which seems an OK limitation for the time being. > In light of the above, here is a suggestion. > > * How about having the ruby repository mirror only the C implementation of YARP, but not Ruby API? It should be used only when `ruby --enable-yarp` or something are given. > * How about bundling the "prism" gem as a bundled gem to provide a Ruby API for YARP? I think this is good and should be done anyway. It is also easier to support YARP like that in JRuby & TruffleRuby, as the YARP Ruby API is then "just a normal gem" and can be updated with `gem install` etc. In fact JRuby & TruffleRuby are both integrating YARP and at least so far they assumed that yarp would be a bundled gem, only C+Java files (so not the Ruby API) are imported in JRuby & TruffleRuby repositories. ---------------------------------------- Misc #19772: API naming for YARP compiler https://bugs.ruby-lang.org/issues/19772#change-104707 * 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/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/