Re: Math.TAU
NO! π all the things! Just kidding ;) ... +1 adding the τ constant. - Jonathan On Sat, Jun 28, 2014 at 9:01 PM, C. Scott Ananian ecmascr...@cscott.net wrote: I'll admit to being a pi-ist, rather than a tau-ist, but I don't object to adding Math.TAU. It's a fairly harmless easter egg. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
I think that a possible compromise that can still make the ES6 module system more compatible with both AMD and CommonJS modules is by this: If there are no exports from a module, named or not, make the export process implementation-defined. If an ES5 Node module uses module.exports, then Node could configure the exports to be importable through the ES6 syntax. Some people use named exports, while others have even exported a constructor via module.exports. In the browser environment, it could be something along the lines of using the added Window properties as named exports. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Math.TAU
Another +1. Would save me doing Math.TAU = 2 * Math.PI; at the top of all my trignometry files :-) On 1404030818733, Jonathan Barronville jonat...@belairlabs.com wrote: NO! π all the things! Just kidding ;) ... +1 adding the τ constant. - Jonathan On Sat, Jun 28, 2014 at 9:01 PM, C. Scott Ananian ecmascr...@cscott.net wrote: I'll admit to being a pi-ist, rather than a tau-ist, but I don't object to adding Math.TAU. It's a fairly harmless easter egg. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
Thanks Kevin. I'm going to challenge your list below, but I hope you don't
take it negatively. I want the case for the module system to be as strong
as possible.
On Sat, Jun 28, 2014 at 11:51 AM, Kevin Smith zenpars...@gmail.com wrote:
Static checking of imports and exports has well-known advantages and
would help the long-term viability of the language.
Enumerating these specific advantages would inform this discussion.
These advantages are not well-known. Many developers have experienced the
disadvantages of complex systems of rules and thus favor simple solutions
over ones with theoretical advantages. Explaining the benefits concretely
would help them balance the well-known costs.
So pretty much everything in Javascript is dynamic, which is one reason
why IDE support for Javascript has always lagged behind. You simply can't
know what anything is until you actually run the program. Statically
verifiable exports gives us the ability to inspect and analyze code without
having to run it. There are two big benefits that this affords us:
## Early Errors and Warnings ##
Let's say that you want to deprecate and remove an exported member from a
module within a large JS code base. With static imports, the system will
generate an error at compile time if something on the other side of that
codebase is importing it.
It seems to me that the compiler can verify these two statements with equal
success:
import {foo} from './foo';
var foo = require('./foo.js').foo;
I agree that as a practical matter compilers may be more likely to
implement checks on the first form simply because it is standard. And I
agree that the language-defined module syntax will lead to better quality
tools simply because more developers have formal training in compiler
technology than have training in dynamic analysis. These are important
pragmatic issues.
Or am I wrong and these are not equivalent? Or there are examples which
show the issue more clearly?
For exported function declarations that use default parameters to indicate
optional parameters, we can generate build-time warnings when such an
function is imported and called with too few arguments.
A good argument for default parameters.
For exported classes, we have even more static information at our hands.
Without having to run the program, we know the number of arguments for the
constructor and we know the list of methods for class instances. We can
generate warnings when we see an instance using a misspelled method name,
for instance.
A good argument for standard rather than ad-hoc class class syntax.
## Computer Aided Coding ##
The information used above to generate lint-like warnings can also be used
to give the developer in-editor feedback. Reliable code-completion for
imported function and class declarations becomes possible. Again, for
exported classes we can also do code completion for instance methods.
These advantages may not seem like a big deal now, but imagine writing JS
in a large team five years from now. Do you want the power of static
analysis at your team's fingertips, or do you want to be stuck with
anything goes so anything can break CommonJS modules?
Does that do it?
These are arguments for statically computable import module names -- so the
compiler can determine the imports without executing source code -- and for
top-level or hoisted (static) import statements -- so every import in a
module is a dependency of the module without runtime conditionals. I
believe that both of these limitations would be acceptable to almost all
developers interested in using modules.
Unfortunately I think we need more specific and detailed examples to
understand the advantages of the static form.
Thanks,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith zenpars...@gmail.com wrote: Static checking will be limited anyway. If you want to go this way you should use typescript. That's the point that I'm trying to make, shops will choose other languages that provide more static information. We should be thinking about expanding the user base and ensuring that JS is a viable option years down the road. JavaScript's enormous user base is the strongest possible evidence that static analysis provides no advantage to programming language viability. Static analysis may encourage some new users; overall complexity may discourage as many. (I recently started using a typed version of JS; I am not impressed.) Any survey of the top languages in actual use clear demonstrates that the runtime platform and app goals dominate language choice. Even within a platform it is clear static checks are way down the list of valued features. Rather than point towards type-checking, I think we should focus on the actual checks offered by the module design. It seems that these would come with a small cost quite unlike type-checking. CommonJS falls a bit short on the import side because static analysis of require calls is brittle. A special language syntax would enable a robust static analysis of dependencies. If you don't have static exports, then how are you going to know if what you import is valid? You can't, without executing the program. If you don't execute the program, how do you know if the code you are checking is even called? Oh, you do plan to execute the program. Well there you go. (I just think it is so weird that JavaScript's huge advantage of rapid dynamic feedback for developers receives so little attention while so much is lavished on static technologies developed decades ago for a computing environment vastly inferior to our current world.) jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
On Jun 29, 2014, at 12:50, Rick Waldron waldron.r...@gmail.com wrote: Static analysis would be necessary if JavaScript ever wanted to make macros possible in modules. I don't have exact numbers nor have I done any formal surveys, but the general response to Sweet.js has been overwhelmingly positive. It would be a shame to close that door. My understanding is that door is already closed, since we were not able to eliminate the global scope contour from modules (which is necessary to get completely-static knowledge of all free identifiers). Part of the rationalization for this was that compile-time tools (like Sweet.js) are working out pretty well. See Back to Static Checking in http://esdiscuss.org/notes/2013-09-18 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
CommonJS falls a bit short on the import side because static analysis of require calls is brittle. A special language syntax would enable a robust static analysis of dependencies. If you don't have static exports, then how are you going to know if what you import is valid? You can't, without executing the program. The main purpose of modules is not to provide static type checking but to prevent global scope pollution and allow loaders to load source code reliably and efficiently. What I meant by static analysis was the ability for a loader to bundle all the dependencies so that they can be transported efficiently. With require this analysis is brittle because require is not a reserved keyword and its argument can be any expression. It is important to focus the design on loader issues and keep things orthogonal. Why reinvent a special destructuring syntax when this is already addressed by existing language constructs? It can be handled by allowing any LHS after the as keyword: import module_path as lhs_expression; Why bother about about static type checking? If you want static typing, use Typescript, your modules will be exporting typed APIs; if you don't care use JavaScript. Sorry for the previous empty post. I hit the wrong key. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: ModuleImport
Static checking will be limited anyway. If you want to go this way you shoud
use typescript.
If you don't want static checking you should stick with ES3. Fixed that for you.
Yes big projects are possible with JS, I work on them everyday. It
would be nice if the language made them easier, that's what we are
talking about.
Big projects are possible with C, why bother with any other language?
With sufficient rigor Assembly will do the trick. Just have good code
reviews and test.
ability to dynamically import modules in addition to static imports. IMO this
should be packaged as an async API
I think this is already possible using the loader.
hooks for transpilers. This should also be an API
Ditto.
Usually, I obtain the same benefit running the tests (and more, test that
were the product of TDD workflow)
I can forsee many people writing tests where they configure the module
loader to load mocks instead of true dependencies.
This could result in tests passing while there is a breakage in the application.
If the language can make some of these problems go away then we are better off.
It's just like tests, code review and linting, it's another type of
verification.
I think that a possible compromise that can still make the ES6 module system
more compatible with both AMD and CommonJS modules
The ES6 module system is compatible with CommonJS and AMD, I'm happily
mixing the two together with libraries like SystemJS
https://github.com/systemjs/systemjs/
For example
https://github.com/briandipalma/flux-es6/blob/master/src/Store.js
The Emitr class here is imported from a CommonJS module
It is important to focus the design on loader issues and keep things
orthogonal.
The Loader is quite solid and well designed, I've not heard any major
issues with it. What does it have to do with this discussion?
import {foo} from './foo';
var foo = require('./foo.js').foo;
I though those two statements weren't comparable?
The import statement can only be present at the module top level while
the require can be written in any code block.
That leaves it open to the random number require issues which makes
static checking impossible.
As you pointed out it's not a language standard so I'd imagine that's
another reason why tooling is so weak.
Rather than point towards type-checking, I think we should focus on the
actual checks offered by the module design.
It seems that these would come with a small cost quite unlike type-checking.
Unless I'm misunderstanding Kevin I think we've both talking about
exactly that. I guess people saw static and automatically added
type.
Just static checking of import and export bindings. A much smaller
scope feature then static type checking.
This discussion has veered off track, it's about a new ModuleImport
form, which grew into questioning if default imports/exports was the
real problem.
I'd be interested in knowing if it's possible that instead of changing
the ModuleImport form the default import/export idea could be
postponed instead.
It could be added in later if there really was need for it.
As far as I can tell libraries like SystemJS can smooth over issues
caused by importing from legacy module systems like CommonJS and AMD.
Leaving default imports/exports an odd third way to import that was
added based on some notion of backward compatability that wasn't
needed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
Bruno and John's arguments are classic examples of the straw man fallacy. In my concrete examples I made no reference to static type systems (or any type systems at all, for that matter). I merely pointed out that by allowing the programmer to provide compile-time information in the form of exports and declarative forms, a world of possibilities opens up. Of course, static information can always be *inferred* from dynamic. That's basically how JS engines work, but raising that up to some ideal principle is foolish dogmatism. They accuse me of advocating decades-old technology, but it is purely dynamic JS that is decades old. Evolve or die is the way. The we don't need no stinkin' classes argument is counter-productive, counter-intuitive reactionary garbage, and quite frankly it bores me. : P ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: ModuleImport
I'd be interested in knowing if it's possible that instead of changing
the ModuleImport form the default import/export idea could be
postponed instead.
It can. Just to be clear, that means that we'd have these two forms on the
import side:
module FS from fs;
import { stat } from fs;
which would be cool with me.
I think, though, that the default thing has syntactically been raised up to
an architectural level, and that's the core problem that Andreas has
pointed out. Once you make the architectural decision to drop it, then
you'll probably never want it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
