Moving to TypeScript in 3.0

Checklist

• Simplify build system (move away from Make) (started at #148)
• Replace Babel by TypeScript for compiling things
• Use JSDoc tags + TypeDoc for API reference (for now)
• Use Sphinx for documentation

Motivation

I did say that I’d take a look at TypeScript again a long while ago and I finally did, today. With some of the recent additions to TypeScript, writing things like Folktale in it is not too bad. The compiler services and the new metadata API, though? Those are very compelling (even though they’re both experimental). An initial 2.0 release is only really missing the Data.Future docs (which, if work allows, should happen sometime between this week and the next), so on to thinking about the future.

Moving to TypeScript would allow some very interesting features:

• Zero-cost verification of compositions as long as the person uses TypeScript;
• (maybe) Runtime contract checking derived from type annotations using the compiler API. This’d largely depend on the type checker providing usable types for this;
• Much better compiler infrastructure for tooling than Babel;
• Extracting minimal complete applications with whole-program compilation (aka tree-shaking);
• People who’re already using TypeScript would be happy, and I wouldn’t have to maintain a separate typings file. Everyone wins here, really.

OTOH, this would also mean that:

• We’d end up dropping the experimental “infix” APIs. This’d probably get dropped anyway since :: hasn’t gained much traction in TC39, and the last person who said they’d champion the proposal hasn’t said anything for quite a while;
• We’d need to build new documentation tooling. This isn’t actually too bad because the TypeScript compiler makes this a lot simpler than the Babel hacks. Plus we do get verified type signatures, which is very important to me (some of the type signatures in the current docs are wrong, btw);
• Things wouldn’t be based on the Core.ADT API anymore, since that requires a kind of dependent typing that TS doesn’t have. We could have some new experimental stuff based on decorators, which would probably end up looking like Scala’s sealed case classes. Not quite sure what to do with this yet though;
• Resources in Tasks would most likely have to be done differently to avoid any types;
• REPL docs wouldn’t work. But they’re not working right now anyway.
• Babel plugins also wouldn’t work, something’d have to be written for the x // ==> y assertions.

There’s also some other stuff to fix:

• Building Folktale is a pain, which in turn makes contributing to the project a pain. Make is not even cross-platform. Furipota will probably fix this, hopefully without increasing the build times too much at first (it won’t have caching for a while);
• We need something that supports prose and cross-references in the documentation properly. Everything right now is a hack, and it’s really hard to navigate. Prose and API references should also be separated, as they have very different use cases.
• Properly versioning the documentation. Keeping only the latest version is very confusing.

Docs will probably move back to Sphinx for the time being. But that means having to write plugins to test code automatically, and the Sphinx extension API is painful.

This work would subsume #65, of course.

[robotlolita]

@boris-marinov I think support for tagged unions was added in 2.1 or something. But that’s just on the types side, so it doesn’t help much with the runtime part of the things. Depending on how the pattern matching proposal goes on TC39 we might get some interesting stuff though. But that’s on the “far future” side of things, sadly.

@raveclassic work on the TS support will start after the final 2.0 version is released, which will hopefully be this weekend.

[snewell92]

While I was playing with the typings in #157 , the waitAll function for tasks seemed a little too restrictive, I think it might need overloads in order to allow what we can currently do in js with folktale 2:

let stringTask = Task.of("Hello");
let numTask = Task.of(5);

waitAll([stringTask, numberTask]);

let stringTask = Task.of("Hello");
let numTask = Task.of(5);

// Error here, because array is expected to have tasks return same type
//waitAll([stringTask, numberTask]);

// wrap waitAll function from folktale
let runAll2: <E, V1, V2>(tasks: [Task<E, V1>, Task<E, V2>]) => Task<E, [V1, V2]> =
  t => waitAll(t);
runAll2([stringTask, numberTask]);
// The error type is still the same,
//  but now we can have different values in the tuple (aka array)

$.02 - just something I came across. Relevant line in current WIP typings.