New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving to TypeScript in 3.0 #115

Open
robotlolita opened this Issue Apr 22, 2017 · 9 comments

Comments

Projects
None yet
7 participants
@robotlolita
Member

robotlolita commented Apr 22, 2017

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.

@boris-marinov

This comment has been minimized.

Show comment
Hide comment
@boris-marinov

boris-marinov Jun 7, 2017

Contributor

Probably a tough decision, but definitely a correct one.

Doesn't Typescript support Sum types natively? In Flow you just need to add a "type" property to your object and define literal value for each subtype.

+1 for the comments on the build process.

Contributor

boris-marinov commented Jun 7, 2017

Probably a tough decision, but definitely a correct one.

Doesn't Typescript support Sum types natively? In Flow you just need to add a "type" property to your object and define literal value for each subtype.

+1 for the comments on the build process.

@robotlolita robotlolita removed the k:Design label Jun 10, 2017

@raveclassic

This comment has been minimized.

Show comment
Hide comment
@raveclassic

raveclassic Jul 3, 2017

Hi!
Any considerations on this or maybe plans? Recent TS 2.4 brings improvements to type system, maybe it could help?

raveclassic commented Jul 3, 2017

Hi!
Any considerations on this or maybe plans? Recent TS 2.4 brings improvements to type system, maybe it could help?

@robotlolita

This comment has been minimized.

Show comment
Hide comment
@robotlolita

robotlolita Jul 8, 2017

Member

@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.

Member

robotlolita commented Jul 8, 2017

@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.

@hojberg

This comment has been minimized.

Show comment
Hide comment
@hojberg

hojberg commented Jul 8, 2017

@snewell92

This comment has been minimized.

Show comment
Hide comment
@snewell92

snewell92 Oct 19, 2017

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.

snewell92 commented Oct 19, 2017

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.

@robotlolita

This comment has been minimized.

Show comment
Hide comment
@robotlolita

robotlolita Oct 22, 2017

Member

@snewell92 I forgot to consider that, thanks for reminding me :) We'll need some overloads for them indeed.

Member

robotlolita commented Oct 22, 2017

@snewell92 I forgot to consider that, thanks for reminding me :) We'll need some overloads for them indeed.

@robotlolita robotlolita modified the milestones: 2.1.0, 3.0.0 Dec 17, 2017

@robotlolita robotlolita changed the title from Moving to TypeScript in 2.1 to Moving to TypeScript in 3.0 Dec 17, 2017

@davidlibland

This comment has been minimized.

Show comment
Hide comment
@davidlibland

davidlibland Mar 22, 2018

When working on this issue, which branch should one fork off of?

davidlibland commented Mar 22, 2018

When working on this issue, which branch should one fork off of?

@robotlolita

This comment has been minimized.

Show comment
Hide comment
@robotlolita

robotlolita Mar 23, 2018

Member

@davidlibland ah, this one's not ready for collaborators yet

Member

robotlolita commented Mar 23, 2018

@davidlibland ah, this one's not ready for collaborators yet

@jfspencer

This comment has been minimized.

Show comment
Hide comment
@jfspencer

jfspencer May 11, 2018

@robotlolita when this is ready for collaborators I would like to help.

jfspencer commented May 11, 2018

@robotlolita when this is ready for collaborators I would like to help.

@robotlolita robotlolita removed this from the 4.0.0 milestone Jul 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment