[Haskell-cafe] : Gathering ideas for the Google Summer of Code

[Alexander Solla]

> Last year we worked hard to come up with a good list of projects for the
> 2010 Google Summer of Code. A  list drafted at ZuriHac is here:
>
>
> http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/
>
> And we ended up with quite a few of those funded,
>
>
> http://donsbot.wordpress.com/2010/04/26/the-7-haskell-projects-in-the-google-summer-of-code/
>
> Now is the time to think hard about student-sized projects that would be
> valuable this year.
>
> A great place to collect  these ideas, and discuss them, is the Haskell
> Proposals Reddit,
>
>    http://www.reddit.com/r/haskell_proposals/
>
> -- Don
>
I don't have a reddit account, so I'll post here.

One thing I would love to see is a "free theorem deriver" integrated into
GHC.  It would be lovely to have, say, a type class called "Free" or "Glue"
which takes in two two types and whose function represents a glue from the
first to the second.  It would be nice if those injections were derived,
say, by Djinn.  Consider my  comments (which I am reposting here, in
abridged form) from
http://www.palgorithm.co.uk/2010/05/why-isnt-haskell-popular-in-industry/ :

I just ignore the “line noise”. Line noise is nearly always glue code. I
don’t want that named. I just want it done. Yes, it can be hard to write
from scratch. But any sane Haskell development environment uses an
interactive environment like GHCi. If you use the type checker to guide you,
writing the glue becomes trivial. Encode logic in data types, and let the
glue write itself. If glue code type checks, it works, guaranteed. These are
free theorems. Focus on the important things: the stuff you’re gluing
together.
...
class Glue a b where
glue :: a -> b

and hide all the line noise in there. And then your client code will look
like

blah :: StateT (MaybeT IO) (Integer) (Maybe Integer)
blah = glue . parseInt . glue . getLine
– or
blah = glue $ parseInt $ glue $ getLine

This is how “line noise” glue code looks to me. Except line noise is more
maintainable. *fnord* Note that these glue functions would each require
their own distinct type class instance.

The nicer the client code looks, the more complexity you have to shovel into
the Glue instances. But you are merely transferring complexity — not
creating or destroying it. Complexity is created by data type definitions
being glued. There is the potential for a combinatorial explosion, since you
can have unused Glue instances, whereas you cannot have unused “line noise”
glue code.

Mathematicians don’t care about mathematical symbols. They care about the
things the symbols join, because the semantics of joining “things” is
dependent on — and usually determined by — the things being joined.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110213/0d81709d/attachment.htm>