Thanks for all the feedback!

I believe I found out the basic misdesign: Thinking in terms of
functions that are married to a type, as you do in OO.
The functional approach would be to have a single function that does the
conversion, broken down into subfunctions and thunks to manage each detail.

I believe that OO is fine in many design situtations, but it seems it's
inappropriate for complex conversion tasks: Any intermediate step tends
to know about both source and destination data type, which gives just
the kind of coupling that a clean design does not have.
I suspect it's better to have a big conversion function, composed of
subfunctions and thunks, freely being dependent on one, the other, or
both data types, and once anybody tries to adapt this thing to other
situations, you can still refactor the common pieces of code.

So - I guess I answered my own question, but your input has been
invaluable to get me out of my existing tracks so I could find better ones!
And sorry for all the sidetracking thoughts. I had a feeling I was
having some very fundamental misconception, but I just didn't know how
to identify it, so I couldn't ask the right questions.

Regards, and thanks again,
Jo
_______________________________________________
Haskell-Cafe mailing list -- haskell-cafe@haskell.org
To (un)subscribe, modify options or view archives go to:
Only members subscribed via the mailman list are allowed to post.