[Haskell-beginners] accessor function scope

[Daniel Fischer]

Am Dienstag 07 April 2009 11:47:32 schrieb Michael Mossey:
> Francesco Bochicchio wrote:
> > me too :-)
> >
> >
> >     Again, StaffItem and TextItem resemble derived classes in OO.
> >
> >
> > To me, they are more close to C union : a data type than can
> > alternatively have different structures,

Both analogies capture some aspects of Haskell types. They're useful if you 
are aware that they take you only so far.

> > In your example, LayoutItem is a type name, while StaffItem and TextItem
> > are constructor, that is functions.
> > Saying that a function specializes a type is a bit of a stretch, I think
> > ...
> >
> > Nevertheless, they can sometime be used to accomplish the same goal :
> > where in OO you define an abstact class and then
> > specialize with concrete classes to model a classification, in haskell
> > you can define a data type with alternate constructors.
> >
> > I think that data types with alternate constructores are called
> > algebraic data types in haskellese, but I'm not sure of that ...

Yes, they're called algebraic datatypes, but I'm not sure if a type must have 
more than one constructor to qualify as such.

>
> Here's what I've learned from my investigations, but I welcome any
> clarifications.
>
> There are a few ways they don't resemble constructors in OO, or unions in
> C.
>
> They are "constructors", but also "take apart" the item in pattern
> matching. myfunc (StaffItem pos dimension) = ...
> myfunc (TextItem pos dimension) = ...
>
> You can also hide the constructors when you export a module. I could export
> LayoutItem but not StaffItem and TextItem, meaning that other code would
> see LayoutItem as a kind of abstract base class.
>
> When you name a field in each constructor (the same name), you can access
> that field on any LayoutItem without knowing its constructor using the
> accessor function for that field. This looks a lot like an abstract base
> class.
>
> data LayoutItem = TextItem { myField :: Int }
>
>                  | StaffItem { myField :: Int }
>
> x1 = TextItem { myField = 3 }
> x2 = STaffItem { myField = 4 }
>
> y1 = myField x1
> y2 = myField x2
>
> When I tried to make TextItem and StaffItem instances of a class, I got an
> error. They aren't really types. Only LayoutItem is the type.
>
> instance Eq TextItem where ...
> ---> ERROR!
>
> instance Eq StaffItem where ...
>
> ---> ERROR!
>
> instance Eq LayoutItem where...
> ---> ok
>
> Right now I'm just confused by how to translate an exising OO design. I'm
> porting a partially complete Python program to Haskell. There are many
> options. For instance I could set up a class called LayoutClass, make
> TextItem and StaffItem their own classes and make them instances of the

"their own types"

> class.
>
> -- Note: Now I can no longer have any overlapping field names
> data TextItem = TextItem { tField1, tField2 :: Int }
> data StaffItem = StaffItem { sField1, sField3 :: Int }

For fields that are generic enough to be interesting, you can have

class HasPosition a where
	pos :: a -> Position

class HasDimension a where
	dim :: a -> Dimension

class HasField1 a where
	field1 :: a -> Int

instance HasField1 TextItem where
	field1 (TextItem f1 _) = f1

>
> class LayoutClass a where
>    access1 :: a -> Int
>
> instance LayoutClass TextItem where
>    access1 (TextItem t) = tField1 t
>
> instance LayoutClass StaffItem where
>    access1 (StaffItem s ) = sField1 s
>
> Or put everything in its own module and use qualified names. Probably the
> best choice for future considerations.

Consider also the "class HasWhatever" approach, sometimes it's better than 
qualified names.