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

Transpiler strategy #8

Closed
littledan opened this issue Apr 4, 2019 · 7 comments
Closed

Transpiler strategy #8

littledan opened this issue Apr 4, 2019 · 7 comments

Comments

@littledan
Copy link
Member

What should be the strategy for implementing this proposal in transpilers? I think it'd make sense to include a high-level design doc in this repository, but maybe outside the README. Perfect value semantics will not be possible; what compromises do we recommend?

@rricard
Copy link
Member

rricard commented Apr 4, 2019

Yep, I'm thinking about trying to play with babel and https://github.com/bloomberg/constant.js/, I'll try to draft that out

@mheiber
Copy link
Contributor

mheiber commented Aug 14, 2019

@cknight may be interested in this based on #18 (comment)

@rricard
Copy link
Member

rricard commented Dec 23, 2019

With @rickbutton's efforts on babel, I think we now have a good idea of the strategy: we either compile to everything around records and tuples are library calls or we can try to intern the data structures (with a risk of leaking memory without WeakRefs). For parsing, Rick already has a PR for Babel: babel/babel#10865

EDIT: typo on Weakrefs

@rricard rricard closed this as completed Dec 23, 2019
@littledan
Copy link
Member Author

Did you consider documenting the transpiler strategy? In particular, there are some caveats of using this with transpilers, but I think they are reasonable tradeoffs. Ideally, there'd be someplace people can go to find documentation for this.

@rricard
Copy link
Member

rricard commented Dec 24, 2019

Do you think this proposal would be the best place for this? If yes, I can reopen the issue with the note this should be docuemnted (and @rickbutton should do it!)

@rickbutton
Copy link
Member

Since the experimental polyfill and transform will live here, the documentation should live in the same place. I will make sure to write up the documentation as soon as I get a chance.

@littledan
Copy link
Member Author

@rricard @rickbutton That all sounds good to me.

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

4 participants