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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
