Re: [Haskell-cafe] Base classes can be _ELIMINATED_ with interfaces
Shelby Moore wrote: ...A type class is a polymorphic (relative to data type) interface, and the polymorphism is strictly parameterized for the client/consumer of the interface, i.e. the data type is known to the function that inputs the interface AT COMPILE TIME. ...A problem with virtual (runtime pointer) inheritance is that it hides the subclass from the compiler. I emphasize that in Haskell, the consuming function knows the interface at compile time (or it can allow the compiler to infer it, if no type class restriction is specified). Caveat follows. The fundamental theorems I mentioned ( http://www.haskell.org/pipermail/haskell-cafe/2009-November/068432.html ), can not be voided by any programming language that is Turing complete. Thus, it is no surprise that dynamic run-time typing is achievable in Haskell[1], basically a punt of the attempt of strict typing exponential local order (which the theorems predict _MUST_ happen in some cases, unless there is no state diagram), to run-time nondeterminism due to Liskov Substitution Principle (and Linsky Referencing). Alas (good news!), local exponential order wins in vast majority of common use cases in Haskell because it is also possible to use static compile-time typing[1], which I assert is because the static typing architecture is granular and orthogonal. [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html#language http://research.microsoft.com/en-us/um/people/simonpj/papers/hmap/gmap3.pdf Ralf Laemmel and Simon Peyton Jones. Scrap your boilerplate: a practical approach to generic programming, Proc ACM SIGPLAN Workshop on Types in Language Design and Implementation (TLDI 2003), New Orleans, pp26-37, Jan 2003 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Base classes can be _ELIMINATED_ with interfaces
The style of OOP is irrelevant, and if one means by style the conflation of the interface with the data and/or use of virtual (runtime) base class inheritance and the style of that induces, then it is an architectural mistake: http://www.haskell.org/pipermail/haskell-cafe/2009-November/068433.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Base classes can be _ELIMINATED_ with interfaces
Shelby Moore wrote:
...A type class is a polymorphic
(relative to data type) interface, and the polymorphism is strictly
parameterized for the client/consumer of the interface, i.e. the data type
is known to the function that inputs the interface AT COMPILE TIME.
...A problem with virtual (runtime pointer) inheritance is that it hides
the subclass from the compiler.
I emphasize that in Haskell, the consuming function knows the interface at
compile time (or it can allow the compiler to infer it, if no type class
restriction is specified).
...if one means by style the
conflation of the interface with the data and/or use of virtual (runtime)
base class inheritance and the style of that induces, then it is an
architectural mistake...
One explanation of how extends (base class) does impact composability:
http://www.haskell.org/pipermail/haskell-cafe/2009-October/068337.html
Instead encapsulate (inherit) data type orthogonal to type class
(interface) in Haskell:
http://www.haskell.org/pipermail/haskell-cafe/2009-October/068328.html
The point of that whole rant is that extending data-bearing classes
isn't necessarily a good idea, so before trying to find a way to do it
with haskell, it may be better to just encapsulate another data type,
which is trivial:
data InnerThing = A | B | C
data OuterThing = Outer { innerThing :: InnerThing, otherField :: Int }
Additionally note:
Shelby Moore wrote:
In Haskel, subtyping is done with Module...
data is analogous to a public class members. Use Module to make some
implementation private:
http://www.cs.auckland.ac.nz/references/haskell/haskell-intro-html/modules.html#sect9.2
Thus use type classes (interfaces) when consuming the public Module
interfaces in functions (i.e. only consume the exported Module interfaces
in the sense they implement a type class, never directly consume the
Module name space).
I realize some examples would make the above easier to visualize.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
