On Wednesday 10 May 2006 11:09 am, Doug Kirk wrote:
> I'm a Haskell newbie, but not new to programming, and I have a
> question regarding style (I think).
> I'm writing a parser for OMG's OCL, and have two ways of defining the
> AST model of a constraint. Each constraint in OCL has the following 4
> 1. name :: Maybe String
> 2. context :: UmlElement
> 3. expr :: OclExpression
> 4. type :: OclConstraintType
> Now, having come from an O-O background, this looks right; however, in
> an FPL, it may not be. OclConstraintType is essentially an enumeration
> of the values:
> | Precondition
> | Postcondition
> | InitialValue
> | Derivation
> | Body
> The question is this: is it better to create a single type as above
> with a 'type' attribute, or would it be better to use the types as
> separate constructors of a Constraint, each constructor taking the
> same attributes?
Opinions may differ on this, bit I'm going to go out on a limb and say that
using separate constructors with the same field names is the more idiomatic
approach in Haskell.
Having a product type or a big record with an enumerated tag field is usually
just a way to simulate sum types. Why do that if the language supports them
> I'm looking to avoid any pitfalls that could occur with either
> decision, and at this point I don't know the benefits of doing it one
> way vs. the other.
So long as every constraint has exactly the same fields, there isn't much
practical difference. If later you discover that different kinds of
constraints need different fields, you'll be better off with the separate