4 ms·
Yeah it seems it would be much more useful with TypeScript as the substrate given its structural typing features. e.g. Declare interfaces that do the type class
by tlarkworthy 11y ago
Yeah it seems it would be much more useful with TypeScript as the substrate given its structural typing features. e.g. Declare interfaces that do the type class stuff, then any object that meets the interface critera can be used in those methods, without ever having to nominate the object as implementing the said interface. You have have parameterized interfaces too, so the functions can be pretty flexible.
- spion 11y agoUnfortunately TypeScript doesn't support higher kinded types, so you can't write interfaces for most of Haskell's most popular typeclasses. And there is something that a dynamic (and/or gradually typed) languages will never be able to do: function overload based on the function's return type, e.g. like Haskell's `return` :) edit: oh wait, after monad of no return its `pure` :D
- nbouscal 11y agoEven if MRP goes through, it'll almost certainly still be `return` for most people for a very long time. It just won't be part of the typeclass :)
- tlarkworthy 11y agoI was pleasantly surprised how far the type system goes though. Thanks to structural typing I get the pipe operator even for things I do not declare as SignalTransformers in the following: interface SignalFn<T> { (time: number): T; } interface SignalTransformer<A, B>{ (a: SignalFn<A>): SignalFn<B> } // the >>> function function pipe<A,B,C> (a: SignalTransformer<A,B>, b: SignalTransformer<B,C>): SignalTransformer<A,C> { return (x: SignalFn<A>) => b(a(x)) } // the arr lift function lift<A, B>(fn: Function1<A,B>): SignalTransformer<A,B> { return (input: SignalFn<A>) => <SignalFn<B>>((time: Time) => fn(input(time))); }