5 ms·

This is a form of cross-compilation kind of like how TypeScript is cross compilation. It does require a build step to produce JavaScript - you will not be able

by inglor 12y ago

This is a form of cross-compilation kind of like how TypeScript is cross compilation. It does require a build step to produce JavaScript - you will not be able to enjoy fiddles as easily and so on. Then again their rationale is very clear and pretty good: You need builds if you're using Facebook's stack anyway (for JSX) so this should not interfere with your current build - which you have to do anyway.

slashnull 12y ago
If only to remove syntactically invalid type annotations, I guess. Strong typing is not incompatible with the absence of run-time typing information, due to the magic of type erasure.
- ufo 12y ago
  Type erasure is only safe if the whole program is statically typed though - you are still going to need to use runtime checks if you want to interface with dynamic code.
  - slashnull 12y ago
    Well yeah nobody talked about removing JS's duck typing algo.
  - oyvindkinsey 12y ago
    Based on the inference, we can imagine a case where Flow would flag certain boundaries as 'unsafe', allowing a transform to inject dynamic type safety checks using the same type information Flow has available. For instance, you could imagine a function calling into some unknown api, where we would need to constrain the type of the variable to the expected one to avoid `any` being applied to it. While the library files do provide typing of external dependencies, this doesn't protect you from bugs in those libraries! The same applies to api's that are explicitly typed as `any`, but which should return a certain type. Having Flow add a dynamic assertion on the type here would allow the rest of the program to remain type safe, knowing that a violation is guaranteed to halt execution. While dynamic strong typing is also used at Facebook, we're not quite ready to launch this as an extension to Flow.
drderidder 12y ago
Really? It appears to be much more of a static analysis tool than a cross-compiled psuedo-syntax. Here's what it outputs: flow examples/01_HelloWorld/hello.js /hello.js:7:5,19: string This type is incompatible with hello.js:4:10,13: number Found 1 error
- inglor 12y ago
  EDIT: looks like it supports type annotations similar to closure compiler's (in docs) https://github.com/facebook/flow/blob/master/tests/docblock/docblock.js https://github.com/facebook/flow/blob/master/tests/docblock/... Try running an annotated file in the browser - it's simply not valid ECMAScript syntax and no JavaScript runtime will run it 'as is'. If the code requires transformation by a compiler aware of the language semantics and syntax - it's transpiling in my book. Just like TypeScript is a superset of ECMAScript - so is Flow (in a much lighter, closer to source sense it seems).
  - masklinn 12y ago
    > Try running an annotated file in the browser - it's simply not valid ECMAScript syntax and no JavaScript runtime will run it 'as is'. Of course not, but the point was that it's not a different language, it simply adds type annotations. If you strip out the type annotations, it should be a valid JS file.
    - inglor 12y ago
      This is also true for TypeScript though. The only thing that's not directly JS in TypeScript is shims for new JS features (from ES6) not yet implemented.
      - masklinn 12y ago
        > This is also true for TypeScript though. AFAIK none of these are valid javascript, event assuming ES6: * class-level variables (resolved as instance variables) * field visibility * initializer constructors (constructor without a body automatically assigning to a field) * enum types That is, you can't remove type annotations (and `interface` declarations which can probably get a pass) and end up with valid JS, which seems to be what flow yields.

by inglor 12y ago

slashnull 12y ago

If only to remove syntactically invalid type annotations, I guess. Strong typing is not incompatible with the absence of run-time typing information, due to the magic of type erasure.

ufo 12y ago
Type erasure is only safe if the whole program is statically typed though - you are still going to need to use runtime checks if you want to interface with dynamic code.
- slashnull 12y ago
  Well yeah nobody talked about removing JS's duck typing algo.
- oyvindkinsey 12y ago
  Based on the inference, we can imagine a case where Flow would flag certain boundaries as 'unsafe', allowing a transform to inject dynamic type safety checks using the same type information Flow has available. For instance, you could imagine a function calling into some unknown api, where we would need to constrain the type of the variable to the expected one to avoid `any` being applied to it. While the library files do provide typing of external dependencies, this doesn't protect you from bugs in those libraries! The same applies to api's that are explicitly typed as `any`, but which should return a certain type. Having Flow add a dynamic assertion on the type here would allow the rest of the program to remain type safe, knowing that a violation is guaranteed to halt execution. While dynamic strong typing is also used at Facebook, we're not quite ready to launch this as an extension to Flow.

drderidder 12y ago

Really? It appears to be much more of a static analysis tool than a cross-compiled psuedo-syntax. Here's what it outputs: flow examples/01_HelloWorld/hello.js /hello.js:7:5,19: string This type is incompatible with hello.js:4:10,13: number Found 1 error

inglor 12y ago
EDIT: looks like it supports type annotations similar to closure compiler's (in docs) https://github.com/facebook/flow/blob/master/tests/docblock/docblock.js https://github.com/facebook/flow/blob/master/tests/docblock/... Try running an annotated file in the browser - it's simply not valid ECMAScript syntax and no JavaScript runtime will run it 'as is'. If the code requires transformation by a compiler aware of the language semantics and syntax - it's transpiling in my book. Just like TypeScript is a superset of ECMAScript - so is Flow (in a much lighter, closer to source sense it seems).
- masklinn 12y ago
  > Try running an annotated file in the browser - it's simply not valid ECMAScript syntax and no JavaScript runtime will run it 'as is'. Of course not, but the point was that it's not a different language, it simply adds type annotations. If you strip out the type annotations, it should be a valid JS file.
  - inglor 12y ago
    This is also true for TypeScript though. The only thing that's not directly JS in TypeScript is shims for new JS features (from ES6) not yet implemented.
    - masklinn 12y ago
      > This is also true for TypeScript though. AFAIK none of these are valid javascript, event assuming ES6: * class-level variables (resolved as instance variables) * field visibility * initializer constructors (constructor without a body automatically assigning to a field) * enum types That is, you can't remove type annotations (and `interface` declarations which can probably get a pass) and end up with valid JS, which seems to be what flow yields.