Add typescript supports

[mizunashi-mana]

Suggestions

• Define TypeScript definition
• Add them on DefinitelyTyped.
• Fix existing types supporting fantasy land.

Notes

TypeScript can add types without any binding codes. So, we can support TypeScript just to write type definition codes.
TypeScript manage definitions on main definitions repository, DefinitelyTyped.
Already, some definitions of library supporting fantasy land (parsimmon, tsmonad, etc.) were added.

However, the types of each library were defined by some contributors and has some differences...
I would like you to define TypeScript type signatures of fantasy land for TypeScript and fantasy land user.

That has good influences for us.
Thanks!

[joneshf]

If you can type Functor in TypeScript, then go for it. Last I checked, you couldn't.

[mizunashi-mana]

@joneshf
Actually, I usually use types of TsMonad now.
And, we can use these.

Functor:
https://github.com/cbowdon/TsMonad/blob/master/monad.ts#L97

[mizunashi-mana]

Oh... Apply type cannot write in TypeScript...

This is illegal typescript code, but I wanted.

interface Apply<(t: T) => U> {
   ap(u: U): U; 
}

interface Apply<T> {
}

However, Apply type is very strange for me. I think all Apply data must have ap method. Functor type ( map :: Functor f => f a -> (a -> b) -> f b ) is good for me.
If we will support typescript for fanrasy-land, we change Apply type to:

a.ap(f); // a :: A<T>, f :: A<(T => U)>, a.ap(f) :: A<U>

or

A.ap(a, f); // a :: A<T>, f :: A<T => U>, A.ap(a, f) :: A<U>

In this cases, the typescript types are:

interface Apply<T> {
  ap<U>(f: Apply<(t: T) => U>): U;
}

or

interface Apply<T> {
  ap(a: T, f: Apply<(t: T) => U>): Apply<U>;
}

interface ApplyStatic<T, U> {
  new(...args: any[]): Apply<any>;
  ap(a: Apply<T>, f: Apply<(t: T) => U>): Apply<U>;
}

Maybe and Either of TsMonad are not supported Apply and Applicative. The reason may be this problem...

[SimonRichardson]

How do you do a natural transformation in typescript as well or high order
types. I think you'll hit road blocks a lot and I wonder if it would be
worth it, esp. when you work with free monads and coyoneda.

On Wed, 11 May 2016, 20:31 Mizunashi Mana, notifications@github.com wrote:

Oh... Apply type cannot write in TypeScript...

This is illegal typescript code, but I wanted.

interface Apply<(t: T) => U> {
ap(u: U): U;
}
interface Apply {
}

However, Apply type is very strange for me. I think all Apply data must
have ap method.
If we will support typescript for fanrasy-land, we change Apply type to:

a.ap(f): // a :: A, f :: A<(T => U)>, a.ap(f) :: A

or

A.ap(a, f); // a :: A, f :: A<T => U>, A.ap(a, f) :: A

In this cases, the typescript types are:

interface Apply {
ap(f: Apply<(t: T) => U>): U;
}

or

interface Apply {
ap(a: T, f: Apply<(t: T) => U>): Apply;
}
interface ApplyStatic<T, U> {
new(...args: any[]): Apply;
ap(a: Apply, f: Apply<(t: T) => U>): Apply;
}

Maybe and Either of TsMonad are not supported Apply and Applicative. The
reason may be this problem...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#140 (comment)

[mizunashi-mana]

I understood we cannot natural transforming in typescript. TypeScript has some problems on type system. Yoneda type can write on TypeScript because this type is only running. But, CoYoneda cannot.
So, we cannot provide full support for TypeScript.

However, I think we can provide main support (Monad/Monoid/Traversal).
This may be also helpful for JavaScripter.

Notes

In TypeScript:

const m = (Functor<A>)Identity(new A());
m.equals(a => Identity(new A()); // this will be compile error

But, this will be ok:

interface Functor<T> {
  map<U>(f: (t: T) => U): Functor<U>;
}

interface Eq<T> {
  equals(t: T): boolean;
}

class A<T> implements Functor<T>, Eq<A<T>> {
  map<U>(f: (t: T) => U): A<U> { return new A(); }
  equals(a: A<T>): boolean { return true; }
}

new A().map(a => a).equals(new A());

So, that cases, we cannot:

function fmap<T, U>(f: (t: T) => U): (g: Functor<T>) => Functor<U> {
  return a => a.map(f);
}

fmap(a => a)(new A()).equals(new A()); // compile error

In this cases, TypeScript user force to cast types...

[SimonRichardson]

You've just shown why the typescript support is pointless from my point of view, by all the notes and changes you've suggested that are required.

I just think the typescript system is too restrictive, by not being free enough (oxymoron considering we're talking about JavaScript).

👎 from me

[mizunashi-mana]

Ok, I considered deeply, Apply design is well and to change this design effects some wrong for javascript fantasy land user. And, typescript support is not well for this project.

I'm sorry for taking your time 🙇 .

[SimonRichardson]

I'm sorry for taking your time

Please note, the issue wasn't about your proposal, but about the fact that TypeScript is limited by its very nature. Therefore the gains/rewards that we get from it are limited and may even restrict the future additions to the specification.

Having said all of this, there isn't anything stopping you from making the repo hosted somewhere else though, if you do get a benefit from having the TypeScript definitions.

[mizunashi-mana]

@SimonRichardson
I see.
However, I cannot define Apply type on TypeScript. Adding TypeScript definitions limit APIs for libraries supporting fantasy-land, and I think that disadvantages are greater than advantages providing standardization.

So, I stop declaring TypeScript types.
Thanks.

[joneshf]

@joneshf
Actually, I usually use types of TsMonad now.
And, we can use these.

Functor:
https://github.com/cbowdon/TsMonad/blob/master/monad.ts#L97

Tell me if I'm wrong here (since I don't know typescript that in-depth), but that doesn't seem to describe Functor properly. It allows the implementer to specify which values they want to work with. Functors don't get to make that choice. Given that interface could we not change this line: https://github.com/cbowdon/TsMonad/blob/f359e2d772a7d6f5d21eba3ba4db85be5a1bd83b/maybe.ts#L54 to the following (and the subsequence implementation) and still have everything typecheck?

export class Maybe<T> implements Monad<T>, Functor<boolean>, Eq<Maybe<T>> {

[mizunashi-mana]

@joneshf
I understood your talking about. TsMonad's interface is wrong. Sorry.

However,

class Maybe<T> {
  fmap<U>(f: (t: T) => U): Maybe<U> { ... }
}

this one can be Functor, cannot? The TsMonad Functor interface can be a helper for declare type.
That will be compile error.

class Maybe<T> implements Functor<boolean> {
  fmap<U>(f: (t: T) => U): Maybe<U> { ... }
  /* fmap(f: (t: boolean) => boolean): Maybe<T> { ... } // can define */
  /* fmap<U>(f: (t: boolean) => U): Maybe<U> { ... } // also can define... */
}

Actually, I'm usual using PureScript, so, not deep TypeScript user. So, maybe, there are some solutions I don't know.

[joneshf]

Sorry, I wasn't very clear.

The last example is what I meant.

class Maybe<T> implements Functor<boolean> {
  fmap<U>(f: (t: boolean) => U): Maybe<U> { ... }
}

That's not a Functor.

But you're right, the first example is a Functor. This one:

class Maybe<T> {
  fmap<U>(f: (t: T) => U): Maybe<U> { ... }
}

You can define them inline to a class, you just can't abstract out the interface with typescript.

[mizunashi-mana]

@joneshf
I see. That is exactly right. Such code has problems.

function void<T extends Functor<U>, U, R extends Functor<{}>>(fa: T): R {
  return fa.fmap(a => ({}));
}

That type signature passed that:

function void<T extends Functor<U>, U, R extends Functor<{}>>(fa: T): R {
  return Maybe.Just({});
}

I understood that TsMonad's Functor interface is wrong for that cases.
Thanks.