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

strongly typed AST #7

Open
UniqueFool opened this issue May 21, 2016 · 3 comments
Open

strongly typed AST #7

UniqueFool opened this issue May 21, 2016 · 3 comments

Comments

@UniqueFool
Copy link

I actually renamed the other question, but I was looking at the verbosity levels because I was really trying to get a dump of the strongly-typed ASTs to see how everything hangs together, could you maybe provide a pointer how to do that ?
I realize that there are different kinds of ASTs depending on the stage of the solver - I am mainly interested in the BFS implementation that traverses the AST to compare candidate trees.

In particular, I would like to learn how new objects/types are represented at the AST level.

Thank you

@UniqueFool
Copy link
Author

This is admittedly a little offtopic, but how difficult do you think would it be to use inductive for creating a different syntax tree format for a subset/dialect of ECMAScript and how would you approach doing something like that ?
Or rather, would you instead suggest manually converting the generated JavaScript code by post-processing the generated code ?

Actually, I am currently doing the latter using a sed script (which works well enough), so this is more of a hypothetical question, mainly inspired by looking at your template/macro system and the way you described it would work internally, i.e. wondering if it could be directly told to use a different format for certain expressions of the AST

In the context of JavaScript/ECMAScript6, the point could be using default arguments or making use of other new features (think for/let loops), but also the other idea of using named function arguments. So this isn't totally unrelated to the current use-case.

Speaking more generally: how difficult would it be to literally use the macro/template system in conjunction with the type system to make use of more recent/experimental JavaScript/node features ?

Thank you

@omphalos
Copy link
Owner

I think this is probably doable in one of two ways. Either use something like babel-register with a babel plugin that supports eval. I'm not sure if one exists for arbitrary strings. It's possible to write one.

Another option: eval in the codebase is handled by the evalUtil file. The important use of this is in Specification. I could expose an option that lets the consumer override the evalUtil call with a custom implementation if they want. At that point it would be up to the consumer to pass a function that calls into the babel parser API (or their parser of choice).

@UniqueFool
Copy link
Author

thanks, that should suffice as a pointer so that I can have a look.

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

No branches or pull requests

2 participants