[ruby-core:123398] [Ruby Bug#21618] Allow to use the build-in prism version to parse code

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


Earlopain (Earlopain _) wrote in #note-10:
> I don't think changing the default would be much of an improvement. You can't tell what people really want.

I *think* we can establish it's only 2 use cases:
* either they want the same as the running Ruby version, i.e they just want to parse code like the current Ruby parses code (and that's why I think that should be the default),
* or they want some specific other version, in which case they really need to specify it (e.g. "3.4").

I don't know of a realistic use case to parse with "latest version supported by Prism" on an older Ruby (especially considering that changes based on the Prism version),
that seems basically always an error to me (though it might accidentally work good enough for a while), but maybe I'm missing something?

So with that I think it means the default of "latest" is basically of no use, and therefore changing that to "current" fixes it for the first use case (probably the most common), where one expects `Prism.parse(code)` to parse code with the same syntax version as RUBY_VERSION.
For the second use case one need to be explicit anyway, so the default doesn't matter there.

> For now, I will just update places to use `RUBY_VERSION` since that is clearly more correct that not passing anything at all.

I think this is the way to go. If there is practical issue with that let's reconsider what to do to address it.

----------------------------------------
Bug #21618: Allow to use the build-in prism version to parse code
https://bugs.ruby-lang.org/issues/21618#change-114769

* Author: Earlopain (Earlopain _)
* Status: Open
* Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN
----------------------------------------
Prism is a multi-version parser, which is a great feature.

If one calls `Prism.parse("foo")`, it will always use the latest version prism knows about. This may or may not be the version that is currently executing. This is problematic when one wants to introspect code the same way that the currently running ruby version would.

Consider that some syntax will be disallowed in the next ruby version. I would have to specify the ruby version I want to parse as in order to not run into syntax errors: `Prism.parse("foo", version: RUBY_VERSION)`. But doing so is not feasable because `prism` is distributed out of sync with ruby itself. If the user already has prism in their lockfile, the user may run a prism version that doesn't yet know about lets say ruby 4.0 and thus raise. Similarly, it may parse as an older patch version that has subtle behaviour differences.

`ripper` does not have this issue because it is always tied to the ruby version and it is not distributed as a gem, so what the user has will always be exactly what ruby shipped with. I wish for a similar API that utilizes the prism version bundled with ruby itself.

Libraries like `rails` have moved from ripper to prism because of its superior developer experience but it risks breaking in unexpected ways with new `prism` versions that know about more recent syntax. `error_highlight` for example also suffers from the same defect.

It seems like prism currently has 34 methods that optionally take a version (per the rbi file). Many of these are trivial helper methods like `Prism.parse_success?` (does the parse result have any errors?). I would be happy with supporting only the minimal functions like `Prism.parse` and `Prism.parse_file`. Currently I don't have a use-case for any of the other methods. Pretty much just functions to mirror `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.compile`.

It would be optimal if I would be able to transparently call `Prism.parse("foo", version: "current")` (or maybe even have an unspecified version mean the build-in prism version) but I am not sure how feasable that is since I'm pretty sure logic for this would have to live in ruby itself.

@kddnewton does this feature request make sense? Do you have any other ideas/inputs?



-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/