I'm very interested in this. What's the ETA? about babel-plugin-tcomb

[gcanti]

Hi,
it's difficult to say at the moment. For now I'm just playing with babel's plugin APIs.
Luckily there is a plugin which I can take as reference implementation:

https://github.com/codemix/babel-plugin-typecheck

[zerkalica]

Why not to parse flowtypes to tcombtypes for run-time checking?

Runtime checking - only small part of the problem, what about ide support (like nuclide ide), autocomplete, static checking, how to use together tcomb and flow ?

[majhork]

Flow provides static checking for Flow types. Otherwise converting those types to tcomb and preserving the unions and intersections would allow very interesting introspective capabilities. Autocomplete and light ide support could likely be added with some very simple hacks.

[zerkalica]

In codemix/babel-plugin-typecheck#21 (comment) i try to describe some problems about runtime checking reflection and external libraries.

[gcanti]

Hi all,
So I wrote the basic code in order to handle the main constructs of tcomb README.
It's already usable but now I wonder if this plugin should handle Flow types and convert them to corresponding tcomb types:

• string -> t.String
• number -> t.Number
• boolean -> t.Boolean
• Array -> t.Array
• Function -> t.Function
• Object -> t.Object
• any, mixed -> t.Any

As example the following function:

function sum(x: number, y: ?number): number {
  return x + (y || 0);
}

will be compiled by the plugin to something like:

function sum(x: number, y: ?number): number {
  x = t.Number(x);
  y = t.maybe(t.Number)(y);

  const ret = function (x, y) {
    return x + (y || 0);
  }(x, y);

  return t.Number(ret);
}

[chrisui]

I would love to see the basic flow types be implemented (ie. moving towards something like the intention of your flowcheck library.

Would be interesting to discuss how to implement the more complex types such as the flow equivilent of a Struct etc.

Maybe parsing Object type declarations look good for struct's?

[gcanti]

Converting the basic Flow types to tcomb should be straightforward. The main problem is that AFAIK Flow can't understand structs, just classes and Object types. This weekend I'm going to play with Flow v0.17, maybe I can find something new/useful.

Maybe parsing Object type declarations look good for struct's?

It depends on your goal. If you want to preserve the Flow semantic I should add a new combinator: Object types are structural while structs are "nominal" (they use instanceof internally). Moreover I should handle classes, now this would raise an error:

class A {}

function f(a: A) {
  return a;
}

f(new A());

since the plugin will convert f to something like:

function f(a: A) {
  a = A(a); // all tcomb types are glorified identity functions

  return a;
}

[majhork]

Could you not compile to this instead?

t.Function([t.Number, t.maybe(t.Number)], t.Number, "sum").of(
    function sum(x: number, y: ?number): number {
        return x + (y || 0);
    }
);

I can see some potential problems but it would be really nice to get runtime type information for functions.
That and +1 for "this plugin should handle Flow types". A Flow user could leverage your entire collection of libraries nearly for free. Inferring forms (using tcomb-form) from functions would be awesome. I think that's the right place to explore deeper type symmetry too. Thanks for this. It looks exciting.

[chrisui]

Ah. Had no idea Structs were nominal in this case. Still a bit naive about types and such so bear with me :)

For my use case I am after structural typing. We have no classes but just pass around state as immutable objects.

NB: A lot of what I want to do in the future is currently being inspired by the F# "design with types" series which you're probably familiar with. tcomb basically does the runtime side of this dynamically but I'm trying to find a way to bend Flow to offer the static side we need which I think is almost there.

[ivan-kleshnin]

What's the current status of this? If Tcomb syntax is Flow-compatible can we have both sides of the coin (static type checking + first-class types)?

P.S.

Readme does not mention that "syntax-flow" and "transform-flow-strip-types" plugins are required.

[gcanti]

What's the current status of this?

Only tcomb types are supported. i.e this is ok:

function sum(a: t.Number, n: t.Number): t.Number {
  return a + b
}

this is not ok (throws):

function sum(a: number, n: number): number {
  return a + b
}

If Tcomb syntax is Flow-compatible can we have both sides of the coin

Yes, it would be great. Unfortunately all my attempts are failed. I suspect it's not possible but I'm open to suggestions.

All I could do is add support for primitive types:

• string -> t.String
• number -> t.Number
• boolean -> t.Boolean
• Array -> t.Array
• Function -> t.Function
• Object -> t.Object
• any, mixed -> t.Any

That would be easy, the real problem comes when you consider first-class types:

const Person = t.struct({
  name: t.String
})

// Flow and TypeScript don't understand Person here
const foo = (person: Person) => ...

Readme does not mention that "syntax-flow" and "transform-flow-strip-types" plugins are required.

Thanks for pointing out

[ivan-kleshnin]

Thanks for the answer.

I suspect it's not possible but I'm open to suggestions.

Unfortunately, I don't even know Flow 😞
But I also guess it's close to impossible until Flow exposes some kind of toolkit for that.

[gcanti]

Closing in favour of #11