AtScript Primer

https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/mobilebasic?pli=1&viewopt=127

by skrebbel • 12 years ago

51 45 12 years ago

docs.google.com

timeu• 12 years ago

This is used for the new AngularJS 2.0

skrebbel• 12 years ago

I'm really interested in this. Does anyone know if this has a publicly available compiler already?

svckr2• 12 years ago

From the "Current Status" section:

    Currently we are in the midst of writing Angular v2 on top of the AtScript syntax. Here is an inventory of what is working today:
    - Traceur transpiler:
      - Consumes the AtScript syntax. (type annotations, meta-data annotations, fields)
      - Generates ES5 code with runtime type assertion statements for the rtts library and with meta-data annotations.
      - Transpiles AtScript into Dart code. (Does not do semantics matching, requires developer to use facades)
    - RTTS Library:
      - Asserts nominal types.
      - Asserts structural or custom types.
      -  Partial support for generics. Generics support in arrays and maps only.

ganarajpr3• 12 years ago

I would be interested in knowing where the RTTS library is ( source-code ).

ganarajpr3• 12 years ago

FWIW, I believe they are using traceur-compiler. https://github.com/google/traceur-compiler

If you look at this page here https://github.com/google/traceur-compiler/wiki/LanguageFeat...

You can see annotations in the "experimental" features list.

temperbens2• 12 years ago

https://github.com/support11/discussions/wiki/Watch-QPR-vs-A...

temperbens2• 12 years ago

https://github.com/support11/discussions/wiki/QPR-vs-Aston-V...

svckr2• 12 years ago

Thanks for the link.

At [ngeurope](ngeurope.org) Miško pointed out that they we're specifically not aiming to create yet-another-language. Instead they are evaluating ways for JS to evolve beyond ES6 and are planning to propose AtScripts features for ES7 (or whatever is next).

This falls in line with the recent trend that new features start out in transpilers instead of browsers.

ceronman• 12 years ago

I really like the idea of static type checking, but I'm not convinced about the usefulness of runtime checking. It will introduce a performance penalty and it will go against duck typing, which is one of the coolest features of languages like JS.

It seems that this project is trying to build something in between of TypeScript and Dart: they want the optional runtime type checking of Dart vs the good interoperability with JS of TypeScript.

In this interview [1] Anders Hejlsberg and Lars Bak (from TypeScript and Dart) discuss the idea of runtime type checking. They don't seem very convinced of the idea either.

[1] https://www.youtube.com/watch?v=5AqbCQuK0gM

grandalf• 12 years ago

Everything quacks like an object!

nawitus2• 12 years ago

The link states that you can "disable" the type checking for production use. I wonder if there's still a slight performance penalty. Atleast my "toy" project for runtime type checking has that slight performance penalty even when it's disabled: https://github.com/panuhorsmalahti/typed-javascript

malandrew6• 12 years ago

Thanks for the link. That's an interesting approach that I hadn't considered. Would be nice to see it also support checking the return types and higher-order functions.

zackbrown• 12 years ago

As I understand it, there is a 'production mode' that disables the runtime type checking. This way developers can gain the development-time benefits of type safety without sacrificing performance where it counts.

As for the benefits of duck typing, also as I understand it, the key point of runtime vs static checking is that it eases interoperation with non-annotated and non-typed code. So duck-type if and when you want; reap the benefits of types when you want.

For a much better explanation, watch Misko Hevery's keynote about Angular 2 and AtScript from NgEurope yesterday: http://youtu.be/S8fE-w2DL8U?t=21m5s

malandrew6• 12 years ago

Yup. Plus it should also be possible to only turn on type checking selectively for some functions in production. This way to you can implement it on functions that are executed infrequently and don't have a material impact on performance, but leave it off for those code paths that are critical for performance.

davidgrenier2• 12 years ago

Personally glad to be free of all that goofiness, Angular, JS or what have you.

http://websharper.com/

Almost two years in production.

I even had the opportunity to try the F# Type Provider for Sencha Architect and although I do not like tooling I came away shocked at how productive the experience could be for back-end application development using that tool.

ep1033• 12 years ago

What's it do, just compiles to js for the front end?

davidgrenier2• 12 years ago

Compiles your client-side F# code to JS such that you write all your code in the same programming language.

You get to leverage the sophisticated type system of F# for your client side code and get transparent interop between front-end and back-end code. There's no need for http/ajax requests to your back-end code because the WebSharper compiler takes care of wiring function calls from the client side directly.

  [<RPC>]
  let getName() = "David"

  [<JavaScript>]
  module Client =
    let page() =
      Div [
        Span [Text (getName())]
      ]

Not only is all of this statically typed, WebSharper takes care of transparently wiring the call for you and serializes any data structure that you may want to pass from the server to the client and vice versa.

WebSharper has no problem generating both server-side markup through server-side combinators but truly reigns as a SPA architecture as you can choose to simply return data from your RPC calls and generate the markup on the client-side. Another benefit here is that you generally avoid the need to rely on libraries like JQuery to query your DOM and interact with the markup. Being able to simply keep a reference to any DOM element you create as opposed to having to query your DOM to get is just simpler.

But WebSharper also offer a host of well thought-out abstractions on top of Web Development in the form of Sitelets/Formlets/Piglets and now UI.Next. The real benefit of those is composability.

If you are are already familiar with an ML-like language you will be pleased at the benefits you get. If you aren't, I strongly recommend you take a look at the landscape of programming languages as three great families stand out... you would do yourself a major favor as a developer to learn at least one ML. Those that do never go back.

santialbo• 12 years ago

I was very excited when Facebook showed flow at @scale but I haven't heard any update on the project since. Does anyone know when they are planning on releasing it?

striking• 12 years ago

Unfortunately it seems to me that the Google Drive folder linked is inaccessible.. the individual documents are easily found via Google Search but seeing them all in one place would be kinda nice.

malandrew6• 12 years ago

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

[1] https://github.com/sefaira/rho-contracts.js

[2] https://github.com/substack/node-falafel

[3] 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

[6] https://www.npmjs.org/package/esprima-fb

dragonwriter5• 12 years 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.)

malandrew6• 12 years 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)

nawitus2• 12 years ago

There is no reason that a similar project could not have been made via smaller modules using comment annotations.

That would be awkward, especially as your program scales.

  /*T (foo: A) => (bar: A) => A */
  var func = foo => bar => foo * bar;

Instead of:

  var func = (foo: A) => (bar: A) => foo * bar;

Handling callback type annotations would make pretty ugly code..

tel• 12 years ago

Why do you think that is the case? On-their-own-line type annotations is probably one of my favorite bits of Haskell syntax

    func :: A -> A -> A
    func foo bar = foo * bar

malandrew6• 12 years ago

Another options besides comment-based annotations is property based annotations.

Basically provide a library that contains all the possible primitive types that can be checked and functions for composing higher order types.

Then in the code do something like so:

    var types = require('types');

    function foo(bar, baz) {
      var qux = '';
      
      /* do something */

      return qux;
    }

    foo.types = {
      args: [types.Array, types.Object],
      return: [ types.String ] // array to support ES6 destructuring assignment
    }

This interface makes it trivially easy to define the types, parse the types, strip the types out on minification, etc.

This approach also makes it trivially easy to compose higher order types in a separate modules and require them.

my-geometry-types.js:

    var types = require('types');
    var point = [types.Float, types.Float];
    module.exports.point = point;
    module.exports.rectangle = [point, point];

Then in another file, you can require these type modules and use them to set the type signature of a function;

Anyways, my point is that building a tool like this is awesome, but a null contribution if it requires me to throw out all my existing tooling, especially for something that could have been implemented in a way that is composable. It may even be a net negative contribution if it gets traction and causes an unnecessary schism (e.g. JSX) in the community that reduces code sharing, interop and the ability for developers to stand on each others shoulders.

The beauty and strength of the NodeJS ecosystem is not the language it is based on (JavaScript) or its runtime (v8/libuv), but that it nailed a lot of details related to common conventions among developers and allowing modules to remain small and composable.

The modules created by people like prominent module contributors like Substack, Raynos, Izs and Dominic Tarr are usually stellar examples of publishing small, reusable module components. All of these guys have hundreds of small modules published that are very composable, easy test and easy/fast to replace if they don't meet your needs.

The tooling behind AtScript would be a huge contribution if it were made in a way where the components that make up the tooling could be mixed and matched for use in novel ways.

dragonwriter5• 12 years ago

Another options besides comment-based annotations is property based annotations.

You mean, exactly like what the generated JavaScript from AtScript has in the samples shown in TFA?

The tooling behind AtScript would be a huge contribution if it were made in a way where the components that make up the tooling could be mixed and matched for use in novel ways.

As detailed in TFA, there are two main components that exist right now -- the Traceur transpiler and the RTTS (runtime type system) library, the latter of which provides the kind of functionality you discuss in much of your post. Clearly RTTS can be used independently of AtScript proper.

There are future plans (also detailed in TFA), which include at least one other standalone tool. So the "components which can be mixed and matched in novel ways" seems to be exactly the plan.

If you had spent as much time reading what they actually have done and are doing as you spent writing about what they should and shouldn't do, you may have realized that you were basically asking for exactly what they are doing.

gcanti• 12 years ago

Another options besides comment-based annotations is property based annotations. Basically provide a library that contains all the possible primitive types that can be checked and functions for composing higher order types.

Shameless plug: I wrote a similar library based on set theory (I'm a mathematician)

https://github.com/gcanti/tcomb

EDIT: and here an article explaining the rationale behind the library

https://gcanti.github.io/2014/09/29/javascript-types-and-set...

ep1033• 12 years ago

Is anyone else simply getting tired of the number of ways google is attempting to (in their words) "replace JavaScript as the lingua franca of web development on the open web platform"? Dart, Angular, and AtScript are just the three most recent iterations of completely overhauling js for and by Google.

dragonwriter5• 12 years ago

No. I appreciate Google (and others) trying to make things better without breaking what works now.

Also, only Dart and AtScript are attempts to overhaul/replace JS, Angular is just a library (with versions for JS and Dart), not attempt to overhaul JS.

malandrew6• 12 years ago

This isn't entirely accurate. They aren't breaking what works in the browser, but they are breaking lots of the toolchains developers already use. I would much more appreciate these efforts if they started from a position of trying to do as much as possible in a way that is compatible with the existing development tooling and then building their incompatible extensions on top of that tooling.

georgemcbay• 12 years ago

No, I'm getting tired of other parties (most notably Mozilla) doing whatever they can to block such efforts on political rather than technical merits.

Do we really want to be stuck with a mostly stagnant JavaScript forever? Ugh.

ganarajpr3• 12 years ago

+1.

I hate this part about Mozilla and Apple. I dont have qualms about javascript. It has its good parts and as a full time javascript contractor I earn my living with javascript. But... I dont really want the next generation of developers to be stuck with whatever we have today. I am not in favor of "Here is what you get - do all your innovations inside this box" mentality. Yes, there is scope for improving javascript or ECMAscript but there are limits to this. As Peter Thiel says in his book - this is incremental-ism. This will never produce 0 to 1. In order to produce something like that people should be allowed to innovate - even if initially they have to do stuff like this AtScript or Dart or TypeScript! Criticizing those attempts as "breaking the existing tool-chain" is as foolish as criticizing a spaceship because it does not make use of roads.

aikah• 12 years ago

Well,the truth is Mozilla never blocked anything.They were on board with Adobe about ES4(basically actionscript3 in the browser).It's brands like Microsoft and Apple who ironically were the most vocal against any change in javascript.

rikkus• 12 years ago

"The goal of AtScript is to enhance the language with these missing features without infringing upon its current capabilities."

Looks like they decided TypeScript was Not Invented Here?

dmethvin• 12 years ago

TypeScript compiles out all the overhead, AtScript will need to leave at least some overhead so that it can support RTTI. The AtScript design acknowledges and borrows from TypeScript, ideally I would prefer it to be a superset so we don't end up with a lot of divergent dialects.

munificent• 12 years ago

According this [1] article from Microsoft, the TypeScript folks are coordinating with the AtScript folks.

[1] http://blogs.msdn.com/b/typescript/archive/2014/10/22/typesc...

robbrown451• 12 years ago

Looks to me like they are embracing Typescript. This is basically a superset. If I was on the Typescript team, I'd consider it a victory.

jbergens2• 12 years ago

If you watch the keynote video about AtScript you'll see that they describe AtScript as a superset of TypeScript 2. They add features they think are missing but are trying to keep the syntax wherever possible (actually they hope that much of TypeScript will be in a future EcmaScript standard and then they will follow that syntax).

danabramov• 12 years ago

I like the parts before DI. TypeScript-ish syntax, pluggable runtime checks—I really like that. But DI and annotations speak more of Angular's complexity than anything.

muyuu• 12 years ago

Another TypeScript or another Dart?

http://xkcd.com/927/

ep1033• 12 years ago

If google is going to attempt to use angular to get developers to use this (as opposed to just letting it fail naturally, like Dart), then I'm done using angular.

paperstreet7• 12 years ago

It seems to me they're trying to use the popularity of Angular.js to bring AtScript on the scene. Everyone who doesn't like JS tries to replace it with his own language or at least fix it. There are tons of different compilers that hide real JS from their eyes behind language x but when it comes to realtime debugging they inevitably have to dig into some real JavaScript generated by those tools. AtScript is not an exception here.

AtScript Primer

Related Stories