ES6 modules proposal

[gkz]

Unfortunately import and export are already used in LS, and I don't want to create a breaking change in the 1.X line.

How would people feel if ES6 modules were supported using import! ... and export! ...? Sort of looks like require! ... and is the best alias I could think of.

For 2.X, backwards compatibility will be broken and we can revert to using import and export

[blvz]

I think it's the way to go for 1.X, though I'm more interested in LS 2.X. I'm willing to work on it, but I'm afraid I'll need some guidance.

[kay-is]

Another option would be a cli flag.

[igl]

Does 1.x really need it? I don't know of any runtime supporting es6-modules yet. I don't see why I would stop using something like browserify anytime soon even when there is support by half of the browsers. import! and export! sure looks like a hack and can be added when its needed.

[dead-claudia]

@igl Ember is written in it (and ES6 modules are the only decent option for imports), and Angular 2.0 will be (actually, in straight ES6). Several transpilers exist. V8 is currently working on implementing it as I type this (I've seen a few recent commits). Multiple relevant transforms exist for Browserify. It's definitely coming.

As for import!/export!, I think that's too much of a hack. I like the idea of 2.0 repurposing import and export, but couldn't this be factored into require!, with a couple simple modifications?

# ES6: import * as bar from 'foo';
# ES5: var bar = require('foo');
require! foo: {*: bar}

# ES6: import * as foo from 'foo'; var {bar} = foo;
# ES5: var foo = require('foo'), bar = foo.bar;
require! foo: {*, bar}

# ES6: import foo, {bar} from 'foo';
# ES5: Same as last example
require! foo: this, {bar} # or @, {bar}

# ES6: import bar, {baz} from 'foo';
# ES5: var bar = require('foo'), baz = bar.baz;
require! foo: bar, {baz}

# ES6: import bar from 'foo';
# ES5: var bar = require('foo');
require! foo: bar

Haven't yet really thought about export syntax, though, but simply allowing export default to represent default exports and export to represent named ones should work. The former could be represented as simply setting module.exports and if the named export statement was used, define exports as a pain object and effectively do module.exports <<< exports at the end.

[vendethiel]

Angular 2.0 will be (actually, in straight ES6)

Angular will be TypeScript, won't it be?

[dead-claudia]

Specifically AtScript, IIRC, but it transpiles to ES6 and Dart.

On Mon, Apr 20, 2015, 11:05 ven [email protected] wrote:

Angular 2.0 will be (actually, in straight ES6)

Angular will be TypeScript, won't it be?

— Reply to this email directly or view it on GitHub.

[vendethiel]

Specifically AtScript, IIRC

nope. They "merged" AtScript into TypeScript. And I don't think it'll transpile to Dart :-).

[dead-claudia]

Never mind then. I haven't really been keeping up with that specific area as much as I should have, anyways. I thought they were planning on having Angular 2.0 work with Dart as well, with effectively the same API. But anyways, I do know that Ember users have been running into problems with the ES6 module requirement, though.

On Mon, Apr 20, 2015, 11:42 ven [email protected] wrote:

Specifically AtScript, IIRC

nope. They "merged" AtScript into TypeScript. And I don't think it'll transpile to Dart :-).

— Reply to this email directly or view it on GitHub https://github.com/gkz/LiveScript/issues/705#issuecomment-94487911.

[kay-is]

I'm an Ember dev. I didn't use imports because I wanted to use LiveScript.

ATM I just concatinate all class files with Gulp and transpile them to JavaScript.

[vendethiel]

I think you can use import a if you really need to.

[kay-is]

Nice to know. Thank you :+1:

[dead-claudia]

I'm aware of import foo from 'bar'. It just looks ugly, IMHO. I also find require! foo: {default: foo} ugly, just as I find var foo = require('foo').default; and foo = require \foo .default ugly.

I still find V8's recent module implementation work really exciting 1.

Now, as for Angular 2, it is actually being written in AtScript, a literal ES6 superset with TypeScript-style type annotations and Traceur as the compiler. Their npm package readme explicitly references AtScript sources 2. TypeScript is not an ES6 superset (although that is being worked on 3). I do stand corrected in that it can still be used as a set of ES5 modules.

On Mon, Apr 20, 2015, 13:33 ven [email protected] wrote:

I think you can use import a if you really need to.

— Reply to this email directly or view it on GitHub https://github.com/gkz/LiveScript/issues/705#issuecomment-94517740.

[vendethiel]

Now, as for Angular 2, it is actually being written in AtScript

as I said:

nope. They "merged" AtScript into TypeScript

article here (which is good, imho)

[blvz]

What if 1.4 is released, then breaking changes are included in a "1.5", but released as 2.0 (for the sake of semver) and "LS2" becomes "LS3"?

[dead-claudia]

@vendethiel Thank you for the link. I still miss some sort of export default syntax, though. Even if it's not ES6.

On Mon, Apr 20, 2015, 15:32 Rafael Belvederese [email protected] wrote:

What if 1.4 is released, then breaking changes are included in a "1.5", but released as 2.0 (for the sake of semver) and "LS2" becomes "LS3"?

— Reply to this email directly or view it on GitHub https://github.com/gkz/LiveScript/issues/705#issuecomment-94548243.

[bianjp]

Really appreciate ES6 module support since I'm developing an application with Ember.js. import! and export! is acceptable. Have you made a decision? When will it be available?

[dead-claudia]

@gkz I like the idea of import! and export! as the transition syntax.

---

<aside> Hopefully, we don't wind up with an exclamation point explosion in LS...IMO it doesn't look pretty.

<deviation class="off-topic"> Although all the punctuation operators in more functional, less stateful languages can easily inhibit readability, IMHO. This is part of the reason why over-using ~~pointless~~point-free style without some restraint is considered bad practice in Haskell, since the code is hard to reason with down the road.

-- These are okay, and even preferred, since being more point-free simplifies
-- them.
double = (* 2)
concat = foldr (++) []

-- (Pointful equivalents of above)
double x = x * 2
concat [] = []
concat (xs:xss) = xs ++ concat xss

-- This is not okay
import Data.Function (on)
a = ...
f = (((chr . (+ a) . (`mod` 26) . (flip (-)) (2 * a)) .) . (. ((+) `on` ord))

-- (More acceptable version of above)
a = ...
f k t = chr $ a + (ord k + ord t - 2*a) `mod` 26

Above in LiveScript:

# These are okay, since being more point-free simplifies them.
double = (* 2)
concat = (.reduce (++), [])

# (Pointful equivalents of above)
double = (x) -> x * 2
concat = (list) ->
  if list.length then list[0] ++ concat list[1 to] else []

mod = (x, y) --> x - y * Math.floor x / y

# This is not okay
a = ...
f = (((.<<. 16 .>>. 16) . (+ a) . (`mod` 26) . (- 2 * a)) .) . (. (+))

# (More acceptable version of above)
a = ...
chr = (.<<. 16 .>>. 16)
f = (k, t) -> chr a + mod k + t - 2*a, 26

</deviation> </aside>

[vendethiel]

Well, we can think of a syntax like module export ... that wouldn't conflict.

[igl]

I am not convinced that 1.x needs es6 modules at all. Do only i feel like this?

Having require!/export for commonjs and import!/export! for es6 seems semantically confused.

[HosseinAgha]

2 years passed and still no body had time to implement import and export!
As a heavy LiveScript user I think language is not going to survive if it does not keep up with destination ecosystem.

[determin1st]

this change doesnt matter in frontend. browsers have global space, so everything is accessible. i dont know why node.js (ops, error, ppl who use it) choose compiled language style to import/export functions. imo, it wont survive in implemented environment. ES6 doesn't fix 0.1 + 0.2 == 0.3 like problems, they do something good, something bad and something irrelevant. so, dont worry.

[dead-claudia]

@determin1st It's way more common and useful in browsers (Webpack and Rollup) than in Node (Babel and Reify. Node already has a working, fully functional, fully featured module loader that has nearly everything you would ever need in one, and they've had it since practically day 1. Browsers do not - all they had were fetch, XMLHttpRequest, and dynamically added script elements.

[determin1st]

@isiahmeadows i take what functions i need from favorite libraries and KISS - put them in one include file - that's all, no need to study how that zoo works and transpiles 8) MDN says, that this feature import/export is not working in any browser. so it lives in abstract transpilator world. sure, node had module loader from day 1, as browsers had

[dead-claudia]

@determin1st

MDN says, that this feature import/export is not working in any browser

Well...it's mildly out of date, then.

Edit: Here's the Can I Use entry for it, which tells me that Chrome (as of 61) and Safari (as of 10.1) are shipping support for <script type="module"> and import/export support, and Edge and Firefox have support behind a flag.

[HosseinAgha]

@determin1st Webpack officially supports import and export and implements scope hoisting and tree shaking using static nature of ES6 import and export take a look here
If you are developing a large frontend application you definitely benefit from such feature even if browsers don't support it completely.

[determin1st]

@HosseinAgha I see it as a build environment, not a language itself. It will be cool if LiveScript (lsc) would be able to merge (.ls, .js) files into single (.js) file.

@isiahmeadows And this seems to be an eval() with cookies 8) What about use case? Something dynamic dynamic? I'm not there yet..

[dead-claudia]

@determin1st Read my edit, and please read up on ES6 modules and <script type="module">. It's shipping in two browsers already. Also, could you please quit slamming ES6 modules here, and instead reserve such questions and discussion in https://github.com/tc39/ecma262 and the es-discuss mailing list? They're not a LiveScript-specific deal - they're part of JS proper, quite a bit of tooling relies on it (like Ember's CLI), and you've made zero criticism that isn't about the general JS feature.

[bartosz-m]

Question to people wanting es6 module support:
Would you be interested in implementation in form of opt-in extension to livescript compiler?

I'm already using some plugins with my loader and in near future I'll code es6 modules plugin, if someone else beside me will use it I'll wait and gather some feedback about syntax.

[HosseinAgha]

@bartosz-m I really liked your micros workaround. nice job!
I also found your ide-livescript package, Do you still working on it?
Do you have any plans for a livescript-transform-esmodules?
I think the idea of micros can fix lots of problems as nobody is interested in or have time to add new features to keep this beautiful language alive.
I should also mention that LiveScript implementation is a bit complicated (you encounter operators and features that even expert LS developers have not seen in their lifetime 😄) and for LS specifically (that does not rely on giant companies support) not using a standard AST like babel generates a lot of issue.
my only hope was livescript-next but unfortunately it seems @dk00 gave up on that months ago.

[dk00]

I didn't give up.

Current version of livescript-next is good enough for my own projects, I'm happy with it now, and I have no spare time to work on it recently.

Feel free to ask usage questions or report bugs / suggest features. Any feedback are welcome 😄 .