search

teal-language / tl

The compiler for Teal, a typed dialect of Lua
MIT License
2.02k stars 101 forks source link

Expose `Node` #734

Open Frityet opened 5 months ago

Frityet commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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