[Haskell-beginners] Converting a data type to an abstract data type

[Kim-Ee Yeoh]

On Wed, Sep 16, 2015 at 12:02 AM, Ryan Warner <
ryan.warner.mn+haskell at gmail.com> wrote:

> So I converted the Room to a parameterized datatype to allow me to
> relocate the textual description.


When I look at the diff, I see numerous changes to explicit top-level
signatures. If you're experimenting with data design at the keyboard, you
could leave out signatures and let the compiler infer them for you. That
way, there's so much you no longer need to refactor.

So, practice and planning will minimize the risk. But that only get's you
> so far, and a requirement change might require you refactor your code
> anyway. As you say, it minimizes, does not eliminate the risk.
>

Some requirement changes are just costly. In my neck of the woods, a house
that's 50% complete -- but where the owner then demands that it be
two-storey high and not just one -- will need to be torn down, have the
foundation buttressed to support the additional weight, and restarted from
scratch.

Getting the foundational data structures right is a bit like that.

(But you might chime in that, isn't this just like modifying SQL schemas,
and what about the whole NoSQL movement that started as a consequence? No
comment there.)

Other language have powerful refactoring tools, so I was wondering if there
> were some for haskell as well. Maybe there is a different design pattern I
> should be using here that would've have avoided this problem. If so, I'd
> love to know!


I mentioned about leaving out type signatures at the exploratory stage, but
even with your code, much of the repetitive work comes down to a global
search-and-replace for, e.g. "State ->" to "State r ->"

There's ghc-mod which isn't a refactoring tool but a library you could use
to write that tool with.

Some of the refactoring really can't be automated away. Suppose you add
another tag to a sumtype T. To remain well-defined, functions that have T
on the left of an arrow must now case on the new tag. The ghc option -W,
which invokes -fwarn-incomplete-patterns, will help you locate all such
functions.

But with a DRY codebase, the functions have duplication squeezed out of
them so extending them need to be done case-by-case. Beyond an editor that
jumps from line ref to line ref, what kind of automation do you envision
here?

Lastly, I'm not sure there really is a "different design pattern" that
would've help you dodge this. I'm old skool Dijkstra in that way. I noodle
about with pen and paper on the datatypes and the function signatures on
them. Once everything clicks and nothing seems left out, I'm ready to hit
the keyboard.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20150916/71aeea26/attachment.html>