[moved to haskell-cafe] On Wednesday 10 May 2006 11:09 am, Doug Kirk wrote:
Hi,
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 characteristics:
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:
Invariant
| 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 directly?
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 constructors.
BTW, I am using UUST Parser Combinator AG for the parser definition, in case that makes a difference.
Thanks! --doug