71–80 of 125 posts
I thought isomorphism was when a function was reversible. I didn't think it had anything to do with currying.
> According to currying, 'a -> 'b -> 'c is interchangeable with 'a * 'b -> 'c. (The fancy math word for this interchangeability is "isomorphism.") I thought isomorphism was when a function was reversible. I didn't think it had anything to do with currying.
The witnesses in Haskell are the higher-order functions (they transform functions) `{,un}curry`:
curry :: ((a, b) -> c) -> (a -> b -> c)
uncurry :: (a -> b -> c) -> ((a, b) -> c)there's an equivalent definition of Applicative that may be a bit less intimidating: class Functor f => Applicative f where unit :: f () (**) :: f a -> f b -> f (a,b) [source - a bit CT heavy]( https://stackoverflow.com/a/35013667/5534735 ) (i'll be writing the second operation as `××` in some places because of HN asterisk weirdness) this gives us: - `unit`, a "template" container with a hole we can fill (by doing `f…
Huh? I cover this definition in the tutorial, when I discuss OCaml's (and+) operator! Did I gloss over things too quickly?
here’s the paper: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b...
I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying…
OCaml (Reason) was my entry point into Typed FP (after a few failed attempts at learning Haskell). The best thing about OCaml is that it allows side-effects, so one can go a long way without having to touch advanced FP. It is only recently that I've started getting comfortable with concepts cogently explained in this post, so to me it is quite valuable. As an aside, I think OCaml/Reason/Elm should become the de-facto…
It works on almost any platform, be it web, mobile, desktop or server via Fable, Xamarin or .NET Core.
It can work as an object-oriented language as well, which makes it easier to interface with C# code, but the documentation makes it very clear that functional is the way to go for F#.
For UIs there are libraries like Fabulous and Elmish, that provide a very similar programming model as Elm does.
You can even share code between all your target platforms:
> According to currying, 'a -> 'b -> 'c is interchangeable with 'a * 'b -> 'c. (The fancy math word for this interchangeability is "isomorphism.") I thought isomorphism was when a function was reversible. I didn't think it had anything to do with currying.
Hom(A * B, C) ~ Hom(A, C ^ B)
This is one of the laws of a Cartesian closed category. The simply typed lambda calculus with products is the internal language of a Cartesian-closed category.
Earlier quoted context omitted.
Thanks for this short explanation. The benefits of these patterns were not clear to me just from reading the article. Questiob: is the idea always to think in terms of types as groups of values + some operations on those types such that ?
It's important not to think of types as just sets of values, because types are more semantic than that; two quite different types might have the same underlying values but they're different types because you use them to mean something different. A typeclass is one or two levels higher than a type, and yes, for a type to conform to a typeclass usually means that that type supports particular operations in a way that c…
Earlier quoted context omitted.
This is correct, and in contrast to Haskell, where monads are a core part of the language (they are used in the definition of do-notation and list comprehensions) and currently the mainstream way to do IO.
This is misleading. There's no place in the specification of Haskell that specifically defines monads as part of the language. They aren't a language feature. They are a pattern which happens to be expressible in Haskell, and which is supported by libraries: "Haskell's built in support for monads is split among the standard prelude, which exports the most common monad functions, and the Monad module, which contains l…
> A do expression provides a more conventional syntax for monadic programming
Earlier quoted context omitted.
This is correct, and in contrast to Haskell, where monads are a core part of the language (they are used in the definition of do-notation and list comprehensions) and currently the mainstream way to do IO.
This is misleading. There's no place in the specification of Haskell that specifically defines monads as part of the language. They aren't a language feature. They are a pattern which happens to be expressible in Haskell, and which is supported by libraries: "Haskell's built in support for monads is split among the standard prelude, which exports the most common monad functions, and the Monad module, which contains l…
An important realization that I had was that monads/functors/applicatives aren't patterns in the sense of design patterns. You don't solve a singular problem with a monad. With something like a strategy pattern you have a concrete problem: how do I select different potential algorithms? Monads don't have a specific problem that they solve. Any attempt to motivate monads in such a manner falls flat because the problem…
Your description means they are design patterns: a technique to solve a problem that appears repeatedly. What trips people up is that monad is a 2nd-level pattern, as can be seen in the type. 'List a' is-a pattern for nondeterminism. 'Maybe a' is-a pattern for handling failure. Instancing 'm a' is a pattern for 'sequencing effects with branching' and also other patterns for various other applications.
In OOP design patterns not only solve a specific problem, they are only used to solve the problem (no need to sprinkle the visitor-pattern all over your classes just because it's possible). Monad/Functor etc. instances are defined where they are possible. I view them as making inherent properties visible and explicit ("this action obeys these laws").
They are used to solve problems, but mainly by making abstract properties directly visible and reminding the programmer that he can just view them as this abstract concept and reuse existing machinery.