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

(Optional) type information #57

Open
chicoxyzzy opened this issue Sep 3, 2018 · 2 comments
Open

(Optional) type information #57

chicoxyzzy opened this issue Sep 3, 2018 · 2 comments

Comments

@chicoxyzzy
Copy link
Member

chicoxyzzy commented Sep 3, 2018

Binary AST could hold additional type information for variables, parameters and return types. This can help VMs do some optimizations ahead of time. Of course types should be statically validated but potentially this static analyse could be done by the same toolchain as used for binary AST creation. Was this idea considered?

@kannanvijayan-zz
Copy link
Collaborator

I've had this on my mind. Not in terms of some explicit support for type-annotations, but rather some generic facility for annotating the AST in-line with extension attributes.

These could be used to associate various pieces of information that could be used by tooling (stripped before release), and allow for a simple and straightforward processing of a single data structure across a variety of transformations and annotations.

You could do type annotations, in-line source-notes (for debug builds, reducing workflow complexity and number of artifacts), or any other arbitrary data.

Now, whether it's feasible in practice or not is something that requires careful consideration. I can sense some of the counter-arguments that might be made (e.g. possibility of hidden payloads in BinAST files, security issues, etc.). It's a good idea but it needs to be thought about carefully.

@Yoric
Copy link
Collaborator

Yoric commented Sep 6, 2018

Yes, we had early specs on how to store/strip such data with the previous format.

On the other hand, it's low-priority at the moment. We first want to ship something that works fast, and then we'll think of additional metadata!

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

3 participants