interesting. it leads to something that feels much more like an object
based, as opposed to a class based, system.
as far as haskell is concerned, everything has the same type, even
though different instances have very different behavior.
instance variables are captured by the closures that define the object
methods, through the instance construction functions.
i get the feeling that a model like 'self''s , based on prototypes,
would not be that hard to implement.
i should have the equivalent example with this style done soon.
the question is, which plays nicer with the rest of haskell? that is,
if i'm not committing to a closed dsl, which style is more likely to
be reusable against other libraries.
my experience so far has been with parsers and type checkers that make
extensive use of pattern matching, which is why I probably gravitated
towards the type class with existentials solution. but my experience
is limited.
On 2/26/07, apfelmus@quantentunnel.de
Tim Docker wrote:
Steve Downey wrote:
So, I've been working on a Composite example. I've used existential types to have a generic proxy to the base type, rather than a simple algebraic type, since adding new leaves to the algebraic type means modifying the whole type, a violation of the Open-Closed principle (open for extension, closed for modification)
Rather than using existential types, a simple record of functions can be often be useful. ie:
data Component = Component { draw :: String add :: Component -> Component }
It might be worth comparing this approach with the (more complex) one you have described.
The point about existential types is that every class like IComponent that allow as useful existential like
data Component = forall e.(IComponent e) => Component e
can be put into the record form Tim mentions. See the old wiki pages at
http://haskell.org/hawiki/ExistentialTypes
This is because every such IComponent has to look like
class IComponent e where foo1 :: e -> ... -> e ... bar1 :: e -> ... ...
where the dots in "-> ..." must not contain the type variable e.
Regards, apfelmus
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe