Re: modules, @std, selectively hiding/renaming imports
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard
..
The "keys" from "Object" and from "@iter" can't both be in
scope, yet both "Object"/"@reflect" and "@iter" seem to be
scheduled for inclusion in "@std".
I think this is a misunderstanding because the "@object" module wasn't
mentioned at the top of that section of the wiki page, which I've now
corrected. The current plan (which is very early, there has been
little discussion of this) has the `keys' function that produces an
iterator in "@std" and the `keys' function that is the same as
`Object.keys()' in the "@object" module.
Yes, on re-reading the current page, I see that I misunderstood
the organization. You separately enumerate standard prelude
and other standard libraries, but you haven't actually committed
to importing any of them implicitly, nor does the page say which
imports will be available unqualified.
The reason I'm trying to have this discussion at this early stage
is that the whole ES.next modules block needs to come under
detailed scrutiny for pragmatic issues as early as possible. It
is a fundamental aspect of ES.next, it has passed the proposal
stage with flying colours, and (nearly) everybody is optimistic
about it. Now the pragmatic details need to be checked/refined.
I tried to list some current module usage patterns in
supporting ES upgrading with a programming pattern repo?
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018240.html
It would be good if all of these -and any other module usage
patterns in common use- would be addressed in the modules
proposal pages. And the (implicit?) standard prelude is entirely
new for ES.next, though there is experience in other languages.
From previous discussions of the 'for (k of keys(o)){..}' pattern,
I assume that there will be an implicit
import * from "@std"
Is that correct? If so, my questions are:
1. how do I convert the implicit import into an explicit one?
taking a leaf from Haskell's (very conventional) module system,
one could assume that every explicit import of "@std" eliminates
the implicit import, for instance, but ES.next modules will be
more flexible than Haskell's, so it would be nice to have that
spelled out.
2. how do I import everything from "@std", with "keys"
omitted or renamed?
From Brendan's remarks, no such feature is currently planned?
3. why is "keys" listed under "@std", but not under "@iter"?
What is the ES.next modules story about re-exporting?
On the topic of standard preludes and Haskell experience: I
could search for the links to the relevant features (over time,
users have requested several extensions to get more control
over what is "standard"), if there is interest?
Claus
http://clausreinke.github.com/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: modules, @std, selectively hiding/renaming imports
On Fri, Nov 25, 2011 at 5:02 AM, Claus Reinke wrote: >>> From the early drafts of a standard library >>> >>> http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard >>> >>> it appears we are headed for an import name clash between >>> "Object.keys and "@iter.keys" - they cannot both be available as >>> plain "keys". >> >> Object is not a module, so there's no clash. Lots of methods named "keys" >> these days. >> Also the recent es-discuss thread on @iter suggests eliminating it in >> favor of @reflect, which we want for Proxy helpers too. > > Perhaps I misunderstand the standard library idea: I thought > the idea was to provide those identifiers in unqualified form, > via an implicit import-* of "@std" (btw, is there a way to turn > of the implicit import, making it explicit, for more selective > import?). > > The "keys" from "Object" and from "@iter" can't both be in > scope, yet both "Object"/"@reflect" and "@iter" seem to be > scheduled for inclusion in "@std". I think this is a misunderstanding because the "@object" module wasn't mentioned at the top of that section of the wiki page, which I've now corrected. The current plan (which is very early, there has been little discussion of this) has the `keys' function that produces an iterator in "@std" and the `keys' function that is the same as `Object.keys()' in the "@object" module. -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: modules, @std, selectively hiding/renaming imports
From the early drafts of a standard library http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard it appears we are headed for an import name clash between "Object.keys and "@iter.keys" - they cannot both be available as plain "keys". Object is not a module, so there's no clash. Lots of methods named "keys" these days. Also the recent es-discuss thread on @iter suggests eliminating it in favor of @reflect, which we want for Proxy helpers too. Perhaps I misunderstand the standard library idea: I thought the idea was to provide those identifiers in unqualified form, via an implicit import-* of "@std" (btw, is there a way to turn of the implicit import, making it explicit, for more selective import?). The "keys" from "Object" and from "@iter" can't both be in scope, yet both "Object"/"@reflect" and "@iter" seem to be scheduled for inclusion in "@std". While the standard library needs a separate resolution, this situation is not at all untypical for module-based development. How are ES.next modules going to deal with this? We can locally rename an imported id, but I see no facilities for import hiding (import everything but a handful of ids), so how would we import everything while renaming a few ids? We've mooted syntax for selective renaming, but import-all (import * from "...") lacks that feature in the current proposal. You'll have to be explicit in what you import. This ok. * imports are for prototyping, one-offs where you control both modules, and the like. They are not for everything. And anyway, there's non conflict with Object.keys. I agree that explicit imports are better for documentation, and for being selective about dependencies when we don't control the imported module. Though it is inconvenient for development, one can write tools that alleviate this inconvenience. And the sooner one documents which module an item comes from, the one will have to search later. However, I'm not sure that JS coders in general will like the added formality, and without selective renaming, import-* cannot be used at all in the presence of possible name conflicts. Assuming, for instance, that two modules A and B both export "keys", one could not import-* both, not even in prototyping. And if there is no way to turn an implicit 'import * from "@std"' into something more selective, names such as "keys" will not be available anyway (or do later imports shadow earlier ones?). Claus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: modules, @std, selectively hiding/renaming imports
On Nov 20, 2011, at 2:04 AM, Claus Reinke wrote: > [btw: http://wiki.ecmascript.org/feed.php still gives me >url-encoded links; I thought that was meant to be > fixed by a wiki upgrade?] > > From the early drafts of a standard library > > http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard > > it appears we are headed for an import name clash between > "Object.keys and "@iter.keys" - they cannot both be available as > plain "keys". Object is not a module, so there's no clash. Lots of methods named "keys" these days. Also the recent es-discuss thread on @iter suggests eliminating it in favor of @reflect, which we want for Proxy helpers too. > While the standard library needs a separate resolution, this > situation is not at all untypical for module-based development. > How are ES.next modules going to deal with this? We can locally > rename an imported id, but I see no facilities for import hiding > (import everything but a handful of ids), so how would we import > everything while renaming a few ids? We've mooted syntax for selective renaming, but import-all (import * from "...") lacks that feature in the current proposal. You'll have to be explicit in what you import. This ok. * imports are for prototyping, one-offs where you control both modules, and the like. They are not for everything. And anyway, there's non conflict with Object.keys. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
modules, @std, selectively hiding/renaming imports
[btw: http://wiki.ecmascript.org/feed.php still gives me url-encoded links; I thought that was meant to be fixed by a wiki upgrade?] From the early drafts of a standard library http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard it appears we are headed for an import name clash between "Object.keys and "@iter.keys" - they cannot both be available as plain "keys". While the standard library needs a separate resolution, this situation is not at all untypical for module-based development. How are ES.next modules going to deal with this? We can locally rename an imported id, but I see no facilities for import hiding (import everything but a handful of ids), so how would we import everything while renaming a few ids? Claus http://clausreinke.github.com/ http://clausreinke.github.com/js-tools/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
