Issue #21795 has been updated by mame (Yusuke Endoh). I have merged the PR. Thank you all for the feedback! @kddnewton Thank you for the review! I do think there are cases where the parent of a BlockNode is needed, but my impression is that yielding it as the second argument of the block would make the API a bit confusing. As for parse.y, I would like to leave the decision to matz. @eregon Since you are repeating the same argument in multiple places, let me repeat mine as well, for the record. I hope this will be the last time. `node_id` is clearly superior to `source_range` for its very purpose: identifying a node. This is because multiple nodes can be located at exactly the same `source_range`. This is a fatal flaw for an identifier. I am aware that you claim that nodes at completely overlapping locations can be distinguished by using the context. In my view, however, that is nothing but saying that source_range is a broken identifier that cannot identify a node without context. `node_id` is perfect for the purpose of identifying a node, except for the parser version mismatch problem. I do understand the claim that `source_range` is more robust across parser versions. But please think calmly: the current situation, where a built-in feature of the interpreter cannot use the parser that the interpreter itself uses, is clearly abnormal. I find it strange to argue that `source_range` is superior based on such an abnormal situation. (By the way, I think this problem may be solved in the future when `Ruby::Box` becomes stable: by loading the default gem prism in a `Ruby::Box` and using its `Prism::Node` definitions, the parser of the interpreter itself would become available. I think it is too early at this point, though.) Also, you repeatedly call `node_id` "CRuby internal", but it is now information that Prism officially provides. I do not say that other Ruby implementations should adopt `node_id` (that is up to you and other implementers), but you should admit that it is not so exotic. So I think it is clear that, to put it mildly, `source_range` is not obviously superior to `node_id`. I believe it is a trade-off, as matz says. ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795#change-118434 * Author: kddnewton (Kevin Newton) * Status: Closed ---------------------------------------- I would like to propose a handful of methods for retrieving ASTs from various objects that correspond to locations in code. This includes: * Proc#ast * Method#ast * UnboundMethod#ast * Thread::Backtrace::Location#ast * TracePoint#ast (on call/return events) The purpose of this is to make tooling easier to write and maintain. Specifically, this would be able to be used in irb, power_assert, error_highlight, and various other tools both in core and not that make use of source code. There have been many previous discussions of retrieving node_id, source_location, source, etc. All of these use cases are covered by returning the AST for some entity. In this case node_id becomes an implementation detail, invisible to the user. Source location can be derived from the information on the AST itself. Similarly, source can be derived from the AST. Internally, I do not think we have to store any more information than we already do (since we have node_id for the first four of these, it becomes rather trivial). For TracePoint we can have a larger discussion about it, but I think it should not be too much work. In terms of implementation, the only caveat I would put is that if the ISEQ were compiled through the old parser/compiler, this should return `nil`, as the node ids do not match up and we do not want to further propagate the RubyVM::AST API. The reason I am opening up this ticket with 5 different methods requested in it is to get approval first for the direction, then I can open individual tickets or just PRs for each method. I believe this feature would ease the maintenance burden of many core libraries, and unify otherwise disparate efforts to achieve the same thing. -- https://bugs.ruby-lang.org/