4 ms·
Your basic problem is that your programming language can’t express the concept cleanly. You need what’s called “Higher-Kinded Types”. To give you a concrete ex
by moomin 1y ago
Your basic problem is that your programming language can’t express the concept cleanly. You need what’s called “Higher-Kinded Types”.
To give you a concrete example, in C#
Func<A, B>, List<A> -> List<B>
Func<A, B>, Task<A> -> Task<B>
Func<A, B>, Func<C, A> -> Func<C, B>
Can’t be expressed using a generalisation. But in Haskell, you can write
(Functor F) => Func<A,B>, F<A> -> F<B>
One of the biggest things that makes monads hard to understand is that the type systems of most languages can’t represent them. Annoying, that includes the “typeless” ones.
- hollerith 1y ago>One of the biggest things that makes monads hard to understand is that the type systems of most languages can’t represent them. Annoying, that includes the “typeless” ones. Well, yeah, since a monad is a type, then a "typeless" PL will not be able to represent it.
- WorldMaker 1y agoC# is a fun example because there is ongoing work to support Higher-Kinded Types in it: https://paullouth.com/higher-kinds-in-c-with-language-ext/ https://paullouth.com/higher-kinds-in-c-with-language-ext/
- jameshart 1y agoI'm sorry, I'm not sure I understand entirely what you are trying to express by Func<A, B>, List<A> -> List<B> That said, in C#, you can write: List<A> listA; Task<A> taskA; Func<A, B> func; List<B> listB = from i in listA select func(i); Task<B> taskB = from t in taskA select func(t); And if it can resolve a method on List<T> called 'Select' that takes a Func<T, S> that returns a List<S>, and a method on Task<T> called 'Select' that takes a Func<T, S> that returns a Task<S> this will compile. In other words, I kind of think that Select methods (which can be Select extension methods, of course) amount to functors in C#?
- instig007 1y agonow write a single function that performs from x in xs select fn(x) and define a signature for it where `xs` and `fn` are the only input arguments, so that it accepts both `listB` and `taskB` without a compilation error.
- jameshart 1y agoRight, ‘some type that has a Select(Func<T, S>) method available’ is not a thing you can express in C# generic constraints. But I don’t need a function that does that, the language has syntax for it - I can just do that wherever I need it.
- instig007 1y ago> Right, ‘some type that has a Select(Func<T, S>) method available’ not just Select(Func<T, S>), but a Select(Func<T, S>) that preserves its original contextual instance of Select and doesn't leak into a different instance with Select. > But I don’t need a function that does that you don't need it yet ;)
- moomin 1y agoYes, but you can’t write something that’s generic over “things that support Select” because that’s not expressible via the type system. So you can’t write a function, then get a version that works on lists, then a version that works on tasks, then a version that works on nullables, then get a version that works on parsers. One if the big secrets on monads is that Haskell users don’t spend very much time thinking about them, while people without monads have to think about them all the time.
- gpderetta 1y agoIn C++: template<template<class> class Container, class T, invocable<T> Fn> Container<invoke_result_t<Fn, T> > map(Container<T> container, Fn fn) { return to<Container>(transform(container, fn)); } (Although idiomatically you wouldn't write the code this way). Whether that counts as HK types, I'll leave it to others to discuss.