[ruby-core:124800] [Ruby Misc#21825] Status of the universal parser implementing the Prism API

[ruby-core:124800] [Ruby Misc#21825] Status of the universal parser implementing the Prism API

[Eregon (Benoit Daloze) via ruby-core]

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


What does "Rejected" means in this case?
No plan to do this?
Does that mean Universal Parser no longer has the intention to become the Ruby parser used by everything?

Having to maintain both parsers and both bytecode compilers is not an overhead we can ignore forever.

----------------------------------------
Misc #21825: Status of the universal parser implementing the Prism API
https://bugs.ruby-lang.org/issues/21825#change-116414

* Author: Eregon (Benoit Daloze)
* Status: Rejected
----------------------------------------
I'm opening this issue to discuss and ask the status of the universal parser implementing the Prism API.

[Matz has agreed that going forward the official parser API for Ruby will be the Prism API](https://railsatscale.com/2024-04-16-prism-in-2024/),
therefore if `parse.y` wants to remain a longer-term possibility it will have to somehow implement the Prism API.
(this is not new, I recall discussing this at RubyKaigi 2024 with matz and @yui-knk)

The Prism API covers clearly at least the Ruby API `Prism::Node`.
But also if the universal parser is a complete alternative for Prism (if not it wouldn't really be *universal* and lots of existing Prism usages couldn't switch to it),
it would need to also support the Java, JavaScript and Rust APIs of Prism.
And also the AST part of the C API of Prism too.
I think the most sensible and maybe the only realistic way is for `parse.y` to generate a Prism C AST using the AST structs from Prism:
https://github.com/eregon/prism-generated/blob/generated/include/prism/ast.h such as `struct pm_call_node`.
That way, all the higher-level APIs and code in the prism gem can be reused as-is and the only real difference is whether using the [prism.c](https://github.com/ruby/prism/blob/main/src/prism.c) parser or the `parse.y` parser, but the output would be the exact same.

When that happens it would actually become possible to just switch the parser with `--parser=`, vs currently switching the CRuby source-to-bytecode compiler as well.
IOW, there would be no need for the massive duplication in `compile.c` and `prism_compile.c`, we'd keep only `prism_compile.c` (and probably rename it), since `parse.y` would also generated a Prism C AST.



-- 
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/lists/ruby-core.ml.ruby-lang.org/