Send Beginners mailing list submissions to
        beginners@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
        beginners-requ...@haskell.org

You can reach the person managing the list at
        beginners-ow...@haskell.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."


Today's Topics:

   1. Re:  Converting a data type to an abstract data   type (Kim-Ee Yeoh)
   2. Re:  Converting a data type to an abstract data   type (Ryan Warner)
   3. Re:  Converting a data type to an abstract data   type
      (Rein Henrichs)


----------------------------------------------------------------------

Message: 1
Date: Wed, 16 Sep 2015 23:57:26 +0700
From: Kim-Ee Yeoh <k...@atamo.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Converting a data type to an abstract
        data    type
Message-ID:
        <CAPY+ZdRv_R=8pwoy55_xovf9od_+yisejnl7bri+6rhca61...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Wed, Sep 16, 2015 at 12:02 AM, Ryan Warner <
ryan.warner.mn+hask...@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-0001.html>

------------------------------

Message: 2
Date: Thu, 17 Sep 2015 01:42:56 +0000
From: Ryan Warner <ryan.warner.mn+hask...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Converting a data type to an abstract
        data    type
Message-ID:
        <CAMV_cL1fDi150SMitXkfZ9jc2veA8X7eQs22kHf5T-+=ea5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Wed, Sep 16, 2015 at 11:58 AM Kim-Ee Yeoh <k...@atamo.com> wrote:

>
> 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.
>
>
Thanks for pointing that out. I hadn't recognized that yet. Are type
signatures used sparingly in most Haskell code? Or as you say, is it coming
to formalize the signatures once the exploration is complete?

-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.haskell.org/pipermail/beginners/attachments/20150917/d61f5429/attachment-0001.html>

------------------------------

Message: 3
Date: Thu, 17 Sep 2015 06:49:01 +0000
From: Rein Henrichs <rein.henri...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Converting a data type to an abstract
        data    type
Message-ID:
        <cajp6g8wgzduwzzqz233dfjxog2s6mg3l_rzu2okllj92w7a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

> Are type signatures used sparingly in most Haskell code?

No, generally most Haskell code uses explicit top-level type signatures
everywhere. They provide useful guidance to the developer as much as (if
not more so than) the compiler.

If possible, you could use a type synonym for your type which keeps
changing. That way there would be only one place to make the change.

On Wed, Sep 16, 2015 at 6:43 PM Ryan Warner <ryan.warner.mn+
hask...@gmail.com> wrote:

> On Wed, Sep 16, 2015 at 11:58 AM Kim-Ee Yeoh <k...@atamo.com> wrote:
>
>>
>> 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.
>>
>>
> Thanks for pointing that out. I hadn't recognized that yet. Are type
> signatures used sparingly in most Haskell code? Or as you say, is it coming
> to formalize the signatures once the exploration is complete?
>
> -Ryan
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.haskell.org/pipermail/beginners/attachments/20150917/2e3f50e8/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


------------------------------

End of Beginners Digest, Vol 87, Issue 8
****************************************

Reply via email to