When I'm designing datatypes for a Haskell program, I sometimes seem to end up with a slightly incoherent mixture of algebraic types and constructors. I'm wondering if anyone has worked out a principled way to decide when to introduce a new data type.

Here's an example from something I'm working on:

[[
data Event = Document DocURI Element
| Element Name BaseURI Language Children Attributes LiIndex Subject
| EndElement
| Attribute Name AttributeVal
| Text TextVal
]]
(abbreviated from the original for discussion, and using arbitrary type names for the field types)


Using this formulation, I have no access to the type of the different alternatives of the Union type thus defined. A different way of describing the type overcomes this limitation:
[[
data Event = EVDocument Document
| EVElement Element
| EVEndElement EndElement
| EVAttribute Attribute
| EVText Text


data Document = Document DocURI Element

data Element = Element Name BaseURI Language Children Attributes
                       LiIndex Subject

data EndElement = EndElement

data Attribute = Attribute Name AttributeVal

data Text = Text TextVal
]]
which seems to be rather repetitious. And I haven't even started to use the named field syntax here.


Yet another alternative, if I'm not interested in field names, might be to use tuples and type synonyms for the alternative values:
[[
data Event = Document EVDocument
| Element EVElement
| EndElement EVEndElement
| Attribute EVAttribute
| Text EVText


type EVDocument = (DocURI,Element)

type EVElement = (Name,BaseURI,Language,Children,Attributes,LiIndex,Subject)

type EVEndElement = ()

type EVAttribute = (Name,AttributeVal)

type EVText = TextVal
]]

Is there any community consensus concerning what constitutes good style in such circumstances?

#g


------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to