Re: Functional design question

--===============3801329216570081831==
Content-Type: multipart/alternative; boundary="000000000000fe59c2064dba7ae2"

--000000000000fe59c2064dba7ae2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

glad to have helped! and by the way, a very useful resource for learning
about library functions you find in examples, and also finding out if
there's an established function that does something thing you need, is
Hoogle: https://hoogle.haskell.org/

you can search by function name OR by type signature, and for the latter it
will also find generic functions that could match a fixed-type search!

On Mon, Mar 23, 2026, 3:53=E2=80=AFPM <[email protected]> wrote:

> 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 detai=
l.
>
> 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 one=
s!
> 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 -- [email protected]
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
>

--000000000000fe59c2064dba7ae2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">glad to have helped! and by the way, a very useful resour=
ce for learning about library functions you find in examples, and also find=
ing out if there&#39;s an established function that does something thing yo=
u need, is Hoogle: <a href=3D"https://hoogle.haskell.org/">https://hoogle.h=
askell.org/</a><div dir=3D"auto"><br></div><div dir=3D"auto">you can search=
 by function name OR by type signature, and for the latter it will also fin=
d generic functions that could match a fixed-type search!</div></div><br><d=
iv class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Mon, Mar 23, 2026, 3:53=E2=80=AFPM  &lt;<a href=3D"mailto:jo@d=
urchholz.org">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">Thanks for all the feedback!<br>
<br>
I believe I found out the basic misdesign: Thinking in terms of <br>
functions that are married to a type, as you do in OO.<br>
The functional approach would be to have a single function that does the <b=
r>
conversion, broken down into subfunctions and thunks to manage each detail.=
<br>
<br>
I believe that OO is fine in many design situtations, but it seems it&#39;s=
 <br>
inappropriate for complex conversion tasks: Any intermediate step tends <br=
>
to know about both source and destination data type, which gives just <br>
the kind of coupling that a clean design does not have.<br>
I suspect it&#39;s better to have a big conversion function, composed of <b=
r>
subfunctions and thunks, freely being dependent on one, the other, or <br>
both data types, and once anybody tries to adapt this thing to other <br>
situations, you can still refactor the common pieces of code.<br>
<br>
So - I guess I answered my own question, but your input has been <br>
invaluable to get me out of my existing tracks so I could find better ones!=
<br>
And sorry for all the sidetracking thoughts. I had a feeling I was <br>
having some very fundamental misconception, but I just didn&#39;t know how =
<br>
to identify it, so I couldn&#39;t ask the right questions.<br>
<br>
Regards, and thanks again,<br>
Jo<br>
_______________________________________________<br>
Haskell-Cafe mailing list -- <a href=3D"mailto:[email protected]" ta=
rget=3D"_blank" rel=3D"noreferrer">[email protected]</a><br>
To (un)subscribe, modify options or view archives go to:<br>
Only members subscribed via the mailman list are allowed to post.<br>
</blockquote></div>

--000000000000fe59c2064dba7ae2--

--===============3801329216570081831==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Haskell-Cafe mailing list -- [email protected]
To (un)subscribe, modify options or view archives go to:
Only members subscribed via the mailman list are allowed to post.
--===============3801329216570081831==--