From: "mame (Yusuke Endoh) via ruby-core" Date: 2023-09-12T20:37:57+00:00 Subject: [ruby-core:114704] [Ruby master Misc#19772] API naming for YARP compiler Issue #19772 has been updated by mame (Yusuke Endoh). Hi @kddnewton kddnewton (Kevin Newton) wrote in #note-22: > From this thread and others, this is my understanding of the requirements: > > * The `YARP` name is not good, since we don't want `YA`- prefixes in production code. There may be a communication error. More precisely, * The `YARP` name is not good as a built-in name, e.g., built-in constant names (like `String`). * The `YARP` name is acceptable as a gem name. If the Ruby API of YARP is provided as a gem, there is no need to rename it. > * We could like to be able to improve the Ruby API without having to go through the Ruby release cycle. Whose requirement is this? I wasn't sure who was asking for it. This requirement is new to Ruby and makes the discussion complicated. If YARP is a built-in feature, I recommend that you drop this requirement. If YARP is a gem, you are free of course. > * We would like for users to be able to parse Ruby code as various versions of Ruby have previously parsed Ruby code. > * We would like for users to be able to parse Ruby code exactly as the current version of Ruby is parsing Ruby code. As @eregon says, I think that two different non-current Ruby grammer versions should be available at the same time. The parser gem allows that. I am concerned that if there is something that the parser gem can do but YARP cannot, then the original goal of making YARP a universal parser might not be achieved. > Here are the kinds of changes we would like to be able to make outside of the Ruby release cycle: > > * We would like to be able to add fields to the various nodes. > * We would like to be able to add flags to the various nodes. Sorry, what are "fields" and "flags" here? > * We would like to be able to change the Ruby API to provide additional functionality/classes. Note that, if YARP is a built-in feature, all these changes will require Matz's approval. With that in mind, I would never recommend doing it outside of the Ruby release cycle. If YARP is a gem, you can do it freely. > Here are the steps I would like to take to address these requirements: > > 1. I would like to rename the `YARP` gem to `Prism`. You may change it if you wish, but * As a built-in name, neither YARP nor Prism is allowed. The only name accepted for a built-in name so far is `Ruby::Parser`. * As a gem name, both YARP and Prism are okay. (However, Ruby::Parser is not a suitable name for a gem.) So I think it will solve nothing. > 2. I would like to change the way we build Ruby objects from both the C API and the serialization API. Currently when we build Ruby objects from these APIs, we call `rb_class_new_instance` directly with the fields coming back from the parser. Instead, I will change this to call a Ruby method (either `XXXNode.new` or `YARP.build_xxx_node`) that will instantiate those objects. > 3. When we add fields to nodes, we will patch the factory method to handle the various combinations coming back from the various APIs. Those factory methods will check the target Ruby version and handle the fields appropriately for that version of Ruby. > 4. When we add flags to nodes or change the Ruby API to provide additional functionality, nothing should have to change. > 5. I would like to add `YARP.parse_native` which will take advantage of the previous bullets here to specify that the target Ruby version should be exactly the version of Ruby that is currently running. This seems interesting. Let me confirm. I understood it as follows: * We introduce, as a built-in feature, only one method to invoke the YARP parser linked into Ruby. Let's call it `RubyVM.invoke_yarp(src, handler)` as a tentative name. * `RubyVM.invoke_yarp` parses the `src` string and calls `handler.build_xxx_node(*child_nodes)` when creating a node. For example, `RubyVM.invoke_yarp("1 + x")` calls 1. `handler.built_integer_node("1")` (To be precise, it should pass a code location rather than a code fragment) 2. `handler.built_local_var_node("x")` 3. `handler.built_call_node(:+, (the result of 1), (the result of 2))` and finally returns the result of 3. Everything else (such as node class definitions, helper methods, etc.) is placed in the YARP gem. `YARP.parse_native` calls `RubyVM.invoke_yarp`. Is my understanding correct? It's similar to Ripper's SAX API. If this is correct, it would be good if you could focus your proposal on the `RubyVM.invoke_yarp` spec. ---------------------------------------- Misc #19772: API naming for YARP compiler https://bugs.ruby-lang.org/issues/19772#change-104536 * 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/