5 ms·

The biggest power of Haskell (and other functional programming languages) is in the type system and the ability to abstract well (e.g. equals()), and these func

The biggest power of Haskell (and other functional programming languages) is in the type system and the ability to abstract well (e.g. equals()), and these functional functions are secondary. How do you suppose to replicate that in JS?

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 ago
  Unfortunately 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 ago
    Even 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 ago
    I 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))); }
thinkpad20 11y ago
I would agree with this. The ability to do things like complicated functional composition, 'flip', and other higher-order function tricks is in large part facilitated by Haskell's powerful and expressive type system, and of course established idioms and nice syntax which facilitates using those techniques in real-world code in a clear way. Unfortunately, without those things I feel like this comes across as a bunch of "cute tricks" rather than actual code you'd want to use in a code base (outside of personal projects perhaps). That, and the particulars of the functions are different because they are aimed at multi-parameter functions rather than currying, which makes their behavior different from their Haskell counterparts anyway.
icholy 11y ago
Symbols might enable something similar actually.
simplify 11y ago
JS Zero [1] is one approach. I would love to make it happen, but although I'm confident I can make the sublanguage design and developer experience great, I'm only familiar with basic type theory. It would be great to have even one interested expert join the project and help get the ball rolling. [1] http://js-zero.com/ http://js-zero.com/

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 ago
Unfortunately 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 ago
  Even 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 ago
  I 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))); }

thinkpad20 11y ago

I would agree with this. The ability to do things like complicated functional composition, 'flip', and other higher-order function tricks is in large part facilitated by Haskell's powerful and expressive type system, and of course established idioms and nice syntax which facilitates using those techniques in real-world code in a clear way. Unfortunately, without those things I feel like this comes across as a bunch of "cute tricks" rather than actual code you'd want to use in a code base (outside of personal projects perhaps). That, and the particulars of the functions are different because they are aimed at multi-parameter functions rather than currying, which makes their behavior different from their Haskell counterparts anyway.

icholy 11y ago

Symbols might enable something similar actually.

simplify 11y ago

JS Zero [1] is one approach. I would love to make it happen, but although I'm confident I can make the sublanguage design and developer experience great, I'm only familiar with basic type theory. It would be great to have even one interested expert join the project and help get the ball rolling. [1] http://js-zero.com/ http://js-zero.com/