3 ms·

An insight I found quite interesting: oo style is great at extending types. You can add a subtype at a later date without modifying existing code and it just w

by Tarean 10y ago

An insight I found quite interesting: oo style is great at extending types. You can add a subtype at a later date without modifying existing code and it just works. Functional style is great at extending behavior. You can take an existing type and implement new functions on it. This means you can have a lot of functions defined on a basic data type which is amazing for composition but you can't add a new type that works with the same methods if you didn't anticipate this need.

bad_user 10y ago
"Function style" can also be OOP, FP being imo orthogonal, although it is true that in practice, with FP, polymorphism is usually achieved with parametric polymorphism because they play well together. Speaking of parametric polymorphism, the need to modify a type's behaviour by implementing a new type is alleviated if you go with higher-kinded polymorphism, where the implementation bits are abstracted by a generic F[_] type and using type classes to go along with that. In the example I'm giving in that presentation, I'm implementing a type named Iterant, for which the plugged-in F[_] can dramatically modify its behaviour. So in practice you don't need to implement a new kind of Iterant, which wouldn't make much sense anyway, you only need to implement a new F[_], which is used to abstract away the details of how Iterant gets evaluated, which is the part that people want to change. Unfortunately most statically typed mainstream languages are not capable of expressing such abstractions due to lack of higher kinded types, or ways to encode / express type-classes, although this part is less problematic than lack of HKTs.
tjalfi 10y ago
This is called the expression problem. http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt http://homepages.inf.ed.ac.uk/wadler/papers/expression/expre... http://stackoverflow.com/a/2079678 http://stackoverflow.com/a/2079678 is a great SO answer on this topic.
- pron 10y ago
  The expression problem has a complete and rather elegant solution in mainstream OO languages with generics, invented in 2012 called object algebras: Video: https://www.infoq.com/presentations/object-algebras https://www.infoq.com/presentations/object-algebras Paper: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf I understand that there is a comparable solution in FP languages called finally tagless interpreters: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...
  - kvb 10y ago
    Vesa Karvonen posted a complete solution in SML here[1] (but LtU seems to be down so the link doesn't work), which I transliterated (directly, not idiomatically) to F# here[2]. [1] http://lambda-the-ultimate.org/node/2232#comment-31278 http://lambda-the-ultimate.org/node/2232#comment-31278 [2] http://fssnip.net/gn http://fssnip.net/gn

by Tarean 10y ago

bad_user 10y ago

"Function style" can also be OOP, FP being imo orthogonal, although it is true that in practice, with FP, polymorphism is usually achieved with parametric polymorphism because they play well together. Speaking of parametric polymorphism, the need to modify a type's behaviour by implementing a new type is alleviated if you go with higher-kinded polymorphism, where the implementation bits are abstracted by a generic F[_] type and using type classes to go along with that. In the example I'm giving in that presentation, I'm implementing a type named Iterant, for which the plugged-in F[_] can dramatically modify its behaviour. So in practice you don't need to implement a new kind of Iterant, which wouldn't make much sense anyway, you only need to implement a new F[_], which is used to abstract away the details of how Iterant gets evaluated, which is the part that people want to change. Unfortunately most statically typed mainstream languages are not capable of expressing such abstractions due to lack of higher kinded types, or ways to encode / express type-classes, although this part is less problematic than lack of HKTs.

tjalfi 10y ago

This is called the expression problem. http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt http://homepages.inf.ed.ac.uk/wadler/papers/expression/expre... http://stackoverflow.com/a/2079678 http://stackoverflow.com/a/2079678 is a great SO answer on this topic.

pron 10y ago
The expression problem has a complete and rather elegant solution in mainstream OO languages with generics, invented in 2012 called object algebras: Video: https://www.infoq.com/presentations/object-algebras https://www.infoq.com/presentations/object-algebras Paper: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf I understand that there is a comparable solution in FP languages called finally tagless interpreters: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...
- kvb 10y ago
  Vesa Karvonen posted a complete solution in SML here[1] (but LtU seems to be down so the link doesn't work), which I transliterated (directly, not idiomatically) to F# here[2]. [1] http://lambda-the-ultimate.org/node/2232#comment-31278 http://lambda-the-ultimate.org/node/2232#comment-31278 [2] http://fssnip.net/gn http://fssnip.net/gn