4 ms·

I don't know category theory, so I defer to more knowledgeable people here, but that sounds strange: "Functor it understands how to take doStuff and execute it

by kika 10y ago

I don't know category theory, so I defer to more knowledgeable people here, but that sounds strange: "Functor it understands how to take doStuff and execute it on the value inside itself, then spit out a new Optional. You don't lose the int-ness or optional-ness." So if I map a function, that takes an int and returns a string over an array of ints, this array stops being a functor? Or is it just a Swift thing? And, as always, I urge people spend an hour of their life and get the explanation of all this from someone who knows the math but still able to explain this in plain English: https://www.youtube.com/watch?v=ZhuHCtR3xq8 https://www.youtube.com/watch?v=ZhuHCtR3xq8 To the best of my limited knowledge, it's all 100% correct.

VeejayRampay 10y ago
It's a great video, thanks. Watching it thinking the guy is sporting an afro is even better for some reason.
jstimpfle 10y ago
What he was getting at is that you can reuse functions which know nothing about the specific context (like, what container are we mapping over). It's not that you couldn't change the type of thing inside. A little more formally, if you have a functor F you can take some (a -> b) and make it into an (F a -> F b). For example, if F is [] (List), you get ([a] -> [b]). So [] adds something (a list "context"), but in a sense you don't lose anything (you can still reuse your (a -> b) which knows nothing about the context). That's the wonderful thing about these formal approaches: composability. (It's sometimes unfortunate that List has this special syntax).
- evincarofautumn 10y ago
  You can actually write the list constructor in prefix form if you like: [] a -> [] b
  - tome 10y ago
    And if you want to go really crazy type List = [] List a -> List b
    - evincarofautumn 10y ago
      type Function = (->) type On f g a b = f (g a) (g b) {-# LANGUAGE TypeOperators #-} (Function `On` List) a b <_<
catnaroek 10y ago
> this array stops being a functor? An individual array, as a runtime object, isn't, never was, and never will be a functor, as the term is used in this discussion. Rather, the functor is the type constructor of arrays itself (to be pedantic: the type constructor and the `map` function). In the grammar of most programming languages, type-level and value-level terms are kept separate, so not even in principle could you conflate a type constructor (a type-level entity) with a runtime object (a value-level entity). <rant> This is a very common problem. Most programmers are only used to reasoning about runtime objects, like “lists”, “sockets” and “windows”. Inasmuch as they talk about entities that don't have a runtime manifestation, like “types”, “preconditions” and “invariants”, these words are merely used as shorthand for things they want to say about runtime objects. Understanding how concepts from abstract algebra and category theory are applied to programming requires a change of mindset: the subject matter is no longer “what happens to this individual object”, but rather “what is the structure common to a large class of objects” and “how can this structure be used as the backbone of our algorithms”. This requires a new vocabulary in which abstract structures (which describe or constrain the representation of runtime objects, but don't have a runtime representation of their own) are first-class entities, so that you can say “the type constructor of immutable arrays is a functor” just as easily as you can already say “this runtime object is an array”. </rant>
- kika 10y ago
  > this array stops being a functor Okay, "the type of this array stops belonging to the typeclass of functors". Better? Peace? :-) I totally agree with your rant and I'm personally less than half way there myself, but this particular comment was within the context of the original article. I do understand the difference between the type and the value (instance). It's not even very hard for C++ programmers.

by kika 10y ago

VeejayRampay 10y ago

It's a great video, thanks. Watching it thinking the guy is sporting an afro is even better for some reason.

jstimpfle 10y ago

What he was getting at is that you can reuse functions which know nothing about the specific context (like, what container are we mapping over). It's not that you couldn't change the type of thing inside. A little more formally, if you have a functor F you can take some (a -> b) and make it into an (F a -> F b). For example, if F is [] (List), you get ([a] -> [b]). So [] adds something (a list "context"), but in a sense you don't lose anything (you can still reuse your (a -> b) which knows nothing about the context). That's the wonderful thing about these formal approaches: composability. (It's sometimes unfortunate that List has this special syntax).

evincarofautumn 10y ago
You can actually write the list constructor in prefix form if you like: [] a -> [] b
- tome 10y ago
  And if you want to go really crazy type List = [] List a -> List b
  - evincarofautumn 10y ago
    type Function = (->) type On f g a b = f (g a) (g b) {-# LANGUAGE TypeOperators #-} (Function `On` List) a b <_<

catnaroek 10y ago

> this array stops being a functor? An individual array, as a runtime object, isn't, never was, and never will be a functor, as the term is used in this discussion. Rather, the functor is the type constructor of arrays itself (to be pedantic: the type constructor and the `map` function). In the grammar of most programming languages, type-level and value-level terms are kept separate, so not even in principle could you conflate a type constructor (a type-level entity) with a runtime object (a value-level entity). <rant> This is a very common problem. Most programmers are only used to reasoning about runtime objects, like “lists”, “sockets” and “windows”. Inasmuch as they talk about entities that don't have a runtime manifestation, like “types”, “preconditions” and “invariants”, these words are merely used as shorthand for things they want to say about runtime objects. Understanding how concepts from abstract algebra and category theory are applied to programming requires a change of mindset: the subject matter is no longer “what happens to this individual object”, but rather “what is the structure common to a large class of objects” and “how can this structure be used as the backbone of our algorithms”. This requires a new vocabulary in which abstract structures (which describe or constrain the representation of runtime objects, but don't have a runtime representation of their own) are first-class entities, so that you can say “the type constructor of immutable arrays is a functor” just as easily as you can already say “this runtime object is an array”. </rant>

kika 10y ago
> this array stops being a functor Okay, "the type of this array stops belonging to the typeclass of functors". Better? Peace? :-) I totally agree with your rant and I'm personally less than half way there myself, but this particular comment was within the context of the original article. I do understand the difference between the type and the value (instance). It's not even very hard for C++ programmers.