3 ms·

Why not use type annotations to accomplish this? Do we really need another compile to JavaScript language for something that did not require changing the langua

Why not use type annotations to accomplish this? Do we really need another compile to JavaScript language for something that did not require changing the language syntax? There is no reason that a similar project could not have been made via smaller modules using comment annotations. This project really should be at least two projets: (1) one npm module for parsing the type signatures with the line numbers of the functions it applies to. (2) one module that takes in that intermediary representation and performs the AST transform for wrapping the functions. I don't see why this couldn't have been accomplished with: (1) the doctrine module [0] for parsing JSDoc comment blocks before functions OR a custom module for recognizing a custom comment delimiter like //+ or //! followed by the type annotation such as Haskell's type declaration format. (2) a module for parsing closure compiler JSDoc type signatures (3) the racket-style higher order contracts module [1] for a way to do run-time checking (3) a module consisting of all the possible permutations of higher order type checking functions based on rho-contracts (4) the node-falafel module [2] for performing the actual AST transform that wraps those contract functions around the function described by the JSdoc comment. Furthermore, this approach of breaking this up in to modules allows multiple people to propose alternative syntaxes for this for consideration in future versions of ECMAScript. I wouldn't be surprised if sweet.js could also be used for those syntax approaches that go beyond comment-based annotations and involve modifying the syntax of the language itself. For those that built this at Google, please please please consider breaking this down into smaller composable modules. I'd love to be able to play with the subcomponents of this myself without having to adopt yet another language that doesn't parse with off the shelf tools [4]. [0] https://github.com/Constellation/doctrine https://github.com/Constellation/doctrine [1] https://github.com/sefaira/rho-contracts.js https://github.com/sefaira/rho-contracts.js [2] https://github.com/substack/node-falafel https://github.com/substack/node-falafel [3] http://sweetjs.org/ http://sweetjs.org/ [4] See JSX for the clusterfuck[6] that results when you add yet another format that needs to be parsed in a unique way with no real benefit that couldn't be accomplished just as easily without fucking with the standard language syntax. See Wadler's Law [5] [5] http://www.haskell.org/haskellwiki/Wadler's_Law http://www.haskell.org/haskellwiki/Wadler's_Law [6] https://www.npmjs.org/package/esprima-fb https://www.npmjs.org/package/esprima-fb

dragonwriter 12y ago
> Why not use type annotations to accomplish this? Type annotations are a strict subset of the "this" that AtScript seeks to accomplish. > Do we really need another compile to JavaScript language for something that did not require changing the language syntax? "Need" is a fuzzy term, but I think it clearly benefits from a new language with new syntax fitted for the semantics rather than trying to hide new functionality in a separate sublanguaged inside JS comments as you suggest. > There is no reason that a similar project could not have been made via smaller modules using comment annotations. There's no reason it couldn't be done, although there are reasons not to prefer it (noted above), and in any case preprocessing comment annotations in what is otherwise JS to generate additional JS code for runtime type checking is creating a new compile-to-JS language, its just putting the code for that new language in something that looks like JS comments, so it would still be doing exactly the thing you say shouldn't be done (or, in other words, your suggested alternative suggests that we must really need another compile to JS language to do this, since your alternative still creates such a language.)
- malandrew 12y ago
  > Type annotations are a strict subset of the "this" that AtScript seeks to accomplish. like? > "Need" is a fuzzy term, but I think it clearly benefits from a new language with new syntax fitted for the semantics rather than trying to hide new functionality in a separate sublanguaged inside JS comments as you suggest. When I used "need" I was suggesting that the syntax proposed did not have to be a mandatory part of adopting this feature. If you break this isn't smaller single purpose modules, you leave people the option of choosing your special syntax or choosing to build upon most of your work to make something that doesn't break all your existing tooling. Clojurescript and PureScript are example of a compile-to-javascript languages that needed another format. In the case of clojurescript, only another syntax will afford you the power of S-expressions. My objection with AtScript is that the new syntax could have been a completely optional interface for getting the benefits of the tooling actually doing the heavy lifting in this module. > in any case preprocessing comment annotations in what is otherwise JS to generate additional JS code for runtime type checking is creating a new compile-to-JS language, its just putting the code for that new language in something that looks like JS comments, so it would still be doing exactly the thing you say shouldn't be done (or, in other words, your suggested alternative suggests that we must really need another compile to JS language to do this, since your alternative still creates such a language.) Not exactly. Using comments allows my code to remain as vanilla JavaScript and therefore continues to work with all other off the shelf tooling out there. Asking me to adopt an entire new code format for what could have worked just fine as an extension of the standard format out there (i.e. vanilla javascript) is onerous and unnecessary. Requiring a new format requires me to through out my linters (eslint, jshint, jscs) and my parsers (esprima, acorn) and any tooling built on those parsers (ternjs, node-falafel, escodegen, browserify, sourcegraph, source maps tooling)

dragonwriter 12y ago

> Why not use type annotations to accomplish this? Type annotations are a strict subset of the "this" that AtScript seeks to accomplish. > Do we really need another compile to JavaScript language for something that did not require changing the language syntax? "Need" is a fuzzy term, but I think it clearly benefits from a new language with new syntax fitted for the semantics rather than trying to hide new functionality in a separate sublanguaged inside JS comments as you suggest. > There is no reason that a similar project could not have been made via smaller modules using comment annotations. There's no reason it couldn't be done, although there are reasons not to prefer it (noted above), and in any case preprocessing comment annotations in what is otherwise JS to generate additional JS code for runtime type checking is creating a new compile-to-JS language, its just putting the code for that new language in something that looks like JS comments, so it would still be doing exactly the thing you say shouldn't be done (or, in other words, your suggested alternative suggests that we must really need another compile to JS language to do this, since your alternative still creates such a language.)

malandrew 12y ago
> Type annotations are a strict subset of the "this" that AtScript seeks to accomplish. like? > "Need" is a fuzzy term, but I think it clearly benefits from a new language with new syntax fitted for the semantics rather than trying to hide new functionality in a separate sublanguaged inside JS comments as you suggest. When I used "need" I was suggesting that the syntax proposed did not have to be a mandatory part of adopting this feature. If you break this isn't smaller single purpose modules, you leave people the option of choosing your special syntax or choosing to build upon most of your work to make something that doesn't break all your existing tooling. Clojurescript and PureScript are example of a compile-to-javascript languages that needed another format. In the case of clojurescript, only another syntax will afford you the power of S-expressions. My objection with AtScript is that the new syntax could have been a completely optional interface for getting the benefits of the tooling actually doing the heavy lifting in this module. > in any case preprocessing comment annotations in what is otherwise JS to generate additional JS code for runtime type checking is creating a new compile-to-JS language, its just putting the code for that new language in something that looks like JS comments, so it would still be doing exactly the thing you say shouldn't be done (or, in other words, your suggested alternative suggests that we must really need another compile to JS language to do this, since your alternative still creates such a language.) Not exactly. Using comments allows my code to remain as vanilla JavaScript and therefore continues to work with all other off the shelf tooling out there. Asking me to adopt an entire new code format for what could have worked just fine as an extension of the standard format out there (i.e. vanilla javascript) is onerous and unnecessary. Requiring a new format requires me to through out my linters (eslint, jshint, jscs) and my parsers (esprima, acorn) and any tooling built on those parsers (ternjs, node-falafel, escodegen, browserify, sourcegraph, source maps tooling)