Thus far each of the prospective edge cases relevant to the proposal have
been technically solved, save for duplicate identifier names and exports
from the same file, which appears to be avoidable.

Have no "faith" in anything, therefore "good" and "bad" preceding "faith"
are as irrelevant as "good" or "bad".

You can use what is available now and write your own language in your spare
time
(What programming languages have been created by PPCG users?
https://codegolf.meta.stackexchange.com/q/6918) though beware ("Anyone,
from the most clueless amateur to the best cryptographer, can create an
algorithm that he himself can't break." -Schneier, Bruce (1998-10-15). Memo
to the Amateur Cipher Design
<http://www.schneier.com/crypto-gram-9810.html#cipherdesign>. Cryptogram
newsletter. (aka Schneier's Law)

On Mon, Jun 3, 2019 at 4:12 AM kai zhu <kaizhu256 at gmail.com> wrote:

> you would need to introduce a new language-syntax that hints delimited
> module-scope, e.g.
>
> ```js
> /*
>  * es-module.rollup.js
>  *
>  * example rolling-up es-modules with [hypothetical] pragma
>  * "use module_scope xxx";
>  * which would be web-compat and minifier-friendly
>  */
>
> "use module_scope ./aa.js";
> // foo is scoped inside module_scope ./aa.js
> var foo = ...
> ...
>
> "use module_scope ./bb.js";
> // foo is scoped inside module_scope ./bb.js
> var foo = ...
> ...
> ```
>
> i'll be honest.  i'm not really proposing this language-syntax in
> good-faith, as javascript is already chock-full of confusing-features that
> are distracting/harmful to UX-workflow programming.
>
> i'm mainly criticizing tc39 for their design-decision pushing through
> es-modules, and how disruptive it is to operationalize (natively, w/o
> transpiling) in production-systems.  web-development could've stayed
> simpler if the committee had done absolutely nothing.  people would've
> continued using es5-style rollups (w/ yui/amdjs-like module-loaders), and
> devop-folks wouldn't be forced to deal with import-maps and http2-push to
> solve a problem that shouldn't have existed.
>
>
>
> On Sun, Jun 2, 2019 at 9:25 PM guest271314 <guest271314 at gmail.com> wrote:
>
>> > but that requires coordination among modules, which is not always
>> possible.  the idea is to inline/rollup es-modules that may not have come
>> from same developers (and whom are unaware their es-modules collide w/
>> others when rolled-up).
>>
>> How do you intend to know the names of the identifiers to import without
>> "coordination" and check for duplicate identifier names and duplicate
>> exports?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190603/ca64341d/attachment.html>

Thus far each of the prospective edge cases relevant to the proposal have
been technically solved, save for duplicate identifier names and exports
from the same file, which appears to be avoidable.

Have no "faith" in anything; "good" and "bad" preceding "faith"
are as irrelevant as "faith" is.

You can use what is available now and write your own language in your spare
time
(What programming languages have been created by PPCG users?
https://codegolf.meta.stackexchange.com/q/6918) though beware ("Anyone,
from the most clueless amateur to the best cryptographer, can create an
algorithm that he himself can't break." -Schneier, Bruce (1998-10-15). Memo
to the Amateur Cipher Designer <http://www.schneier.com/crypto-gram-9810.html#cipherdesign>. Cryptogram newsletter. (aka Schneier's Law)).

Thus far each of the prospective edge cases relevant to the proposal have
been technically solved, save for duplicate identifier names and exports
from the same file, which appears to be avoidable.

Have no "faith" in anything, therefore "good" and "bad" preceding "faith"
are as irrelevant as "good" or "bad" and "faith" are.

You can use what is available now and write your own language in your spare
time
(What programming languages have been created by PPCG users?
https://codegolf.meta.stackexchange.com/q/6918) though beware ("Anyone,
from the most clueless amateur to the best cryptographer, can create an
algorithm that he himself can't break." -Schneier, Bruce (1998-10-15). Memo
to the Amateur Cipher Designer <http://www.schneier.com/crypto-gram-9810.html#cipherdesign>. Cryptogram newsletter. (aka Schneier's Law)).

Thus far each of the prospective edge cases relevant to the proposal have
been technically solved, save for duplicate identifier names and exports
from the same file, which appears to be avoidable.

Have no "faith" in anything, therefore "good" and "bad" preceding "faith"
are as irrelevant as "good" or "bad" and "faith" are.

You can use what is available now and write your own language in your spare
time
(What programming languages have been created by PPCG users?
https://codegolf.meta.stackexchange.com/q/6918) though beware ("Anyone,
from the most clueless amateur to the best cryptographer, can create an
algorithm that he himself can't break." -Schneier, Bruce (1998-10-15). Memo
to the Amateur Cipher Design <http://www.schneier.com/crypto-gram-9810.html#cipherdesign>. Cryptogram newsletter. (aka Schneier's Law)).

Thus far each of the prospective edge cases relevant to the proposal have
been technically solved, save for duplicate identifier names and exports
from the same file, which appears to be avoidable.

Have no "faith" in anything, therefore "good" and "bad" preceding "faith"
are as irrelevant as "good" or "bad".

You can use what is available now and write your own language in your spare
time
(What programming languages have been created by PPCG users?
https://codegolf.meta.stackexchange.com/q/6918) though beware ("Anyone,
from the most clueless amateur to the best cryptographer, can create an
algorithm that he himself can't break." -Schneier, Bruce (1998-10-15). Memo
to the Amateur Cipher Design <http://www.schneier.com/crypto-gram-9810.html#cipherdesign>. Cryptogram newsletter. (aka Schneier's Law)).