Consider making location explicit.

I've been using this gem quite a bit recently.

I'm also looking at parsing C/C++ using clang into the same format, with the goal of providing a unified index for symbol lookup (as much as is possible).

In practice, it seems to me that an AST is (almost) always tied to some kind of source "location". I know there are cases where an AST is completely detached from actual code, but that is not, in my experience, the most common use case.

Have you considered whether it would make sense to expose a generic Location abstraction in the AST gem, that would cover multiple use cases?

In more concrete terms, making an interface for:

class AST::Node
  attr :location
end

# Introduce:

class AST::Location
  # Generic handling of source code, e.g. getting textual value, etc.
end

When I come to implementing a parser for C++ using the AST gem, I'm either going to have to roll my own location class with the same interface as the parser gem, or, preferably, follow some standard set out by the AST gem. The benefit would make it easier for converting an AST back into source code.

Essentially, what I'm proposing, is whether we can move a very light amount of location interface abstractions into the AST gem, such that parsing other languages could expose a shared interface for accessing location details.

Start by reviewing the proposed AST::Node location attribute and the AST::Location interface in the issue, then read the surrounding comment discussion for an agreed direction. Done would require a decided, shared location abstraction that supports the stated source-location and textual-value use cases, but the issue does not identify files or tests.