Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename haschildren() to is_leaf() #483

Merged
merged 1 commit into from
Aug 7, 2024
Merged

Rename haschildren() to is_leaf() #483

merged 1 commit into from
Aug 7, 2024

Conversation

c42f
Copy link
Member

@c42f c42f commented Aug 7, 2024

Unfortunately, haschildren(x) was a terrible name because it's not testing the same thing as numchildren(x) == 0!

In our ASTs

  • Leaves of the tree correspond to tokens in the source text
  • Internal nodes are containers for a range of tokens or other internal nodes.

Occasionally we can have internal nodes which have no tokens and thus have numchildren(node) == 0. These are, however, still "internal nodes" and we have haschildren(node) === true for these which makes no sense!

Unfortunately, `haschildren(x)` was a terrible name because it's not
testing the same thing as `numchildren(x) == 0`!

In our ASTs
* Leaves of the tree correspond to tokens in the source text
* Internal nodes are containers for a range of tokens or other internal
  nodes.

Occasionally we can have internal nodes which have no tokens and thus
have `numchildren(node) == 0`. These are, however, still "internal
nodes" and we have `haschildren(node) === true` for these which makes no
sense!
@c42f c42f added the breaking label Aug 7, 2024
@c42f c42f merged commit d8796c6 into main Aug 7, 2024
36 checks passed
@c42f c42f deleted the caf/haschildren->is_leaf branch August 7, 2024 06:16
c42f added a commit that referenced this pull request Aug 7, 2024
Here I commit to a more consistent but simpler child access API for
syntax trees, as informed by the JuliaLowering work so far:

* `is_leaf(node)` is given a precise definition (previously
  `!haschildren()` - but that had issues - see #483)
* `children(node)` returns the child list, or `nothing` if there are no
  children. The `nothing` might be seen as inconvenient, but mapping
  across the children of a leaf node is probably an error and one should
  probably branch on `is_leaf` first.
* `numchildren(node)` is documented
* `node[i]`, `node[i:j]` are documented to index into the child list

We distinguish `GreenNode` and its implementation of `span` from
`SyntaxNode` and its implementation of `byte_range` and `sourcetext` -
these seem to just have very different APIs, at least as of now.

I've deleted the questionable overloads of multidimensional `getindex`
and the `child` function in favor of single dimensional getindex. I
don't know whether anyone ever ended up using these. But I didn't and
they didn't seem useful+consistent enough to keep the complexity.

I've kept setindex! for now, to set a child of a `SyntaxNode`. Though
I'm not sure this is a good idea to support by default.
c42f added a commit that referenced this pull request Aug 7, 2024
Here I commit to a more consistent but simpler child access API for
syntax trees, as informed by the JuliaLowering work so far:

* `is_leaf(node)` is given a precise definition (previously
  `!haschildren()` - but that had issues - see #483)
* `children(node)` returns the child list, or `nothing` if there are no
  children. The `nothing` might be seen as inconvenient, but mapping
  across the children of a leaf node is probably an error and one should
  probably branch on `is_leaf` first.
* `numchildren(node)` is documented
* `node[i]`, `node[i:j]` are documented to index into the child list

We distinguish `GreenNode` and its implementation of `span` from
`SyntaxNode` and its implementation of `byte_range` and `sourcetext` -
these seem to just have very different APIs, at least as of now.

I've deleted the questionable overloads of multidimensional `getindex`
and the `child` function in favor of single dimensional getindex. I
don't know whether anyone ever ended up using these. But I didn't and
they didn't seem useful+consistent enough to keep the complexity.

I've kept setindex! for now, to set a child of a `SyntaxNode`. Though
I'm not sure this is a good idea to support by default.
c42f added a commit that referenced this pull request Aug 9, 2024
Here I commit to a more consistent but simpler child access API for
syntax trees, as informed by the JuliaLowering work so far:

* `is_leaf(node)` is given a precise definition (previously
  `!haschildren()` - but that had issues - see #483)
* `children(node)` returns the child list, or `nothing` if there are no
  children. The `nothing` might be seen as inconvenient, but mapping
  across the children of a leaf node is probably an error and one should
  probably branch on `is_leaf` first.
* `numchildren(node)` is documented
* `node[i]`, `node[i:j]` are documented to index into the child list

We distinguish `GreenNode` and its implementation of `span` from
`SyntaxNode` and its implementation of `byte_range` and `sourcetext` -
these seem to just have very different APIs, at least as of now.

I've deleted the questionable overloads of multidimensional `getindex`
and the `child` function in favor of single dimensional getindex. I
don't know whether anyone ever ended up using these. But I didn't and
they didn't seem useful+consistent enough to keep the complexity.

I've kept setindex! for now, to set a child of a `SyntaxNode`. Though
I'm not sure this is a good idea to support by default.
c42f added a commit that referenced this pull request Aug 9, 2024
Here I commit to a more consistent but simpler child access API for
syntax trees, as informed by the JuliaLowering work so far:

* `is_leaf(node)` is given a precise definition (previously
  `!haschildren()` - but that had issues - see #483)
* `children(node)` returns the child list, or `nothing` if there are no
  children. The `nothing` might be seen as inconvenient, but mapping
  across the children of a leaf node is probably an error and one should
  probably branch on `is_leaf` first.
* `numchildren(node)` is documented
* `node[i]`, `node[i:j]` are documented to index into the child list

We distinguish `GreenNode` and its implementation of `span` from
`SyntaxNode` and its implementation of `byte_range` and `sourcetext` -
these seem to just have very different APIs, at least as of now.

I've deleted the questionable overloads of multidimensional `getindex`
and the `child` function in favor of single dimensional getindex. I
don't know whether anyone ever ended up using these. But I didn't and
they didn't seem useful+consistent enough to keep the complexity.

I've kept setindex! for now, to set a child of a `SyntaxNode`. Though
I'm not sure this is a good idea to support by default.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant