[instig007]

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

[gpderetta]

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

[jameshart]

Right, ‘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.

[moomin]

Yes, 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.

[instig007]

> 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 ;)