
2009/7/29 Luke Palmer
On Wed, Jul 29, 2009 at 10:15 AM, Paul Sujkov
wrote: Hi Luke,
I'm not pretty sure. The thing I don't like is the need to copy-and-paste all the code with enumeration constructors. So, now I have two types to make Type data from, but they could be many, so I'll have many almost identical makeTypeFromFoo-functions. The thing I need is something like (*):
makeType :: ? -> Type makeType c = case c of ("-$-" or 240) -> Status ("-M-" or 64) -> Message ("-W-" or 32) -> Warning
Well, you could write a helper like this:
matchType :: (Eq a) => (a,a,a) -> a -> Type matchType (status,message,warning) x | x == status = Status | x == message = Message | x == warning = Warning
To reduce the size of your specifications:
makeTypeStr = matchType ("-$-", "-M-", "-W-") makeTypeInt = matchType (240, 64, 32)
There are trade-offs to doing something like this. It's smaller, but harder to read as specification. But, because it uses a tuple, it will catch you if you add a new case but forget to add it to one of the makeType*s (providing you remember to change matchType).
What you're asking for puts all the conversions in the same place, which forbids them from being split out, decoupled, and modularlized. What if, instead of simple values, you had a more involved parser for these things?
Even though it's kind of verbose, I think what you already have is fine. You do have to repeat the names, but it is still content code, and the relationship of the content to the names is explicit. You might find tables like this in a user's manual for your software...
Hi, Maybe two simple association lists would be acceptable ? Cheers, Thu