2009/7/29 Luke Palmer <lrpal...@gmail.com>:
> On Wed, Jul 29, 2009 at 10:15 AM, Paul Sujkov<psuj...@gmail.com> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
