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

Expose Node #734

Open
Frityet opened this issue Jan 25, 2024 · 2 comments
Open

Expose Node #734

Frityet opened this issue Jan 25, 2024 · 2 comments
Labels
feature request New feature or request

Comments

@Frityet
Copy link

Frityet commented Jan 25, 2024

I would like to use Teal's Node type, but it doesn't seem to be exposed, is it possible to get this in the public API? It is returned by tl.parse() so it would make sense

@hishamhm hishamhm added the feature request New feature or request label Jan 25, 2024
@hishamhm
Copy link
Member

I've kept it private so far because the internal format changes every now and then (it's already different in the next branch, and I have further uncommitted changes in the pipeline)... Most importantly,exposing the Node record is equivalent to exposing the shape of the parse tree, which also changes.

I could expose Node, but with no guarantees of consistency from version to version. The compiler would help you catch incompatibilities in the record fields in client code that used it, but it wouldn't detect changes of the parse tree shape, especially because the Node tree stores sub-nodes in its array part, so it's not very typed. In the next branch I have turned Type into an interface and I am defining subtypes for different types as separate records (Type no longer contains {Type} as it did in the past), but I haven't done the same for Node (yet?). With separate Node subtypes it would be easier for client code to catch changes to the format at compile-time, but not all though—semantic changes could still go under the radar. In the end, nothing beats testing to see if things still work as intended from version to version...

@Frityet
Copy link
Author

Frityet commented Jan 25, 2024

I've kept it private so far because the internal format changes every now and then (it's already different in the next branch, and I have further uncommitted changes in the pipeline)... Most importantly,exposing the Node record is equivalent to exposing the shape of the parse tree, which also changes.

I could expose Node, but with no guarantees of consistency from version to version. The compiler would help you catch incompatibilities in the record fields in client code that used it, but it wouldn't detect changes of the parse tree shape, especially because the Node tree stores sub-nodes in its array part, so it's not very typed. In the next branch I have turned Type into an interface and I am defining subtypes for different types as separate records (Type no longer contains {Type} as it did in the past), but I haven't done the same for Node (yet?). With separate Node subtypes it would be easier for client code to catch changes to the format at compile-time, but not all though—semantic changes could still go under the radar. In the end, nothing beats testing to see if things still work as intended from version to version...

I think even having an unstable exposed Node is alright, just being able to traverse and use the AST is so useful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants