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

Add babelify to browserify to enable ES6 #239

Open
stuhlmueller opened this issue Oct 1, 2015 · 4 comments
Open

Add babelify to browserify to enable ES6 #239

stuhlmueller opened this issue Oct 1, 2015 · 4 comments
Milestone

Comments

@stuhlmueller
Copy link
Member

Node already supports many ES6 features. If we add babelify to our browserify transform, we can start using these features in our code. I've been using ES6 for another project and I think it allows for significantly more readable code in some situations.

ESLint (#225) is compatible with ES6 (using babel-eslint).

@null-a
Copy link
Member

null-a commented Oct 2, 2015

One possible complication is that ES6 syntax may not play nicely with our sweet.js integration.

@wuxianliang
Copy link

sweet.js is refactoring on Babel. sweet-js/sweet-core#485

@stuhlmueller
Copy link
Member Author

We can independently discuss whether to enable ES6 for the implementation and for webppl programs. (As I understand it, both are blocked right now by incompatibility with the sweet.js readableNames option.) If we enable ES6 for webppl programs, we could consider enforcing that all variables are declared as constants (e.g., const x = 1). This would make it more explicit that they can't be mutated (and are block-scoped, unlike var), and would move webppl closer to being a true subset of Javascript.

@null-a
Copy link
Member

null-a commented Nov 11, 2015

As I understand it, both are blocked right now by incompatibility with the sweet.js readableNames option.

In general I think that's right, since once we have HMC (#81) we'll be expanding macros in both.

I like the const idea. I tried it in a webppl program and surprisingly it seems to work already. It looks like it's because like var, const is parsed as a VariableDeclaration (but with its type field set to const), so while not officially supported things just happen to work out. Of course, relying on an accidental feature to stick around probably isn't a great idea, so waiting for full ES6 support seems sensible.

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