Re:Microsoft takes .NET open source and cross-platform
by Locke1689 on Wednesday November 12, 2014 @12:45PM
(#8596912)
So I guess the pitch is: imagine C# async/await could be "just a library", and other contexts that you wanted to handle similarly could also be a library, and the resulting functions are first-class citizens in the type system (no awkward choices of whether a particular function is async or not, you can handle that generically).
That's true in F# -- async is just a library in a computation expression.
Re:Microsoft takes .NET open source and cross-platform
by yohanatan on Wednesday November 12, 2014 @03:13PM
(#8597844)
> F# has a number of these specific implementations but they're kind of "hard-coded" in the language rather than fully extensible.
That's not true. You can extend the language yourself with "computation expressions" (and that's in fact how the 'async', 'let!' et al keywords are implemented).
Re:Microsoft takes .NET open source and cross-platform
by lmm on Thursday November 13, 2014 @04:42AM
(#8600696)
True, but what you can't do is abstract over them; you can't write a function that operates on "some generic computation expression" (you can't even write that type). So you can't write "sequence" or "traverseM" or more complicated/specific things you build on top of these.
Re:Microsoft takes .NET open source and cross-platform
by yohanatan on Thursday November 13, 2014 @05:33PM
(#8604606)
There is an encoding supporting that level of abstraction (perhaps though not as straightforward as you'd prefer); namely using interfaces (which are first-class) to encode module signatures. See: https://gist.github.com/t0yv0/192353
It takes a while for your code to get big enough for the last part to matter, but it's huge when it does - you can handle any kind of "context" in a generic way, e.g. async calls, error handling, audit logging, software transactional memory, or custom things for e.g. database access. F# has a number of these specific implementations but they're kind of "hard-coded" in the language rather than fully extensible. So I guess the pitch is: imagine C# async/await could be "just a library", and other contexts that you wanted to handle similarly could also be a library, and the resulting functions are first-class citizens in the type system (no awkward choices of whether a particular function is async or not, you can handle that generically).