https://wiki.haskell.org/api.php?action=feedcontributions&user=SeanLeather&feedformat=atomHaskellWiki - User contributions [en]2019-04-25T17:07:30ZUser contributionsMediaWiki 1.27.4https://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60197MonadFail Proposal2015-10-05T10:21:14Z<p>SeanLeather: /* Discussion */ Expand on Monad/Applicative constraint discussion</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* What laws should <code>fail</code> follow?<br />
** '''Left zero''': <code>∀ s f. fail s >>= f ≡ fail s</code>.<br />
** '''Right zero''': <code>∀ v s. v >> fail s ≡ fail s</code>.<br />
* What is the relationship to <code>MonadPlus</code>?<br />
** As the laws above indicate, <code>fail</code> is a close relative of <code>mzero</code>. We could suggest a default definition of <code>fail _ = mzero</code>, which shows the intended usage and effect of the <code>MonadFail</code> class.<br />
** However, we should not remove <code>fail</code> and use only <code>mzero</code> instead. <br />
*** Not all types with <code>Monad</code> instances have <code>MonadPlus</code> instances.<br />
*** Some types do use the <code>String</code> argument to <code>fail</code>. For example, a parser might fail with a message involving positional information. <code>Binary</code> uses <code>fail</code> as their only interface to fail a decoding step.<br />
*** Some types have different definitions for <code>mzero</code> and <code>fail</code>. Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code>. It should therefore not get a <code>MonadFail</code> instance.<br />
* Rename <code>fail</code>?<br />
** '''No.''' Old code might use <code>fail</code> explicitly and we should avoid breaking it. The Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument?<br />
** '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching?<br />
** '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* Do we need a class constraint (e.g. <code>Monad</code>) on <code>MonadFail</code>?<br />
** '''Yes.''' The intended use of <code>fail</code> is for desugaring <code>do</code>-notation, not generally for any <code>String -> m a</code> function. Given that goal, we would rather keep the constraints simple as <code>MonadFail m =></code> rather than the somewhat redundant <code>(Monad m, MonadFail m) =></code>.<br />
* Can we relax the class constraint from <code>Monad</code> to <code>Applicative</code>?<br />
** We don't necessarily have to choose now. Since <code>Applicative</code> is a superclass of <code>Monad</code>, it is possible to change the superclass for <code>MonadFail</code> to <code>Applicative</code> later. This will naturally require a migration period, and the name will, of course, become misleading.<br />
** For the sake of discussion, let's use the following definition:<syntaxhighlight lang="haskell">class Applicative f => ApplicativeFail f where fail :: String -> f a</syntaxhighlight><br />
** '''Pros'''<br />
*** <code>ApplicativeDo</code> is coming, and <code>fail</code> may be useful to combine pattern matching and <code>Applicative</code> code.<br />
*** If the <code>Monad</code> constraint is kept, that would force <code>Applicative</code> code with pattern matching to be <code>Monad</code> code.<br />
** '''Cons'''<br />
*** The constraints for <code>Monad</code> code using <code>fail</code> become <code>(Monad m, ApplicativeFail m) =></code> instead of the simpler <code>MonadFail m =></code>. If we expect the common use of <code>fail</code> to be in <code>Monad</code> — not <code>Applicative</code> — <code>do</code>-notation, this leaves us with more verbose constraints.<br />
** Here are alternative definitions (with names open to debate) that would allow us to keep the constraints simple:<br />
*** <syntaxhighlight lang="haskell">class Applicative f => ApplicativeFail f where failA :: String -> f a</syntaxhighlight><br />
*** <syntaxhighlight lang="haskell">class ApplicativeFail m => MonadFail m where fail :: String -> m a; fail = failA</syntaxhighlight><br />
*** Since we do not have much experience using <code>ApplicativeDo</code>, it is not yet clear that this large of a change is useful.<br />
* Which types with <code>Monad</code> instances will not have <code>MonadFail</code> instances?<br />
** <code>base</code>: <code>Either</code><br />
** <code>transformers</code>:<br />
** <code>stm</code>: <code>STM</code><br />
* What <code>MonadFail</code> instances will be created?<br />
** <code>base</code>: <code>IO</code><br />
** <code>transformers</code>:<br />
*** Proposal for an <code>Either</code> instance using <code>Monad</code> instance in <code>Control.Monad.Trans.Error</code>:<syntaxhighlight lang="haskell">instance MonadFail (Either String) where fail = Left </syntaxhighlight><br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60196MonadFail Proposal2015-10-05T09:40:07Z<p>SeanLeather: /* Discussion */ Minor additions</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* What laws should <code>fail</code> follow?<br />
** '''Left zero''': <code>∀ s f. fail s >>= f ≡ fail s</code>.<br />
** '''Right zero''': <code>∀ v s. v >> fail s ≡ fail s</code>.<br />
* What is the relationship to <code>MonadPlus</code>?<br />
** As the laws above indicate, <code>fail</code> is a close relative of <code>mzero</code>. We could suggest a default definition of <code>fail _ = mzero</code>, which shows the intended usage and effect of the <code>MonadFail</code> class.<br />
** However, we should not remove <code>fail</code> and use only <code>mzero</code> instead. <br />
*** Not all types with <code>Monad</code> instances have <code>MonadPlus</code> instances.<br />
*** Some types do use the <code>String</code> argument to <code>fail</code>. For example, a parser might fail with a message involving positional information. <code>Binary</code> uses <code>fail</code> as their only interface to fail a decoding step.<br />
*** Some types have different definitions for <code>mzero</code> and <code>fail</code>. Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code>. It should therefore not get a <code>MonadFail</code> instance.<br />
<br />
* Rename <code>fail</code>?<br />
** '''No.''' Old code might use <code>fail</code> explicitly and we should avoid breaking it. The Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument?<br />
** '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching?<br />
** '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* The <code>Monad</code> constraint for <code>MonadFail</code> seems unnecessary. Should we drop or relax it? What other things should be considered?<br />
** Applicative <code>do</code> notation is coming sooner or later, <code>fail</code> might be useful in this more general scenario. Due to the AMP, it is trivial to change the <code>MonadFail</code> superclass to <code>Applicative</code> later. (The name will be a bit misleading, but it's a very small price to pay.)<br />
** The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the <code>Monad</code> superclass for three main reasons:<br />
*** We don't want to see <code>(Monad m, MonadFail m) =></code> all over the place.<br />
*** The primary intended use of <code>fail</code> is for desugaring do-notation anyway.<br />
*** Retroactively removing superclasses is easy, but adding them is hard (see AMP).<br />
* Which types with <code>Monad</code> instances will not have <code>MonadFail</code> instances?<br />
** <code>base</code>: <code>Either</code><br />
** <code>transformers</code>:<br />
** <code>stm</code>: <code>STM</code><br />
* What <code>MonadFail</code> instances will be created?<br />
** <code>base</code>: <code>IO</code><br />
** <code>transformers</code>:<br />
*** Proposal for an <code>Either</code> instance using <code>Monad</code> instance in <code>Control.Monad.Trans.Error</code>:<syntaxhighlight lang="haskell">instance MonadFail (Either String) where fail = Left </syntaxhighlight><br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60195MonadFail Proposal2015-10-05T09:31:38Z<p>SeanLeather: /* Discussion */ Fill out laws and MonadPlus section</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* What laws should <code>fail</code> follow?<br />
** '''Left zero''': <code>∀ s f. fail s >>= f ≡ fail s</code>.<br />
** '''Right zero''': <code>∀ v s. v >> fail s ≡ fail s</code>.<br />
* What is the relationship to <code>MonadPlus</code>?<br />
** As the laws above indicate, <code>fail</code> is a close relative of <code>mzero</code>. We could suggest a default definition of <code>fail _ = mzero</code>, which shows the intended usage and effect of the <code>MonadFail</code> class.<br />
** However, we should not remove <code>fail</code> and use only <code>mzero</code> instead. <br />
*** Not all types with <code>Monad</code> instances have <code>MonadPlus</code> instances.<br />
*** Some types do use the <code>String</code> argument to <code>fail</code>. For example, a parser might fail with a message involving positional information. <code>Binary</code> uses <code>fail</code> as their only interface to fail a decoding step.<br />
*** Some types have different definitions for <code>mzero</code> and <code>fail</code>. Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code>. It should therefore not get a <code>MonadFail</code> instance.<br />
<br />
* Rename <code>fail</code>?<br />
** '''No.''' Old code might use <code>fail</code> explicitly and we should avoid breaking it. The Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument?<br />
** '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching?<br />
** '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* The <code>Monad</code> constraint for <code>MonadFail</code> seems unnecessary. Should we drop or relax it? What other things should be considered?<br />
** Applicative <code>do</code> notation is coming sooner or later, <code>fail</code> might be useful in this more general scenario. Due to the AMP, it is trivial to change the <code>MonadFail</code> superclass to <code>Applicative</code> later. (The name will be a bit misleading, but it's a very small price to pay.)<br />
** The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the <code>Monad</code> superclass for three main reasons:<br />
*** We don't want to see <code>(Monad m, MonadFail m) =></code> all over the place.<br />
*** The primary intended use of <code>fail</code> is for desugaring do-notation anyway.<br />
*** Retroactively removing superclasses is easy, but adding them is hard (see AMP).<br />
* Which types with <code>Monad</code> instances will not have <code>MonadFail</code> instances?<br />
* What <code>MonadFail</code> instances will be created?<br />
** <code>base</code>:<br />
** <code>transformers</code>:<br />
*** Proposal for an <code>Either</code> instance using <code>Monad</code> instance in <code>Control.Monad.Trans.Error</code>:<syntaxhighlight lang="haskell">instance MonadFail (Either String) where fail = Left </syntaxhighlight><br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60194MonadFail Proposal2015-10-05T09:11:50Z<p>SeanLeather: /* Discussion */ More on Monad and MonadFail instances</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* Although for many <code>MonadPlus</code> <code>fail _ = mzero</code> a separate <code>MonadFail</code> class should be created instead of just using that.<br />
** A parser might fail with an error message involving positional information. Some libraries, like <code>Binary</code> provide <code>fail</code> as their only interface to fail a decoding step.<br />
** Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code> It will therefore not get a <code>MonadFail</code> instance.<br />
* What laws should <code>fail</code> follow?<br />
** '''Left zero''': <code lang="haskell"> ∀ s f. fail s >>= f ≡ fail s</code>. A call to <code>fail</code> should abort the computation. In this sense, <code>fail</code> would become a close relative of <code>mzero</code> It would work well with the common definition <code>fail _ = mzero</code> and give a simple guideline to the intended usage and effect of the <code>MonadFail</code> class.<br />
* Rename <code>fail</code>?<br />
** '''No.''' Old code might use <code>fail</code> explicitly and we might avoid breaking it, the Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument?<br />
** '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching?<br />
** '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* The <code>Monad</code> constraint for <code>MonadFail</code> seems unnecessary. Should we drop or relax it? What other things should be considered?<br />
** Applicative <code>do</code> notation is coming sooner or later, <code>fail</code> might be useful in this more general scenario. Due to the AMP, it is trivial to change the <code>MonadFail</code> superclass to <code>Applicative</code> later. (The name will be a bit misleading, but it's a very small price to pay.)<br />
** The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the <code>Monad</code> superclass for three main reasons:<br />
*** We don't want to see <code>(Monad m, MonadFail m) =></code> all over the place.<br />
*** The primary intended use of <code>fail</code> is for desugaring do-notation anyway.<br />
*** Retroactively removing superclasses is easy, but adding them is hard (see AMP).<br />
* Which types with <code>Monad</code> instances will not have <code>MonadFail</code> instances?<br />
* What <code>MonadFail</code> instances will be created?<br />
** <code>base</code>:<br />
** <code>transformers</code>:<br />
*** Proposal for an <code>Either</code> instance using <code>Monad</code> instance in <code>Control.Monad.Trans.Error</code>:<syntaxhighlight lang="haskell">instance MonadFail (Either String) where fail = Left </syntaxhighlight><br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60193MonadFail Proposal2015-10-05T09:04:40Z<p>SeanLeather: /* Discussion */ Add discussion point on new MonadFail instances plus Either proposal</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* Although for many <code>MonadPlus</code> <code>fail _ = mzero</code> a separate <code>MonadFail</code> class should be created instead of just using that.<br />
** A parser might fail with an error message involving positional information. Some libraries, like <code>Binary</code> provide <code>fail</code> as their only interface to fail a decoding step.<br />
** Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code> It will therefore not get a <code>MonadFail</code> instance.<br />
* What laws should <code>fail</code> follow?<br />
** '''Left zero''': <code lang="haskell"> ∀ s f. fail s >>= f ≡ fail s</code>. A call to <code>fail</code> should abort the computation. In this sense, <code>fail</code> would become a close relative of <code>mzero</code> It would work well with the common definition <code>fail _ = mzero</code> and give a simple guideline to the intended usage and effect of the <code>MonadFail</code> class.<br />
* Rename <code>fail</code>?<br />
** '''No.''' Old code might use <code>fail</code> explicitly and we might avoid breaking it, the Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument?<br />
** '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching?<br />
** '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* The <code>Monad</code> constraint for <code>MonadFail</code> seems unnecessary. Should we drop or relax it? What other things should be considered?<br />
** Applicative <code>do</code> notation is coming sooner or later, <code>fail</code> might be useful in this more general scenario. Due to the AMP, it is trivial to change the <code>MonadFail</code> superclass to <code>Applicative</code> later. (The name will be a bit misleading, but it's a very small price to pay.)<br />
** The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the <code>Monad</code> superclass for three main reasons:<br />
*** We don't want to see <code>(Monad m, MonadFail m) =></code> all over the place.<br />
*** The primary intended use of <code>fail</code> is for desugaring do-notation anyway.<br />
*** Retroactively removing superclasses is easy, but adding them is hard (see AMP).<br />
* What are the new <code>MonadFail</code> instances?<br />
** Proposal for new <code>Either</code> instance in <code>transformers</code> using <code>Monad</code> instance currently in <code>Control.Monad.Trans.Error</code>:<syntaxhighlight lang="haskell">instance MonadFail (Either String) where fail = Left </syntaxhighlight><br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60192MonadFail Proposal2015-10-05T08:55:12Z<p>SeanLeather: /* Discussion */ Put answers in new bullets for easier reading</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* Although for many <code>MonadPlus</code> <code>fail _ = mzero</code> a separate <code>MonadFail</code> class should be created instead of just using that.<br />
** A parser might fail with an error message involving positional information. Some libraries, like <code>Binary</code> provide <code>fail</code> as their only interface to fail a decoding step.<br />
** Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code> It will therefore not get a <code>MonadFail</code> instance.<br />
* What laws should <code>fail</code> follow?<br />
** '''Left zero''': <code lang="haskell"> ∀ s f. fail s >>= f ≡ fail s</code>. A call to <code>fail</code> should abort the computation. In this sense, <code>fail</code> would become a close relative of <code>mzero</code> It would work well with the common definition <code>fail _ = mzero</code> and give a simple guideline to the intended usage and effect of the <code>MonadFail</code> class.<br />
* Rename <code>fail</code>?<br />
** '''No.''' Old code might use <code>fail</code> explicitly and we might avoid breaking it, the Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument?<br />
** '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching?<br />
** '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* The <code>Monad</code> constraint for <code>MonadFail</code> seems unnecessary. Should we drop or relax it? What other things should be considered?<br />
** Applicative <code>do</code> notation is coming sooner or later, <code>fail</code> might be useful in this more general scenario. Due to the AMP, it is trivial to change the <code>MonadFail</code> superclass to <code>Applicative</code> later. (The name will be a bit misleading, but it's a very small price to pay.)<br />
** The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the <code>Monad</code> superclass for three main reasons:<br />
*** We don't want to see <code>(Monad m, MonadFail m) =></code> all over the place.<br />
*** The primary intended use of <code>fail</code> is for desugaring do-notation anyway.<br />
*** Retroactively removing superclasses is easy, but adding them is hard (see AMP).<br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60191MonadFail Proposal2015-10-05T08:53:49Z<p>SeanLeather: /* Discussion */ Clean up Left zero style</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* Although for many <code>MonadPlus</code> <code>fail _ = mzero</code> a separate <code>MonadFail</code> class should be created instead of just using that.<br />
** A parser might fail with an error message involving positional information. Some libraries, like <code>Binary</code> provide <code>fail</code> as their only interface to fail a decoding step.<br />
** Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code> It will therefore not get a <code>MonadFail</code> instance.<br />
* What laws should <code>fail</code> follow?<br />
** '''Left zero''': <code lang="haskell"> ∀ s f. fail s >>= f ≡ fail s</code>. A call to <code>fail</code> should abort the computation. In this sense, <code>fail</code> would become a close relative of <code>mzero</code> It would work well with the common definition <code>fail _ = mzero</code> and give a simple guideline to the intended usage and effect of the <code>MonadFail</code> class.<br />
* Rename <code>fail</code> '''No.''' Old code might use <code>fail</code> explicitly and we might avoid breaking it, the Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument? '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching? '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* The <code>Monad</code> constraint for <code>MonadFail</code> seems unnecessary. Should we drop or relax it? What other things should be considered?<br />
** Applicative <code>do</code> notation is coming sooner or later, <code>fail</code> might be useful in this more general scenario. Due to the AMP, it is trivial to change the <code>MonadFail</code> superclass to <code>Applicative</code> later. (The name will be a bit misleading, but it's a very small price to pay.)<br />
** The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the <code>Monad</code> superclass for three main reasons:<br />
*** We don't want to see <code>(Monad m, MonadFail m) =></code> all over the place.<br />
*** The primary intended use of <code>fail</code> is for desugaring do-notation anyway.<br />
*** Retroactively removing superclasses is easy, but adding them is hard (see AMP).<br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60190MonadFail Proposal2015-10-05T08:50:46Z<p>SeanLeather: /* Discussion */ Indent bullets more</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* Although for many <code>MonadPlus</code> <code>fail _ = mzero</code> a separate <code>MonadFail</code> class should be created instead of just using that.<br />
** A parser might fail with an error message involving positional information. Some libraries, like <code>Binary</code> provide <code>fail</code> as their only interface to fail a decoding step.<br />
** Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code> It will therefore not get a <code>MonadFail</code> instance.<br />
* What laws should <code>fail</code> follow? '''Left zero''', <syntaxhighlight lang="haskell"> ∀ s f. fail s >>= f ≡ fail s</syntaxhighlight> A call to <code>fail</code> should abort the computation. In this sense, <code>fail</code> would become a close relative of <code>mzero</code> It would work well with the common definition <code>fail _ = mzero</code> and give a simple guideline to the intended usage and effect of the <code>MonadFail</code> class.<br />
* Rename <code>fail</code> '''No.''' Old code might use <code>fail</code> explicitly and we might avoid breaking it, the Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument? '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching? '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* The <code>Monad</code> constraint for <code>MonadFail</code> seems unnecessary. Should we drop or relax it? What other things should be considered?<br />
** Applicative <code>do</code> notation is coming sooner or later, <code>fail</code> might be useful in this more general scenario. Due to the AMP, it is trivial to change the <code>MonadFail</code> superclass to <code>Applicative</code> later. (The name will be a bit misleading, but it's a very small price to pay.)<br />
** The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the <code>Monad</code> superclass for three main reasons:<br />
*** We don't want to see <code>(Monad m, MonadFail m) =></code> all over the place.<br />
*** The primary intended use of <code>fail</code> is for desugaring do-notation anyway.<br />
*** Retroactively removing superclasses is easy, but adding them is hard (see AMP).<br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=MonadFail_Proposal&diff=60189MonadFail Proposal2015-10-05T08:47:58Z<p>SeanLeather: /* The problem */ Add Either</p>
<hr />
<div>== <code>MonadFail</code> proposal (MFP) ==<br />
<br />
A couple of years ago, we proposed to make <code>Applicative</code> a superclass of <code>Monad</code> which successfully killed the single most ugly thing in Haskell as of GHC 7.10.<br />
<br />
Now, it's time to tackle the other major issue with <code>Monad</code> <code>fail</code> being a part of it.<br />
<br />
You can contact me as usual via IRC/Freenode as ''quchen'', or by email to ''dluposchainsky at the email service of Google''. This file was posted on the ghc-devs@ and [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24910 libraries@ mailing lists], as well as on [http://www.reddit.com/r/haskell/comments/397k1a/monadfail_proposal_mfp_moving_fail_out_of_monad/ Reddit].<br />
<br />
This proposal was first posted on [https://github.com/quchen/articles/blob/master/monad_fail.md quchen's articles Github repo].<br />
<br />
=== Overview ===<br />
<br />
* '''The problem''' - reason for the proposal<br />
* '''MonadFail class''' - the solution<br />
* '''Discussion''' - explaining our design choices<br />
* '''Adapting old code''' - how to prepare current code to transition smoothly<br />
* '''Estimating the breakage''' - how much stuff we will break<br />
* '''Transitional strategy''' - how to break as little as possible while transitioning<br />
* '''Current status'''<br />
<br />
=== The problem ===<br />
<br />
Currently, the <code><-</code> symbol is unconditionally desugared as follows:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do pat <- computation >>> let f pat = more<br />
more >>> f _ = fail "..."<br />
>>> in computation >>= f<br />
</syntaxhighlight><br />
<br />
The problem with this is that <code>fail</code> cannot (!) be sensibly implemented for many monads, for example <code>Either</code>, <code>State</code>, <code>IO</code>, and <code>Reader</code>. In those cases it defaults to <code>error</code> As a consequence, in current Haskell, you can not use <code>Monad</code> polymorphic code safely, because although it claims to work for all <code>Monad</code> , it might just crash on you. This kind of implicit non-totality baked into the class is ''terrible''.<br />
<br />
The goal of this proposal is adding the <code>fail</code> only when necessary and reflecting that in the type signature of the <code>do</code> block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so.<br />
<br />
=== <code>MonadFail</code> class ===<br />
<br />
To fix this, introduce a new typeclass:<br />
<br />
<syntaxhighlight lang="haskell"><br />
class Monad m => MonadFail m where<br />
fail :: String -> m a<br />
</syntaxhighlight><br />
<br />
Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the <code>fail</code> call.<br />
<br />
The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally,<br />
<br />
<syntaxhighlight lang="haskell"><br />
do x <- action >>> let f x = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde:<br />
<br />
<syntaxhighlight lang="haskell"><br />
do ~pat <- action >>> let f ~pat = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A class of patterns that are conditionally failable are <code>newtype</code> , and single constructor <code>data</code> types, which are unfailable by themselves, but may fail if matching on their fields is done with failable patterns.<br />
<br />
<syntaxhighlight lang="haskell"><br />
data Newtype a = Newtype a<br />
<br />
-- "x" cannot fail<br />
do Newtype x <- action >>> let f (Newtype x) = more<br />
more >>> in action >>= f<br />
<br />
-- "Just x" can fail<br />
do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
<code>ViewPatterns</code> are as failable as the pattern the view is matched against. Patterns like <code>(Just -> Just x)</code> should generate a <code>MonadFail</code> constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do (view -> pat) <- action >>> let f (view -> pat) = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
<br />
do (view -> ~pat) <- action >>> let f (view -> ~pat) = more<br />
more >>> in action >>= f<br />
</syntaxhighlight><br />
<br />
A similar issue arises for <code>PatternSynonyms</code> which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable.<br />
<br />
<syntaxhighlight lang="haskell"><br />
do PatternSynonym x <- action >>> let f PatternSynonym x = more<br />
more >>> f _ = fail "..."<br />
>>> in action >>= f<br />
</syntaxhighlight><br />
<br />
=== Discussion ===<br />
<br />
* Although for many <code>MonadPlus</code> <code>fail _ = mzero</code> a separate <code>MonadFail</code> class should be created instead of just using that.<br />
** A parser might fail with an error message involving positional information. Some libraries, like <code>Binary</code> provide <code>fail</code> as their only interface to fail a decoding step.<br />
** Although <code>STM</code> is <code>MonadPlus</code> it uses the default <code>fail = error</code> It will therefore not get a <code>MonadFail</code> instance.<br />
* What laws should <code>fail</code> follow? '''Left zero''', <syntaxhighlight lang="haskell"> ∀ s f. fail s >>= f ≡ fail s</syntaxhighlight> A call to <code>fail</code> should abort the computation. In this sense, <code>fail</code> would become a close relative of <code>mzero</code> It would work well with the common definition <code>fail _ = mzero</code> and give a simple guideline to the intended usage and effect of the <code>MonadFail</code> class.<br />
* Rename <code>fail</code> '''No.''' Old code might use <code>fail</code> explicitly and we might avoid breaking it, the Report talks about <code>fail</code> and we have a solid migration strategy that does not require a renaming.<br />
* Remove the <code>String</code> argument? '''No.''' The <code>String</code> might help error reporting and debugging. <code>String</code> may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with <code>fail</code> so this breaking change would in no way be justified. Also note that explicit <code>fail</code> calls would break if we removed the argument.<br />
* How sensitive would existing code be to subtle changes in the strictness behaviour of <code>do</code> notation pattern matching? '''It doesn't.''' The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using <code>~</code> as that ''does'' affect strictness. (Cf. difference between lazy/strict State)<br />
* The <code>Monad</code> constraint for <code>MonadFail</code> seems unnecessary. Should we drop or relax it? What other things should be considered?<br />
** Applicative <code>do</code> notation is coming sooner or later, <code>fail</code> might be useful in this more general scenario. Due to the AMP, it is trivial to change the <code>MonadFail</code> superclass to <code>Applicative</code> later. (The name will be a bit misleading, but it's a very small price to pay.)<br />
** The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the <code>Monad</code> superclass for three main reasons:<br />
** We don't want to see <code>(Monad m, MonadFail m) =></code> all over the place.<br />
** The primary intended use of <code>fail</code> is for desugaring do-notation anyway.<br />
** Retroactively removing superclasses is easy, but adding them is hard (see AMP).<br />
<br />
=== Adapting old code ===<br />
<br />
<ul><br />
<li>Help! My code is broken because of a missing <code>MonadFail</code> instance! ''Here are your options:''<br />
<ol><li>Write a <code>MonadFail</code> instance (and bring it into scope)<br />
<syntaxhighlight lang="haskell"><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Control.Monad.Fail import will become redundant in GHC 7.16+<br />
import qualified Control.Monad.Fail as Fail<br />
#endif<br />
import Control.Monad<br />
<br />
instance Monad Foo where<br />
(>>=) = <...bind impl...><br />
-- NB: <code>return</code> defaults to <code>pure</code><br />
#if !MIN_VERSION_base(4,11,0)<br />
-- Monad(fail) will be removed in GHC 7.16+<br />
fail = Fail.fail<br />
#endif<br />
<br />
instance MonadFail Foo where<br />
fail = <...fail implementation...><br />
</syntaxhighlight></li><br />
<li>Change your pattern to be irrefutable</li><br />
<li>Emulate the old behaviour by desugaring the pattern match by hand:<br />
<syntaxhighlight lang="haskell"><br />
do Left e <- foobar<br />
stuff<br />
</syntaxhighlight> becomes <syntaxhighlight lang="haskell"><br />
do x <- foobar<br />
e <- case x of<br />
Left e' -> e'<br />
Right r -> error "Pattern match failed" -- Boooo<br />
stuff<br />
</syntaxhighlight><br />
The point is you'll have to do your dirty laundry yourself now if you have a value that ''you'' know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you.</li><br />
</ol></li><br />
<li>Help! My code is broken because you removed <code>fail</code> from <code>Monad</code> but my class defines it! ''Delete that part of the instance definition.''</li></ul><br />
<br />
=== Esimating the breakage ===<br />
<br />
Using our initial implementation, I compiled stackage-nightly, and grepped the logs for the warnings. Assuming my implementation is correct, the number of "missing <code>MonadFail</code> warnings generated is 487. Note that I filtered out <code>[]</code> <code>Maybe</code> and <code>ReadPrec</code> since those can be given a <code>MonadFail</code> instance from within GHC, and no breakage is expected from them.<br />
The build logs can be found [https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 here]. Search for "failable pattern" to find your way to the still pretty raw warnings.<br />
<br />
Here are some commands you might find interesting for exploring the logs:<br />
<br />
<syntaxhighlight lang="bash"><br />
# List all packages generating warnings (57 of them)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^(.'')\.log.''$#\1#' | \<br />
uniq -u<br />
<br />
# Histogram of the breaking contexts (mostly IO and parsers)<br />
grep "is used in the context" '' | \<br />
grep -v '(‘\[|Maybe|ReadPrec)' | \<br />
perl -pe 's#^.''in the context ‘([^ ]+).''$#\1#' | \<br />
sort | \<br />
uniq -c | \<br />
sort -rg<br />
</syntaxhighlight><br />
<br />
=== Transitional strategy ===<br />
<br />
The roadmap is similar to the [https://github.com/quchen/articles/blob/master/applicative_monad.md AMP], the main difference being that since <code>MonadFail</code> does not exist yet, we have to introduce new functionality and then switch to it.<br />
<br />
<ol><br />
<li>GHC 8.0 / base-4.9<br />
<ul><br />
<li>Add module <code>Control.Monad.Fail</code> with new class <code>MonadFail(fail)</code> so people can start writing instances for it. <code>Control.Monad</code> only re-exports the class <code>MonadFail</code> but not its <code>fail</code> method. NB: At this point, <code>Control.Monad.Fail.fail</code> clashes with <code>Prelude.fail</code> and <code>Control.Monad.fail</code>.</li><br />
<li>Add a language extension <code>-XMonadFailDesugaring</code> that changes desugaring to use <code>MonadFail(fail)</code> instead of <code>Monad(fail)</code> This has the effect that typechecking will infer a <code>MonadFail</code> constraint for <code>do</code> blocks with failable patterns, just as it is planned to do when the entire thing is done.</li><br />
<li>Warn when a <code>do</code> block that contains a failable pattern is desugared, but there is no <code>MonadFail</code> instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears.</li><br />
<li>Warn when an instance implements the <code>fail</code> function (or when <code>fail</code> is imported as a method of <code>Monad</code> , as it will be removed from the <code>Monad</code> class in the future. (See also [https://ghc.haskell.org/trac/ghc/ticket/10071 GHC #10071])</li><br />
</ul><br />
</li><br />
<li>GHC 8.2<br />
<ul><br />
<li>Switch <code>-XMonadFailDesugaring</code> on by default.</li><br />
<li>Warnings are still issued if the desugaring extension has been explicitly disabled.</li><br />
</ul><br />
</li><br />
<li>GHC 8.4<br />
<ul><br />
<li>Remove <code>-XMonadFail</code> leaving its effects on at all times.</li><br />
<li>Remove <code>fail</code> from <code>Monad</code></li><br />
<li>Instead, re-export <code>Control.Monad.Fail.fail</code> as <code>Prelude.fail</code> and <code>Control.Monad.fail</code></li><br />
<li><code>Control.Monad.Fail</code> is now a redundant module that can be considered deprecated.</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
=== Current status ===<br />
<br />
* [https://wiki.haskell.org/ZuriHac2015 ZuriHac 2015 (29.5. - 31.5.)]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC.<br />
** Desugaring to the new <code>fail</code> can be controlled via a new language extension, <code>MonadFailDesugaring</code><br />
** If the language extension is turned off, a warning will be emitted for code that would break if it was enabled.<br />
** Warnings are emitted for types that ''have'' a ''MonadFail'' instance. This still needs to be fixed.<br />
** The error messages are readable, but should be more so. We're still on this.<br />
* 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.<br />
* 2015-06-09 (late): Published. People seem to like the idea, with a couple of pain points remaining.<br />
* 2015-06-16: [https://github.com/quchen/articles/blob/master/monad_fail_update1.md Update 1 posted.]<br />
* 2015-09-18: [https://phabricator.haskell.org/D1248 Patch nearly finished. Some nontrivial tests still fail.]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=GHC.Generics&diff=54273GHC.Generics2012-10-10T17:55:29Z<p>SeanLeather: Fix link</p>
<hr />
<div>GHC 7.2 includes improved support for ''datatype-generic programming'' through two new features, enabled with two new flags: <tt>DeriveGeneric</tt> and <tt>DefaultSignatures</tt>. We show how this all works in this page, starting with a detailed example.<br />
<br />
Since this is a fresh new feature, it is possible that you will run into bugs when using it. If so, please<br />
[http://hackage.haskell.org/trac/ghc/wiki/ReportABug report them]!<br />
<br />
== Example: serialization ==<br />
<br />
Suppose you are writing a class for serialization of data. You have a type <hask>Bit</hask> representing bits, and a class <hask>Serialize</hask>:<br />
<br />
<haskell><br />
data Bit = O | I<br />
<br />
class Serialize a where<br />
put :: a -> [Bit]<br />
</haskell><br />
<br />
You might have written some instances already:<br />
<br />
<haskell><br />
instance Serialize Int where<br />
put i = serializeInt i<br />
<br />
instance Serialize a => Serialize [a] where<br />
put [] = []<br />
put (h:t) = put h ++ put t<br />
</haskell><br />
<br />
A user of your library, however, will have his own datatypes, like:<br />
<br />
<haskell><br />
data UserTree a = Node a (UserTree a) (UserTree a) | Leaf<br />
</haskell><br />
<br />
He will have to specify an <hask>instance Serialize (UserTree a) where ...</hask> himself. This, however, is tedious, especially because most instances will probably be rather trivial, and should be derived automatically.<br />
<br />
It is here that generic programming can help you. If you are familiar with [http://www.cs.uu.nl/wiki/bin/view/GenericProgramming/SYB SYB] you could use it at this stage, but now we'll see how to do this with the new features of GHC 7.2.<br />
<br />
=== Generic serialization ===<br />
<br />
First you have to tell the compiler how to serialize any datatype, in general. Since Haskell datatypes have a regular structure, this means you can just explain how to serialize a few basic datatypes.<br />
<br />
==== Representation types ====<br />
<br />
We can represent most Haskell datatypes using only the following primitive types:<br />
<br />
<haskell><br />
-- | Unit: used for constructors without arguments<br />
data U1 p = U1<br />
<br />
-- | Constants, additional parameters and recursion of kind *<br />
newtype K1 i c p = K1 { unK1 :: c }<br />
<br />
-- | Meta-information (constructor names, etc.)<br />
newtype M1 i c f p = M1 { unM1 :: f p }<br />
<br />
-- | Sums: encode choice between constructors<br />
infixr 5 :+:<br />
data (:+:) f g p = L1 (f p) | R1 (g p)<br />
<br />
-- | Products: encode multiple arguments to constructors<br />
infixr 6 :*:<br />
data (:*:) f g p = f p :*: g p<br />
</haskell><br />
<br />
For starters, try to ignore the <tt>p</tt> parameter in all types; it's there just for future compatibility. The easiest way to understand how you can use these types to represent others is to see an example. Let's represent the <hask>UserTree</hask> type shown before:<br />
<br />
<haskell><br />
type RepUserTree a =<br />
-- A UserTree is either a Leaf, which has no arguments<br />
U1<br />
-- ... or it is a Node, which has three arguments that we put in a product<br />
:+: a :*: UserTree a :*: UserTree a<br />
</haskell><br />
<br />
Simple, right? Different constructors become alternatives of a sum, and multiple arguments become products. In fact, we want to have some more information in the representation, like datatype and constructor names, and to know if a product argument is a parameter or a type. We use the other primitives for this, and the representation looks more like:<br />
<br />
<haskell><br />
type RealRepUserTree a =<br />
-- Information about the datatype<br />
M1 D Data_UserTree (<br />
-- Leaf, with information about the constructor<br />
M1 C Con_Leaf U1<br />
-- Node, with information about the constructor<br />
:+: M1 C Con_Node (<br />
-- Constructor argument, which could have information<br />
-- about a record selector label<br />
M1 S NoSelector (<br />
-- Argument, tagged with P because it is a parameter<br />
K1 P a)<br />
-- Another argument, tagged with R because it is <br />
-- a recursive occurrence of a type<br />
:*: M1 S NoSelector (K1 R (UserTree a))<br />
-- Idem<br />
:*: M1 S NoSelector (K1 R (UserTree a))<br />
))<br />
</haskell><br />
<br />
A bit more complicated, but essentially the same. Datatypes like <hask>Data_UserTree</hask> are empty datatypes used only for providing meta-information in the representation; you don't have to worry much about them for now. Also, GHC generates these representations for you automatically, so you should never have to define them yourself! All of this is explained in much more detail in Section 2.1. of [http://dreixel.net/research/pdf/gdmh.pdf the original paper describing the new generic deriving mechanism].<br />
<br />
==== A generic function ====<br />
<br />
Since GHC can represent user types using only those primitive types, all you have to do is to tell GHC how to serialize each of the individual primitive types. The best way to do that is to create a new type class:<br />
<br />
<haskell><br />
class GSerialize f where<br />
gput :: f a -> [Bin]<br />
</haskell><br />
<br />
This class looks very much like the original <hask>Serialize</hask> class, just that the type argument is of kind <hask>* -> *</hask>, since our generic representation types have this <tt>p</tt> parameter lying around. Now we need to give instances for each of the basic types. For units there's nothing to serialize:<br />
<br />
<haskell><br />
instance GSerialize U1 where<br />
gput U1 = []<br />
</haskell><br />
<br />
The serialization of multiple arguments is simply the concatenation of each of the individual serializations:<br />
<br />
<haskell><br />
instance (GSerialize a, GSerialize b) => GSerialize (a :*: b) where<br />
gput (a :*: b) = gput a ++ gput b<br />
</haskell><br />
<br />
The case for sums is the most interesting, as we have to record which alternative we are in. We will use a 0 for left injections and a 1 for right injections:<br />
<br />
<haskell><br />
instance (GSerialize a, GSerialize b) => GSerialize (a :+: b) where<br />
gput (L1 x) = O : gput x<br />
gput (R1 x) = I : gput x<br />
</haskell><br />
<br />
We don't need to encode the meta-information, so we just go over it recursively :<br />
<br />
<haskell><br />
instance (GSerialize a) => GSerialize (M1 i c a) where<br />
gput (M1 x) = gput x<br />
</haskell><br />
<br />
Finally, we're only left with the arguments. For these we will just use our first class, <hask>Serialize</hask>, again:<br />
<br />
<haskell><br />
instance (Serialize a) => GSerialize (K1 i a) where<br />
gput (K1 x) = put x<br />
</haskell><br />
<br />
So, if a user datatype has a parameter which is instantiated to <hask>Int</hask>, at this stage we will use the library instance for <hask>Serialize Int</hask>.<br />
<br />
==== Default implementations ====<br />
<br />
We've seen how to represent user types generically, and how to define functions on representation types. However, we still have to tie these two together, explaining how to convert user types to their representation and then applying the generic function.<br />
<br />
The representation <hask>RepUserTree</hask> we have seen earlier is only one component of the representation; we also need functions to convert to and from the user datatype into the representation. For that we use another type class:<br />
<br />
<haskell><br />
class Generic a where<br />
-- Encode the representation of a user datatype<br />
type Rep a :: * -> *<br />
-- Convert from the datatype to its representation<br />
from :: a -> (Rep a) x<br />
-- Convert from the representation to the datatype<br />
to :: (Rep a) x -> a<br />
</haskell><br />
<br />
So, for the <hask>UserTree</hask> datatype shown before, GHC generates the following instance:<br />
<br />
<haskell><br />
instance Generic (UserTree a) where<br />
type Rep (UserTree a) = RepUserTree a<br />
<br />
from Leaf = L1 U1<br />
from (Node a l r) = R1 (a :*: l :*: r)<br />
<br />
to (L1 U1) = Leaf<br />
to (R1 (a :*: l :*: r)) = Node a l r<br />
</haskell><br />
<br />
(Note that we are using the simpler representation <hask>RepUserTree</hask> instead of the real representation <hask>RealRepUserTree</hask>, just for simplicity.)<br />
<br />
Equipped with a <hask>Generic</hask> instance, we are ready to tell the compiler how it can serialize any representable type:<br />
<br />
<haskell><br />
putDefault :: (Generic a, GSerialize (Rep a)) => a -> [Bit]<br />
putDefault a = gput (from a)<br />
</haskell><br />
<br />
The type of <hask>putDefault</hask> says that we can serialize any <tt>a</tt> into a list of bits, as long as that <tt>a</tt> is <hask>Generic</hask>, and its representation <hask>Rep a</hask> has a <hask>GSerialize</hask> instance. The implementation is very simple: first convert the value to its representation using <hask>from</hask>, and then call <hask>gput</hask> on that representation.<br />
<br />
However, we still have to write a <hask>Serialize</hask> instance for the user dataype:<br />
<br />
<haskell><br />
instance (Serialize a) => Serialize (UserTree a) where<br />
put = putDefault<br />
</haskell><br />
<br />
=== Using GHC's new features ===<br />
<br />
What we have seen so far could all already be done, at the cost of writing a lot of boilerplate code yourself (or spending hours writing [[Template Haskell]] code to do it for you). Now we'll see how the new features of GHC can help you.<br />
<br />
==== Deriving representations ====<br />
<br />
The <hask>Generic</hask> class, and all the representation types, come with GHC in the <tt>GHC.Generics</tt> module. GHC can also derive <hask>Generic</hask> for user types, so all the user has to do is:<br />
<br />
<haskell><br />
{-# LANGUAGE DeriveGeneric #-}<br />
<br />
data UserTree a = Node a (UserTree a) (UserTree a) | Leaf<br />
deriving Generic<br />
</haskell><br />
<br />
(Standlone deriving also works fine, and you can use it for types you have not defined yourself, but are imported from somewhere else.) You will need the new <tt>DeriveGeneric</tt> language pragma.<br />
<br />
==== More general default methods ====<br />
<br />
We don't want the user to have to write the <hask>instance Serialize (UserTree a)</hask> himself, since most of the times it will just be <hask>putDefault</hask>. However, we cannot make <hask>putDefault</hask> the default implementation of the <hask>put</hask> method, because that would require adding the <hask>(Generic a, GSerialize (Rep a))</hask> constraint to the class head. This would restrict the ability to give ad-hoc instances for types that are not representable, for instance.<br />
<br />
We solved this by allowing the user to give a different signature for default methods:<br />
<br />
<haskell><br />
{-# LANGUAGE DefaultSignatures #-}<br />
<br />
class Serialize a where<br />
put :: a -> [Bit]<br />
<br />
default put :: (Generic a, GSerialize (Rep a)) => a -> [Bit]<br />
put a = gput (from a)<br />
</haskell><br />
<br />
With the new language pragma <tt>DefaultSignatures</tt>, GHC allows you to put the keyword <hask>default</hask> before a (new) type signature for a method inside a class declaration. If you give such a default type signature, then you have to provide a default method implementation, which will be type-checked using the default signature, and not the original one.<br />
<br />
Now the user can simply write:<br />
<br />
<haskell><br />
instance (Serialize a) => Serialize (UserTree a)<br />
</haskell><br />
<br />
GHC fills out the implementation for <hask>put</hask> using the default method. It will type-check correctly because we have a <hask>Generic</hask> instance for <hask>UserTree</hask>, and <hask>GSerialize</hask> instances for all the representation types.<br />
<br />
== Different perspectives ==<br />
<br />
We outline the changes introduced in 7.2 regarding support for generic programming from the perspective of three different types of users: the end-user, the generic programmer, and the GHC hacker.<br />
<br />
=== The end-user ===<br />
<br />
If you know nothing about generic programming and would like to keep it that way, then you will be pleased to know that using generics in GHC 7.2 is easier than ever. As soon as you encounter a class with a default signature (like <tt>Serialize</tt> above), you will be able to give empty instances for your datatypes, like this:<br />
<br />
<haskell><br />
instance (Serialize a) => Serialize (UserTree a)<br />
</haskell><br />
<br />
You will need to add a <hask>deriving Generic</hask> clause to each datatype that you want to have generic implementations for. You might have datatypes that use other datatypes, and you might need <tt>Generic</tt> instances for those too. In that case, you can import the module where the datatype is defined and give a standalone deriving <tt>Generic</tt> instance. In either case, you will need the <tt>-XDeriveGeneric</tt> flag.<br />
<br />
=== The generic programmer ===<br />
<br />
If you are a library author and are eager to make your classes easy to instantiate by your users, then you should invest some time in defining instances for each of the representation types of <tt>GHC.Generics</tt> and defining a generic default method. See the example for <tt>Serialize</tt> above, and the [http://dreixel.net/research/pdf/gdmh.pdf original paper] for many other examples (but make sure to check the [[#Changes from the paper|changes from the paper]]).<br />
<br />
=== The GHC hacker ===<br />
<br />
If you are working on the GHC source code, you might find it useful to know what kind of changes were made. There is a [http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving Trac wiki page] with a lower-level overview of things and also keeping track of what still needs to be done.<br />
<br />
== Changes from the paper ==<br />
<br />
In the [http://dreixel.net/research/pdf/gdmh.pdf paper] we describe the implementation in [http://www.cs.uu.nl/wiki/UHC UHC]. The implementation in GHC is slightly different:<br />
<br />
* <tt>Representable0</tt> and <tt>Representable1</tt> have become <tt>Generic</tt> and <tt>Generic1</tt>, respectively. <tt>from0</tt>, <tt>to0</tt>, and <tt>Rep0</tt> also lost the <tt>0</tt> at the end of their names.<br />
<br />
* We are using type families, so the <tt>Generic</tt> and <tt>Generic1</tt> type classes have only one type argument. So, in GHC the classes look like what we describe in the "Avoiding extensions" part of Section 2.3 of the paper. This change affects only a generic function writer, and not a generic function user.<br />
<br />
* Default definitions (Section 3.3) work differently. In GHC we don't use a <tt>DERIVABLE</tt> pragma; instead, a type class can declare a ''generic default method'', which is akin to a standard default method, but includes a default type signature. This removes the need for a separate default definition and a pragma. For example, the <tt>Encode</tt> class of Section 3.1 is now:<br />
<haskell><br />
class Encode a where<br />
encode :: a -> [Bit]<br />
default encode :: (Generic a, Encode1 (Rep a)) => a -> [Bit]<br />
encode = encode1 . from<br />
</haskell><br />
<br />
* To derive generic functionality to a user type, the user no longer uses <hask>deriving instance</hask> (Section 4.6.1). Instead, the user gives an instance without defining the method; GHC then uses the generic default. For instance:<br />
<haskell><br />
instance Encode [a] -- works if there is an instance Generic [a]<br />
</haskell><br />
<br />
== Limitations ==<br />
<br />
* We do not yet allow <hask>deriving Generic1</hask> clauses. This means that functions like <tt>fmap</tt> cannot be easily expressed generically in GHC yet.<br />
<br />
* We cannot derive <tt>Generic</tt> instances for:<br />
** Datatypes with a context;<br />
** Existentially-quantified datatypes;<br />
** GADTs.<br />
<br />
<br />
[[Category:GHC]]<br />
[[Category:Language extensions]]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=Template:Dutch_HUG/Upcoming&diff=49795Template:Dutch HUG/Upcoming2012-08-20T21:30:22Z<p>SeanLeather: Fix &#235;</p>
<hr />
<div>* '''August 29''' - Meeting at 19:00 in the Utrecht University library ([https://groups.google.com/d/topic/dutch-hug/3YJ8-embZ0k/discussion details]):<br />
** Jurri&#235;n Stutterheim - Building JavaScript Applications with Haskell<br />
** Sebastiaan Visser - Functional Programming at [http://www.silkapp.com/ Silk]<br />
<br />
<small>For a preliminary schedule of meetings, see the [http://www.google.com/calendar/embed?src=sv7tbnq0qon2sb1k2abb80i66k%40group.calendar.google.com&ctz=Europe/Amsterdam Google calendar] or subscribe to the [http://www.google.com/calendar/ical/sv7tbnq0qon2sb1k2abb80i66k%40group.calendar.google.com/public/basic.ics iCal version].</small></div>SeanLeatherhttps://wiki.haskell.org/index.php?title=Template:Dutch_HUG/Upcoming&diff=49794Template:Dutch HUG/Upcoming2012-08-20T21:29:22Z<p>SeanLeather: Add next meeting</p>
<hr />
<div>* '''August 29''' - Meeting at 19:00 in the Utrecht University library ([https://groups.google.com/d/topic/dutch-hug/3YJ8-embZ0k/discussion details]):<br />
** Jurriën Stutterheim - Building JavaScript Applications with Haskell<br />
** Sebastiaan Visser - Functional Programming at [http://www.silkapp.com/ Silk]<br />
<br />
<small>For a preliminary schedule of meetings, see the [http://www.google.com/calendar/embed?src=sv7tbnq0qon2sb1k2abb80i66k%40group.calendar.google.com&ctz=Europe/Amsterdam Google calendar] or subscribe to the [http://www.google.com/calendar/ical/sv7tbnq0qon2sb1k2abb80i66k%40group.calendar.google.com/public/basic.ics iCal version].</small></div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45544DHD UHac/Links2012-05-01T21:05:42Z<p>SeanLeather: /* Announcements */ Bram Neijt's email</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* Tom Lokhorst<br />
** [https://twitter.com/#!/tomlokhorst/statuses/193268629284995072 Pascal Hof speaking].<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Dutch-HUG-Day-Apr-20/22545333_Rg2Ddr DHD on Friday]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/UHac-Apr-22/22626801_PKSpFb UHac on Sunday]<br />
* [http://www.flickr.com/photos/spockz/sets/72157629872187931/ Alessandro Vermeulen]<br />
** [http://www.flickr.com/photos/spockz/6955427522/in/set-72157629872187931 DHD]<br />
<br />
Original photos from Alessandro are available upon request in print and digitally.<br />
<br />
== Announcements ==<br />
<br />
* Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
* Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
* Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
* José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
* Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].<br />
* Andres Löh migrated the [https://github.com/haskell/cabal cabal repository] to GitHub.<br />
* Jasper Van der Jeugt found a place for his [https://plus.google.com/113933723670373082880/posts/abcpx1H6Hpd Haskell sticker].<br />
* Erik Hesselink released [http://hackage.haskell.org/package/bumper bumper], a tool for bumping package versions transitively, on behalf of [http://www.silkapp.com Silk].<br />
* Bram Neijt [http://www.haskell.org/pipermail/haskell-cafe/2012-May/101018.html writes] about [https://gist.github.com/bneijt/hs2dot hs2dot] and [https://gist.github.com/bneijt/dotimate dotimate].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45431DHD UHac/Links2012-04-25T10:37:06Z<p>SeanLeather: /* Photos */ Add my UHac photos</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* Tom Lokhorst<br />
** [https://twitter.com/#!/tomlokhorst/statuses/193268629284995072 Pascal Hof speaking].<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Dutch-HUG-Day-Apr-20/22545333_Rg2Ddr DHD on Friday]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/UHac-Apr-22/22626801_PKSpFb UHac on Sunday]<br />
* [http://www.flickr.com/photos/spockz/sets/72157629872187931/ Alessandro Vermeulen]<br />
** [http://www.flickr.com/photos/spockz/6955427522/in/set-72157629872187931 DHD]<br />
<br />
Original photos from Alessandro are available upon request in print and digitally.<br />
<br />
== Announcements ==<br />
<br />
* Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
* Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
* Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
* José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
* Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].<br />
* Andres Löh migrated the [https://github.com/haskell/cabal cabal repository] to GitHub.<br />
* Jasper Van der Jeugt found a place for his [https://plus.google.com/113933723670373082880/posts/abcpx1H6Hpd Haskell sticker].<br />
* Erik Hesselink released [http://hackage.haskell.org/package/bumper bumper], a tool for bumping package versions transitively, on behalf of [http://www.silkapp.com Silk].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45430DHD UHac/DHD Program2012-04-25T09:45:01Z<p>SeanLeather: Add Pascal's links</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| [[#homepage|How I Generate My Homepage]]<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (UGent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
* [http://jaspervdj.be/files/2012-dutchhug-websockets.pdf Slides]<br />
* [http://jaspervdj.be/websockets/ websockets] home page<br />
* [http://hackage.haskell.org/package/websockets websockets] on Hackage<br />
* [https://github.com/jaspervdj/websockets websockets] on GitHub<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/erik-hesselink-ecosystem.pdf Slides]<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/pascal-hof-model-checking.pdf Slides]<br />
* [https://github.com/pascalh/modelchecking modelchecking] on GitHub<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://prezi.com/-acujvowpciq/dotfs Slides] on prezi.com<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
* [http://www.cs.uu.nl/wiki/pub/Hage/ResearchTalks/holmes-slides.pdf Slides] <br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage ([http://www.oblomov.com Oblomov Systems])<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
* [http://www.oblomov.com/Documents/AmpersandJoosten-DHD2012.pdf Slides Stef]<br />
* [http://www.oblomov.com/Documents/Ampersand101-DHD2012.pdf Slides Martijn]<br />
* [http://ampersand.sourceforge.net Ampersand] on Sourceforge<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
* [http://hackage.haskell.org/package/fclabels fclabels] on Hackage<br />
* [https://github.com/sebastiaanvisser/fclabels fclabels] on GitHub<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].<br />
<br />
* [http://ro-che.info/docs/2012-04-20-applicative-regexps.pdf Slides]<br />
* [http://hackage.haskell.org/package/regex-applicative regex-applicative] on Hackage<br />
* [https://github.com/feuerbach/regex-applicative regex-applicative] on GitHub<br />
<br />
=== <span id="homepage">How I Generate My Homepage</span> ===<br />
<br />
Wouter Swierstra (UU)<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/wouter-swierstra-homepage.pdf Slides]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45415DHD UHac/DHD Program2012-04-24T10:43:00Z<p>SeanLeather: Add Erik's slides</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| [[#homepage|How I Generate My Homepage]]<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (UGent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
* [http://jaspervdj.be/files/2012-dutchhug-websockets.pdf Slides]<br />
* [http://jaspervdj.be/websockets/ websockets] home page<br />
* [http://hackage.haskell.org/package/websockets websockets] on Hackage<br />
* [https://github.com/jaspervdj/websockets websockets] on GitHub<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/erik-hesselink-ecosystem.pdf Slides]<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://prezi.com/-acujvowpciq/dotfs Slides] on prezi.com<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
* [http://hackage.haskell.org/package/fclabels fclabels] on Hackage<br />
* [https://github.com/sebastiaanvisser/fclabels fclabels] on GitHub<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].<br />
<br />
* [http://hackage.haskell.org/package/regex-applicative regex-applicative] on Hackage<br />
<br />
=== <span id="homepage">How I Generate My Homepage</span> ===<br />
<br />
Wouter Swierstra (UU)<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/wouter-swierstra-homepage.pdf Slides]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45414DHD UHac/DHD Program2012-04-24T10:16:36Z<p>SeanLeather: </p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| [[#homepage|How I Generate My Homepage]]<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (UGent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
* [http://jaspervdj.be/websockets/ websockets] home page<br />
* [http://hackage.haskell.org/package/websockets websockets] on Hackage<br />
* [https://github.com/jaspervdj/websockets websockets] on GitHub<br />
* [http://jaspervdj.be/files/2012-dutchhug-websockets.pdf slides] of the talk<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
* [http://prezi.com/-acujvowpciq/dotfs slides] on prezi.com<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
* [http://hackage.haskell.org/package/fclabels fclabels] on Hackage<br />
* [https://github.com/sebastiaanvisser/fclabels fclabels] on GitHub<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].<br />
<br />
* [http://hackage.haskell.org/package/regex-applicative regex-applicative] on Hackage<br />
<br />
=== <span id="homepage">How I Generate My Homepage</span> ===<br />
<br />
Wouter Swierstra (UU)<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/wouter-swierstra-homepage.pdf Slides]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45412DHD UHac/DHD Program2012-04-24T10:06:21Z<p>SeanLeather: Add Wouter's slides</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| [[#homepage|How I Generate My Homepage]]<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
* [http://jaspervdj.be/websockets/ websockets] home page<br />
* [http://hackage.haskell.org/package/websockets websockets] on Hackage<br />
* [https://github.com/jaspervdj/websockets websockets] on GitHub<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
* [http://prezi.com/-acujvowpciq/dotfs slides] on prezi.com<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
* [http://hackage.haskell.org/package/fclabels fclabels] on Hackage<br />
* [https://github.com/sebastiaanvisser/fclabels fclabels] on GitHub<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].<br />
<br />
* [http://hackage.haskell.org/package/regex-applicative regex-applicative] on Hackage<br />
<br />
=== <span id="homepage">How I Generate My Homepage</span> ===<br />
<br />
Wouter Swierstra (UU)<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/wouter-swierstra-homepage.pdf Slides]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=File:DHD-wouter.pdf&diff=45411File:DHD-wouter.pdf2012-04-24T09:57:26Z<p>SeanLeather: Wouter Swierstra's slides from his DHD talk.</p>
<hr />
<div>Wouter Swierstra's slides from his DHD talk.</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45406DHD UHac/DHD Program2012-04-24T09:26:57Z<p>SeanLeather: /* Applicative Regular Expressions */ Hackage</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
* [http://jaspervdj.be/websockets/ websockets] home page<br />
* [http://hackage.haskell.org/package/websockets websockets] on Hackage<br />
* [https://github.com/jaspervdj/websockets websockets] on GitHub<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
* [http://hackage.haskell.org/package/fclabels fclabels] on Hackage<br />
* [https://github.com/sebastiaanvisser/fclabels fclabels] on GitHub<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].<br />
<br />
* [http://hackage.haskell.org/package/regex-applicative regex-applicative] on Hackage</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45405DHD UHac/DHD Program2012-04-24T09:25:50Z<p>SeanLeather: /* Supporting Different Versions of the WebSockets Protocol */ links</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
* [http://jaspervdj.be/websockets/ websockets] home page<br />
* [http://hackage.haskell.org/package/websockets websockets] on Hackage<br />
* [https://github.com/jaspervdj/websockets websockets] on GitHub<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
* [http://hackage.haskell.org/package/fclabels fclabels] on Hackage<br />
* [https://github.com/sebastiaanvisser/fclabels fclabels] on GitHub<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45404DHD UHac/DHD Program2012-04-24T09:23:46Z<p>SeanLeather: /* fclabels: First Class Record Labels for Haskell */ Hackage and GitHub</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
* [http://hackage.haskell.org/package/fclabels fclabels] on Hackage<br />
* [https://github.com/sebastiaanvisser/fclabels fclabels] on GitHub<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45403DHD UHac/DHD Program2012-04-24T09:22:38Z<p>SeanLeather: /* Building Your Own Haskell ecosystem */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45402DHD UHac/DHD Program2012-04-24T09:22:23Z<p>SeanLeather: /* Building Your Own Haskell ecosystem */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45401DHD UHac/DHD Program2012-04-24T09:21:53Z<p>SeanLeather: /* DotFS - or How Fred Solved His Config Clutter */ Hackage</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper package] ([https://github.com/silkapp/bumper on GitHub])<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45400DHD UHac/DHD Program2012-04-24T09:20:48Z<p>SeanLeather: /* DotFS - or How Fred Solved His Config Clutter */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper package] ([https://github.com/silkapp/bumper on GitHub])<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [https://github.com/toothbrush/dotfs DotFS] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45399DHD UHac/DHD Program2012-04-24T09:20:24Z<p>SeanLeather: /* Snap and Gruze */ Gruze-Store</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper package] ([https://github.com/silkapp/bumper on GitHub])<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [https://github.com/toothbrush/dotfs On GitHub]<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45398DHD UHac/DHD Program2012-04-24T09:18:31Z<p>SeanLeather: /* Building Your Own Haskell ecosystem */ bumper</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [http://hackage.haskell.org/package/bumper bumper package] ([https://github.com/silkapp/bumper on GitHub])<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [https://github.com/toothbrush/dotfs On GitHub]<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45396DHD UHac/DHD Program2012-04-24T09:05:22Z<p>SeanLeather: /* GHC 7.6, More Well-Typed Than Ever */ Slides</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [https://github.com/toothbrush/dotfs On GitHub]<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45395DHD UHac/DHD Program2012-04-24T09:04:12Z<p>SeanLeather: /* DotFS - or How Fred Solved His Config Clutter */ GitHub link</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [https://github.com/toothbrush/dotfs On GitHub]<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45385DHD UHac/Links2012-04-23T17:39:54Z<p>SeanLeather: /* Announcements */ Cabal announcement</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* Tom Lokhorst<br />
** [https://twitter.com/#!/tomlokhorst/statuses/193268629284995072 Pascal Hof speaking].<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
* [http://www.flickr.com/photos/spockz/sets/72157629872187931/ Alessandro Vermeulen]<br />
** [http://www.flickr.com/photos/spockz/6955427522/in/set-72157629872187931 DHD]<br />
<br />
Original photos from Alessandro are available upon request in print and digitally.<br />
<br />
== Announcements ==<br />
<br />
* Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
* Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
* Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
* José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
* Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].<br />
* Andres Löh migrated the [https://github.com/haskell/cabal cabal repository] to GitHub.<br />
* Jasper Van der Jeugt found a place for his [https://plus.google.com/113933723670373082880/posts/abcpx1H6Hpd Haskell sticker].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45384DHD UHac/Links2012-04-23T17:34:23Z<p>SeanLeather: /* Announcements */ Sticker announcement</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* Tom Lokhorst<br />
** [https://twitter.com/#!/tomlokhorst/statuses/193268629284995072 Pascal Hof speaking].<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
* [http://www.flickr.com/photos/spockz/sets/72157629872187931/ Alessandro Vermeulen]<br />
** [http://www.flickr.com/photos/spockz/6955427522/in/set-72157629872187931 DHD]<br />
<br />
Original photos from Alessandro are available upon request in print and digitally.<br />
<br />
== Announcements ==<br />
<br />
* Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
* Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
* Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
* José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
* Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].<br />
* Jasper Van der Jeugt found a place for his [https://plus.google.com/113933723670373082880/posts/abcpx1H6Hpd Haskell sticker].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45382DHD UHac/Links2012-04-23T16:41:44Z<p>SeanLeather: /* Announcements */ Chrono is not needed, generalize from Social Networks</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* Tom Lokhorst<br />
** [https://twitter.com/#!/tomlokhorst/statuses/193268629284995072 Pascal Hof speaking].<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
* [http://www.flickr.com/photos/spockz/sets/72157629872187931/ Alessandro Vermeulen]<br />
** [http://www.flickr.com/photos/spockz/6955427522/in/set-72157629872187931 DHD]<br />
<br />
Original photos from Alessandro are available upon request in print and digitally.<br />
<br />
== Announcements ==<br />
<br />
* Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
* Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
* Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
* José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
* Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45380DHD UHac/Links2012-04-23T12:35:24Z<p>SeanLeather: /* Photos */ Add Tom's photo of Pascal</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* Tom Lokhorst<br />
** [https://twitter.com/#!/tomlokhorst/statuses/193268629284995072 Pascal Hof speaking].<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
* [http://www.flickr.com/photos/spockz/sets/72157629872187931/ Alessandro Vermeulen]<br />
** [http://www.flickr.com/photos/spockz/6955427522/in/set-72157629872187931 DHD]<br />
<br />
Original photos from Alessandro are available upon request in print and digitally.<br />
<br />
== Social Networks ==<br />
<br />
Ordered chronologically.<br />
<br />
# Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
# Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
# Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
# José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
# Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45379DHD UHac/Links2012-04-23T12:32:22Z<p>SeanLeather: /* Google+ */ Renive]</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
* [http://www.flickr.com/photos/spockz/sets/72157629872187931/ Alessandro Vermeulen]<br />
** [http://www.flickr.com/photos/spockz/6955427522/in/set-72157629872187931 DHD]<br />
<br />
Original photos from Alessandro are available upon request in print and digitally.<br />
<br />
== Social Networks ==<br />
<br />
Ordered chronologically.<br />
<br />
# Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
# Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
# Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
# José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
# Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac&diff=45368DHD UHac2012-04-22T09:55:50Z<p>SeanLeather: Photos moved to DHD_UHac/Links</p>
<hr />
<div>The [http://dutchhug.nl/ Dutch Haskell Users Group] is hosting a combined event for Haskell enthusiasts: an informal mini-conference and a weekend hackathon. It is the '''Dutch HUG Day''' followed by '''Utrecht Hackathon''', or more concisely ...<br />
<br />
<br/><br />
----<br />
<br />
{|<br />
| Event:<br />
| '''DHD >>= UHac'''<br />
|-<br />
| Dates:<br />
| '''April 20 - 22, 2012'''<br />
|-<br />
| Location:<br />
| '''Utrecht, The Netherlands'''<br />
|}<br />
<br />
----<br />
<br/><br />
<br />
'''Quick links: [[DHD_UHac/Local|Local Information]] | [[DHD_UHac/Projects|UHac Project Information]] | [[DHD_UHac/Links|Links]]'''<br />
<br />
----<br />
<br />
== Introduction ==<br />
<br />
The DHD and UHac are two events held over a long weekend and organized by the Dutch HUG.<br />
<br />
'''NOTE:''' Everything regarding the DHD >>= UHac is in English!<br />
<br />
=== Dutch HUG Day ===<br />
<br />
[[Image:Dhug2.png|35px]] The DHD will be on Friday, April 20. We invite people from all backgrounds to speak about their hobby projects, their research, or anything else related to functional programming.<br />
<br />
This will be the second time the Dutch HUG has hosted such an event. The [http://dutchhug.nl/dutchhugday first Dutch HUG Day] was held on April 24, 2010. It was a great success and brought together people from all over the Netherlands, as well as Germany and Belgium.<br />
<br />
We intend to make this year's DHD just as successful and open it to an even wider audience by binding it to a hackathon, which usually attracts people from all over Europe.<br />
<br />
=== Utrecht Hackathon ===<br />
<br />
[[Image:Hac-axe-icon.png|35px]] UHac immediately follows the DHD and lasts from Friday, April 20, to Sunday, April 22. In the now-grand tradition of [[Hackathon|Haskell hackathons]], UHac is an international, grassroots collaborative coding festival with a simple focus: build and improve Haskell libraries, tools, and infrastructure.<br />
<br />
Haskell hackathons have been held every year since at least 2006. Utrecht hosted its first hackathon, [[Hac5]], in 2009, and this is the second.<br />
<br />
=== Dutch Haskell Users Group ===<br />
<br />
The Dutch HUG is an informal group with monthly meetings. Each meeting often includes talks on novel applications of functional programming. Other times, members just gather for drinks at a pub. The group was founded on April 19, 2009, at the end of [[Hac5]]. In April, 2012, the group celebrates its 3rd year of existence.<br />
<br />
== Schedule ==<br />
<br />
We have combined two events in the hopes that people interested in one might also take the opportunity to check out the other. Thus, it's much easier if the events are juxtaposed. In that light, here is a preliminary schedule to help you plan your time here.<br />
<br />
----<br />
{|<br />
! Date<br />
! Time<br />
! Event<br />
|-<br />
| Friday, April 20<br />
| 9:30 - 15:30<br />
| DHD at Ordina ([[DHD_UHac/Local#DHD_at_Ordina|venue]], [[DHD_UHac/DHD_Program|program]])<br />
|-<br />
|<br />
| 16:00 - 20:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|-<br />
| Saturday, April 21<br />
| 9:00 - 19:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|-<br />
| Sunday, April 22<br />
| 9:00 - 19:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|}<br />
----<br />
<br />
<!--<br />
== Registration and Attendees ==<br />
<br />
Registration allows us (the organizers) to determine the number of participants (for logistics such as seating, lunch at the DHD, and rooms for UHac) and gives us a means to contact them. Please [[DHD_UHac/Register|register]]:<br />
<br />
{|<br />
| Registration deadline for the DHD:<br />
| April 1, 2012<br />
|-<br />
| Registration deadline for UHac:<br />
| '''April 19, 2012'''<br />
|}<br />
<br />
In addition to registering, it is often helpful to arrange things (such as accommodation, transportation, etc.) with other participants. Please include some information about yourself in the [[DHD_UHac/Attendees|list of attendees]], so that others may contact you to coordinate.<br />
--><br />
<br />
== Local arrangements ==<br />
<br />
Refer to the [[DHD_UHac/Local|local information page]] for the latest on everything related to the location.<br />
<br />
== DHD ==<br />
<br />
<!--<br />
=== Call for speakers ===<br />
<br />
We are still looking for a few speakers for the Dutch HUG Day. The topic can cover anything in the functional programming or Haskell world. It may be your latest pet project, current research, or simply a demonstration of something novel that you discovered. We are flexible about the time: it can be a lightning talk of 5 minutes, a full talk of 20 minutes, or even a longer hands-on tutorial.<br />
<br />
If you would like to give a talk, please send a title and abstract to Sean Leather ([mailto:leather@cs.uu.nl leather@cs.uu.nl]).<br />
--><br />
<br />
See the [[DHD_UHac/DHD_Program|program]] page for details.<br />
<br />
== UHac ==<br />
<br />
=== Project information ===<br />
<br />
Have plans for a project to work on during UHac? Want to find out about other people's projects? Check out the [[DHD_UHac/Projects|project page]] for details.<br />
<br />
=== Rooms ===<br />
<br />
We have two rooms for UHac, and one of those rooms will support tutorials and presentations (and anything else that requires a projector or group meetings). See the [[DHD_UHac/UHac_Rooms|rooms page]] for more information.<br />
<br />
== Discussion and social ==<br />
<br />
;IRC<br />
<br />
Join the official [irc://irc.freenode.net#uhac #uhac] channel on irc.[http://freenode.net/ freenode.net].<br />
<br />
;Email<br />
<br />
Use the [http://www.haskell.org/mailman/listinfo/hackathon hackathon@haskell.org] mailing list to communicate broadly with other hackathon attendees.<br />
<br />
Join the [https://groups.google.com/group/dutch-hug dutch-hug@googlegroups.com] mailing list to chat with other Haskell hackers in the area of the Netherlands (and even occasionally Belgium and Germany). The Dutch Haskell Users Group meetings are announced on this list. Most communication is in English, since there are a number of foreigners involved.<br />
<br />
;Hash Tags<br />
<br />
On Twitter or Google+, use <code>#dhduhac</code> for all things related to DHD >>= UHac.<br />
<br />
* [https://twitter.com/#!/search/realtime/%23dhduhac Search Twitter]<br />
* [https://plus.google.com/s/%23dhduhac Search Google+]<br />
<br />
== Follow-up ==<br />
<br />
The DHD >>= UHac is now underway. See the current development of [[DHD_UHac/Links|links]] around the web that are relevant.<br />
<br />
== Sponsors ==<br />
<br />
We are extremely grateful to the following sponsors for making the DHD >>= UHac experience very enjoyable.<br />
<br />
=== Ordina ===<br />
<br />
[[Image:OrdinaLogo.gif]]<br />
<br />
[http://www.ordina.com/ Ordina] ([http://www.ordina.nl/ Dutch site]) hosted the DHD and provided lunch to the participants. This is the second time they have hosted the DHD.<br />
<br />
=== Well-Typed ===<br />
<br />
[[Image:WellTypedLogo.png]]<br />
<br />
[http://www.well-typed.com/ Well-Typed, LLP], the Haskell consultants, provided dinner on Friday for the UHac participants.<br />
<br />
== Organizers ==<br />
<br />
The organizers are:<br />
<br />
* Sean Leather ([mailto:leather@cs.uu.nl leather@cs.uu.nl])<br />
* Jurri&euml;n Stutterheim ([mailto:j.stutterheim@uu.nl j.stutterheim@uu.nl])<br />
* Jurriaan Hage<br />
<br />
If you have any questions regarding the event, please feel free to contact us.<br />
<br />
[[Category:Events]]<br />
[[Category:Hackathon]]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45367DHD UHac/Links2012-04-22T09:55:15Z<p>SeanLeather: Add Alessandro's photos</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
* Alessandro Vermeulen<br />
** [http://www.flickr.com/photos/spockz/sets/72157629872187931/ DHD]<br />
<br />
== Social Networks ==<br />
<br />
Ordered chronologically.<br />
<br />
=== Google+ ===<br />
<br />
# Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
# Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
# Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
# José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
# Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45364DHD UHac/Links2012-04-22T07:51:56Z<p>SeanLeather: /* Social Networks */ blaze-html</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
<br />
== Social Networks ==<br />
<br />
Ordered chronologically.<br />
<br />
=== Google+ ===<br />
<br />
# Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
# Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
# Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
# José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.<br />
# Jasper Van der Jeugt [http://jaspervdj.be/posts/2012-04-21-blaze-html-0.5.html released] [http://jaspervdj.be/blaze/ blaze-html-0.5].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45358DHD UHac/Links2012-04-21T12:02:08Z<p>SeanLeather: /* Google+ */ Pedro is generic</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
<br />
== Social Networks ==<br />
<br />
Ordered chronologically.<br />
<br />
=== Google+ ===<br />
<br />
# Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
# Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
# Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).<br />
# José Pedro Magalhães [https://plus.google.com/u/0/104222093009939197511/posts/TYDYRMzfZ2o updated] the [http://www.haskell.org/haskellwiki/Generics Haskell Generics] wiki page.</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=Generics&diff=45357Generics2012-04-21T11:48:58Z<p>SeanLeather: Grammar</p>
<hr />
<div>''Datatype-generic programming'', also frequently just called ''generic programming'' or ''generics'' in Haskell, is a form of abstraction that allows defining functions that can operate on a large class of datatypes. In this page we summarise a number of popular approaches to generic programming that are often used with GHC. For a more in-depth introduction to generic programming in general, have a look at Gibbon's [http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/dgp.pdf Datatype-Generic Programming], or the [http://dreixel.net/research/pdf/lgph.pdf Libraries for Generic Programming] paper.<br />
<br />
== What is generic programming? ==<br />
<br />
Haskell is a polymorphic language. This means that you can have a single datatype for lists:<br />
<haskell><br />
data List a = Nil | Cons a (List a)<br />
</haskell><br />
These lists can contain any type of information, such as integers, Booleans, or even other lists. Since the length of a list does not depend on the type of its elements, there is also a single definition for list length:<br />
<haskell><br />
length :: List a -> Int<br />
length Nil = 0<br />
length (Cons _ t) = 1 + length t<br />
</haskell><br />
<br />
However, it's not only lists that have length. Consider a datatype for trees:<br />
<haskell><br />
data Tree a = Leaf | Bin a (Tree a) (Tree a)<br />
</haskell><br />
You can also compute the length of a tree (or its size, if you want), by recursively traversing the tree and counting the number of elements. Generic programming allows to define a ''single'' length function, that can operate on lists, trees, and many other datatypes. This reduces code duplication and makes the code more robust to changes, because you can change your datatypes without needing to adapt the generic functions that operate on them.<br />
<br />
We now look at some approaches to generic programming in Haskell.<br />
<br />
== GHC.Generics ==<br />
<br />
The <hask>GHC.Generics</hask> module, available with GHC since version 7.2, allows you to easily define classes with methods for which no implementation is necessary, similarly to <hask>Show</hask>, for instance. It's described in a [[GHC.Generics|separate wiki page]].<br />
<br />
== SYB ==<br />
<br />
Scrap Your Boilerplate (SYB), available with GHC since version 6.0, is an earlier approach to generic programming, particularly well suited for traversals and transformations over large trees. It has its own [http://www.cs.uu.nl/wiki/GenericProgramming/SYB wiki page].<br />
<br />
== Uniplate ==<br />
<br />
Uniplate is available as a [http://hackage.haskell.org/package/uniplate library on Hackage]. It is similar in nature to SYB, but uses simpler types. For more information [http://community.haskell.org/~ndm/uniplate/ see its webpage].<br />
<br />
== Multirec ==<br />
<br />
Multirec is a library for generic programming with fixed points, supporting mutually recursive families of datatypes, and allowing functionality such as folds or the zipper. For more information, [http://www.cs.uu.nl/wiki/GenericProgramming/Multirec see its webpage].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45344DHD UHac/Links2012-04-20T22:02:40Z<p>SeanLeather: Add my review</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
<br />
== Social Networks ==<br />
<br />
Ordered chronologically.<br />
<br />
=== Google+ ===<br />
<br />
# Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
# Gregory Collins was [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].<br />
# Sean Leather [https://plus.google.com/104222093009939197511/posts/cPqYsoW2MDT reviewed] the event so far (Friday).</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45343DHD UHac/Links2012-04-20T21:29:32Z<p>SeanLeather: Google+ links</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]<br />
<br />
== Social Networks ==<br />
<br />
Ordered chronologically.<br />
<br />
=== Google+ ===<br />
<br />
# Sean Leather announced his [https://plus.google.com/104222093009939197511/posts/PA82ATB9t7n latex-number-signs].<br />
# Gregory Collins is [https://plus.google.com/117852249512245938101/posts/Jup4smt8Bt7 hanging with the nerds].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac&diff=45342DHD UHac2012-04-20T21:19:57Z<p>SeanLeather: Add Follow-up section and Links</p>
<hr />
<div>The [http://dutchhug.nl/ Dutch Haskell Users Group] is hosting a combined event for Haskell enthusiasts: an informal mini-conference and a weekend hackathon. It is the '''Dutch HUG Day''' followed by '''Utrecht Hackathon''', or more concisely ...<br />
<br />
<br/><br />
----<br />
<br />
{|<br />
| Event:<br />
| '''DHD >>= UHac'''<br />
|-<br />
| Dates:<br />
| '''April 20 - 22, 2012'''<br />
|-<br />
| Location:<br />
| '''Utrecht, The Netherlands'''<br />
|}<br />
<br />
----<br />
<br/><br />
<br />
'''Quick links: [[DHD_UHac/Local|Local Information]] | [[DHD_UHac/Projects|UHac Project Information]] | [[DHD_UHac/Links|Links]]'''<br />
<br />
----<br />
<br />
== Introduction ==<br />
<br />
The DHD and UHac are two events held over a long weekend and organized by the Dutch HUG.<br />
<br />
'''NOTE:''' Everything regarding the DHD >>= UHac is in English!<br />
<br />
=== Dutch HUG Day ===<br />
<br />
[[Image:Dhug2.png|35px]] The DHD will be on Friday, April 20. We invite people from all backgrounds to speak about their hobby projects, their research, or anything else related to functional programming.<br />
<br />
This will be the second time the Dutch HUG has hosted such an event. The [http://dutchhug.nl/dutchhugday first Dutch HUG Day] was held on April 24, 2010. It was a great success and brought together people from all over the Netherlands, as well as Germany and Belgium.<br />
<br />
We intend to make this year's DHD just as successful and open it to an even wider audience by binding it to a hackathon, which usually attracts people from all over Europe.<br />
<br />
=== Utrecht Hackathon ===<br />
<br />
[[Image:Hac-axe-icon.png|35px]] UHac immediately follows the DHD and lasts from Friday, April 20, to Sunday, April 22. In the now-grand tradition of [[Hackathon|Haskell hackathons]], UHac is an international, grassroots collaborative coding festival with a simple focus: build and improve Haskell libraries, tools, and infrastructure.<br />
<br />
Haskell hackathons have been held every year since at least 2006. Utrecht hosted its first hackathon, [[Hac5]], in 2009, and this is the second.<br />
<br />
=== Dutch Haskell Users Group ===<br />
<br />
The Dutch HUG is an informal group with monthly meetings. Each meeting often includes talks on novel applications of functional programming. Other times, members just gather for drinks at a pub. The group was founded on April 19, 2009, at the end of [[Hac5]]. In April, 2012, the group celebrates its 3rd year of existence.<br />
<br />
== Schedule ==<br />
<br />
We have combined two events in the hopes that people interested in one might also take the opportunity to check out the other. Thus, it's much easier if the events are juxtaposed. In that light, here is a preliminary schedule to help you plan your time here.<br />
<br />
----<br />
{|<br />
! Date<br />
! Time<br />
! Event<br />
|-<br />
| Friday, April 20<br />
| 9:30 - 15:30<br />
| DHD at Ordina ([[DHD_UHac/Local#DHD_at_Ordina|venue]], [[DHD_UHac/DHD_Program|program]])<br />
|-<br />
|<br />
| 16:00 - 20:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|-<br />
| Saturday, April 21<br />
| 9:00 - 19:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|-<br />
| Sunday, April 22<br />
| 9:00 - 19:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|}<br />
----<br />
<br />
<!--<br />
== Registration and Attendees ==<br />
<br />
Registration allows us (the organizers) to determine the number of participants (for logistics such as seating, lunch at the DHD, and rooms for UHac) and gives us a means to contact them. Please [[DHD_UHac/Register|register]]:<br />
<br />
{|<br />
| Registration deadline for the DHD:<br />
| April 1, 2012<br />
|-<br />
| Registration deadline for UHac:<br />
| '''April 19, 2012'''<br />
|}<br />
<br />
In addition to registering, it is often helpful to arrange things (such as accommodation, transportation, etc.) with other participants. Please include some information about yourself in the [[DHD_UHac/Attendees|list of attendees]], so that others may contact you to coordinate.<br />
--><br />
<br />
== Local arrangements ==<br />
<br />
Refer to the [[DHD_UHac/Local|local information page]] for the latest on everything related to the location.<br />
<br />
== DHD ==<br />
<br />
<!--<br />
=== Call for speakers ===<br />
<br />
We are still looking for a few speakers for the Dutch HUG Day. The topic can cover anything in the functional programming or Haskell world. It may be your latest pet project, current research, or simply a demonstration of something novel that you discovered. We are flexible about the time: it can be a lightning talk of 5 minutes, a full talk of 20 minutes, or even a longer hands-on tutorial.<br />
<br />
If you would like to give a talk, please send a title and abstract to Sean Leather ([mailto:leather@cs.uu.nl leather@cs.uu.nl]).<br />
--><br />
<br />
See the [[DHD_UHac/DHD_Program|program]] page for details.<br />
<br />
== UHac ==<br />
<br />
=== Project information ===<br />
<br />
Have plans for a project to work on during UHac? Want to find out about other people's projects? Check out the [[DHD_UHac/Projects|project page]] for details.<br />
<br />
=== Rooms ===<br />
<br />
We have two rooms for UHac, and one of those rooms will support tutorials and presentations (and anything else that requires a projector or group meetings). See the [[DHD_UHac/UHac_Rooms|rooms page]] for more information.<br />
<br />
== Discussion and social ==<br />
<br />
;IRC<br />
<br />
Join the official [irc://irc.freenode.net#uhac #uhac] channel on irc.[http://freenode.net/ freenode.net].<br />
<br />
;Email<br />
<br />
Use the [http://www.haskell.org/mailman/listinfo/hackathon hackathon@haskell.org] mailing list to communicate broadly with other hackathon attendees.<br />
<br />
Join the [https://groups.google.com/group/dutch-hug dutch-hug@googlegroups.com] mailing list to chat with other Haskell hackers in the area of the Netherlands (and even occasionally Belgium and Germany). The Dutch Haskell Users Group meetings are announced on this list. Most communication is in English, since there are a number of foreigners involved.<br />
<br />
;Hash Tags<br />
<br />
On Twitter or Google+, use <code>#dhduhac</code> for all things related to DHD >>= UHac.<br />
<br />
* [https://twitter.com/#!/search/realtime/%23dhduhac Search Twitter]<br />
* [https://plus.google.com/s/%23dhduhac Search Google+]<br />
<br />
== Follow-up ==<br />
<br />
The DHD >>= UHac is now underway. See the current development of [[DHD_UHac/Links|links]] around the web that are relevant.<br />
<br />
== Sponsors ==<br />
<br />
We are extremely grateful to the following sponsors for making the DHD >>= UHac experience very enjoyable.<br />
<br />
=== Ordina ===<br />
<br />
[[Image:OrdinaLogo.gif]]<br />
<br />
[http://www.ordina.com/ Ordina] ([http://www.ordina.nl/ Dutch site]) hosted the DHD and provided lunch to the participants. This is the second time they have hosted the DHD.<br />
<br />
=== Well-Typed ===<br />
<br />
[[Image:WellTypedLogo.png]]<br />
<br />
[http://www.well-typed.com/ Well-Typed, LLP], the Haskell consultants, provided dinner on Friday for the UHac participants.<br />
<br />
== Organizers ==<br />
<br />
The organizers are:<br />
<br />
* Sean Leather ([mailto:leather@cs.uu.nl leather@cs.uu.nl])<br />
* Jurri&euml;n Stutterheim ([mailto:j.stutterheim@uu.nl j.stutterheim@uu.nl])<br />
* Jurriaan Hage<br />
<br />
If you have any questions regarding the event, please feel free to contact us.<br />
<br />
[[Category:Events]]<br />
[[Category:Hackathon]]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Links&diff=45341DHD UHac/Links2012-04-20T21:15:48Z<p>SeanLeather: Start page, add my photos</p>
<hr />
<div>Here, we collect various links around the web that are relevant to the DHD >>= UHac.<br />
<br />
== Photos ==<br />
<br />
* [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012 Sean Leather's photos]<br />
** [http://spl.smugmug.com/Dutch-Haskell-Users-Group/DHD-UHac-2012/Friday-Apr-20/22545333_Rg2Ddr Friday]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac&diff=45340DHD UHac2012-04-20T21:05:49Z<p>SeanLeather: Comment out registration, add Well-Typed as sponsor</p>
<hr />
<div>The [http://dutchhug.nl/ Dutch Haskell Users Group] is hosting a combined event for Haskell enthusiasts: an informal mini-conference and a weekend hackathon. It is the '''Dutch HUG Day''' followed by '''Utrecht Hackathon''', or more concisely ...<br />
<br />
<br/><br />
----<br />
<br />
{|<br />
| Event:<br />
| '''DHD >>= UHac'''<br />
|-<br />
| Dates:<br />
| '''April 20 - 22, 2012'''<br />
|-<br />
| Location:<br />
| '''Utrecht, The Netherlands'''<br />
|}<br />
<br />
----<br />
<br/><br />
<br />
'''Quick links:''' [[DHD_UHac/Local|Local Information]]<br />
| [[DHD_UHac/DHD_Program|DHD Program]]<br />
| [[DHD_UHac/Projects|UHac Project Information]]<br />
<br />
----<br />
<br />
== Introduction ==<br />
<br />
The DHD and UHac are two events held over a long weekend and organized by the Dutch HUG.<br />
<br />
'''NOTE:''' Everything regarding the DHD >>= UHac is in English!<br />
<br />
=== Dutch HUG Day ===<br />
<br />
[[Image:Dhug2.png|35px]] The DHD will be on Friday, April 20. We invite people from all backgrounds to speak about their hobby projects, their research, or anything else related to functional programming.<br />
<br />
This will be the second time the Dutch HUG has hosted such an event. The [http://dutchhug.nl/dutchhugday first Dutch HUG Day] was held on April 24, 2010. It was a great success and brought together people from all over the Netherlands, as well as Germany and Belgium.<br />
<br />
We intend to make this year's DHD just as successful and open it to an even wider audience by binding it to a hackathon, which usually attracts people from all over Europe.<br />
<br />
=== Utrecht Hackathon ===<br />
<br />
[[Image:Hac-axe-icon.png|35px]] UHac immediately follows the DHD and lasts from Friday, April 20, to Sunday, April 22. In the now-grand tradition of [[Hackathon|Haskell hackathons]], UHac is an international, grassroots collaborative coding festival with a simple focus: build and improve Haskell libraries, tools, and infrastructure.<br />
<br />
Haskell hackathons have been held every year since at least 2006. Utrecht hosted its first hackathon, [[Hac5]], in 2009, and this is the second.<br />
<br />
=== Dutch Haskell Users Group ===<br />
<br />
The Dutch HUG is an informal group with monthly meetings. Each meeting often includes talks on novel applications of functional programming. Other times, members just gather for drinks at a pub. The group was founded on April 19, 2009, at the end of [[Hac5]]. In April, 2012, the group celebrates its 3rd year of existence.<br />
<br />
== Schedule ==<br />
<br />
We have combined two events in the hopes that people interested in one might also take the opportunity to check out the other. Thus, it's much easier if the events are juxtaposed. In that light, here is a preliminary schedule to help you plan your time here.<br />
<br />
----<br />
{|<br />
! Date<br />
! Time<br />
! Event<br />
|-<br />
| Friday, April 20<br />
| 9:30 - 15:30<br />
| DHD at Ordina ([[DHD_UHac/Local#DHD_at_Ordina|venue]], [[DHD_UHac/DHD_Program|program]])<br />
|-<br />
|<br />
| 16:00 - 20:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|-<br />
| Saturday, April 21<br />
| 9:00 - 19:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|-<br />
| Sunday, April 22<br />
| 9:00 - 19:00<br />
| UHac at Newton ([[DHD_UHac/Local#UHac_at_Newton|venue]])<br />
|}<br />
----<br />
<br />
<!--<br />
== Registration and Attendees ==<br />
<br />
Registration allows us (the organizers) to determine the number of participants (for logistics such as seating, lunch at the DHD, and rooms for UHac) and gives us a means to contact them. Please [[DHD_UHac/Register|register]]:<br />
<br />
{|<br />
| Registration deadline for the DHD:<br />
| April 1, 2012<br />
|-<br />
| Registration deadline for UHac:<br />
| '''April 19, 2012'''<br />
|}<br />
<br />
In addition to registering, it is often helpful to arrange things (such as accommodation, transportation, etc.) with other participants. Please include some information about yourself in the [[DHD_UHac/Attendees|list of attendees]], so that others may contact you to coordinate.<br />
--><br />
<br />
== Local arrangements ==<br />
<br />
Refer to the [[DHD_UHac/Local|local information page]] for the latest on everything related to the location.<br />
<br />
== DHD ==<br />
<br />
<!--<br />
=== Call for speakers ===<br />
<br />
We are still looking for a few speakers for the Dutch HUG Day. The topic can cover anything in the functional programming or Haskell world. It may be your latest pet project, current research, or simply a demonstration of something novel that you discovered. We are flexible about the time: it can be a lightning talk of 5 minutes, a full talk of 20 minutes, or even a longer hands-on tutorial.<br />
<br />
If you would like to give a talk, please send a title and abstract to Sean Leather ([mailto:leather@cs.uu.nl leather@cs.uu.nl]).<br />
--><br />
<br />
See the [[DHD_UHac/DHD_Program|program]] page for details.<br />
<br />
== UHac ==<br />
<br />
=== Project information ===<br />
<br />
Have plans for a project to work on during UHac? Want to find out about other people's projects? Check out the [[DHD_UHac/Projects|project page]] for details.<br />
<br />
=== Rooms ===<br />
<br />
We have two rooms for UHac, and one of those rooms will support tutorials and presentations (and anything else that requires a projector or group meetings). See the [[DHD_UHac/UHac_Rooms|rooms page]] for more information.<br />
<br />
== Discussion and social ==<br />
<br />
;IRC<br />
<br />
Join the official [irc://irc.freenode.net#uhac #uhac] channel on irc.[http://freenode.net/ freenode.net].<br />
<br />
;Email<br />
<br />
Use the [http://www.haskell.org/mailman/listinfo/hackathon hackathon@haskell.org] mailing list to communicate broadly with other hackathon attendees.<br />
<br />
Join the [https://groups.google.com/group/dutch-hug dutch-hug@googlegroups.com] mailing list to chat with other Haskell hackers in the area of the Netherlands (and even occasionally Belgium and Germany). The Dutch Haskell Users Group meetings are announced on this list. Most communication is in English, since there are a number of foreigners involved.<br />
<br />
;Hash Tags<br />
<br />
On Twitter or Google+, use <code>#dhduhac</code> for all things related to DHD >>= UHac.<br />
<br />
* [https://twitter.com/#!/search/realtime/%23dhduhac Search Twitter]<br />
* [https://plus.google.com/s/%23dhduhac Search Google+]<br />
<br />
== Sponsors ==<br />
<br />
We are extremely grateful to the following sponsors for making the DHD >>= UHac experience very enjoyable.<br />
<br />
=== Ordina ===<br />
<br />
[[Image:OrdinaLogo.gif]]<br />
<br />
[http://www.ordina.com/ Ordina] ([http://www.ordina.nl/ Dutch site]) hosted the DHD and provided lunch to the participants. This is the second time they have hosted the DHD.<br />
<br />
=== Well-Typed ===<br />
<br />
[[Image:WellTypedLogo.png]]<br />
<br />
[http://www.well-typed.com/ Well-Typed, LLP], the Haskell consultants, provided dinner on Friday for the UHac participants.<br />
<br />
== Organizers ==<br />
<br />
The organizers are:<br />
<br />
* Sean Leather ([mailto:leather@cs.uu.nl leather@cs.uu.nl])<br />
* Jurri&euml;n Stutterheim ([mailto:j.stutterheim@uu.nl j.stutterheim@uu.nl])<br />
* Jurriaan Hage<br />
<br />
If you have any questions regarding the event, please feel free to contact us.<br />
<br />
[[Category:Events]]<br />
[[Category:Hackathon]]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=File:WellTypedLogo.png&diff=45339File:WellTypedLogo.png2012-04-20T20:58:12Z<p>SeanLeather: The logo for [http://www.well-typed.com/ Well-Typed, LLC].</p>
<hr />
<div>The logo for [http://www.well-typed.com/ Well-Typed, LLC].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45328DHD UHac/DHD Program2012-04-20T05:59:08Z<p>SeanLeather: Final program note.</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45315DHD UHac/DHD Program2012-04-19T12:15:10Z<p>SeanLeather: Caps consistency</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the current program for the Dutch HUG Day. It may still change.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| How I Generate My Homepage<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (Ghent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage (Oblomov Systems)<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Local&diff=45312DHD UHac/Local2012-04-19T11:44:30Z<p>SeanLeather: /* Getting there */ Add rooms</p>
<hr />
<div>This page should contain all the information you need to know to get to Utrecht, get around, and get out. If it doesn't, let us know.<br />
<br />
== Before you arrive! ==<br />
<br />
=== What to bring ===<br />
* A laptop with support for wireless networking. Ethernet access will probably not be available. If you really need ethernet access, please contact the organisers.<br />
* Power adapters if necessary. Power sockets in the Netherlands are 220-240V CEE 7/4 (a.k.a. "[http://en.wikipedia.org/wiki/Schuko Schuko]").<br />
* Mobile phone<br />
* A debit card, credit card and/or enough cash to sleep/eat/drink. Credit cards are generally not accepted in Dutch stores (and even restaurants), so be prepared to pay in some other way.<br />
<br />
=== Get organized ===<br />
<br />
* Pick a project or projects to work at UHac<br />
* Add your project, or add your name to one of the projects on the [[DHD_UHac/Projects|Projects]] page<br />
* Prepare your laptop with the necessary software, including the latest [http://hackage.haskell.org/platform/ Haskell platform] or [http://www.haskell.org/ghc/ GHC]<br />
* Get excited!<br />
<br />
== Maps ==<br />
<br />
; Google Map<br />
<br />
Use '''[http://maps.google.com/maps/ms?msid=211877270309020342121.0004b89c16976b3a082db&msa=0 this map]''' to familiarize yourself with the locations relevant to the event. This includes the venues as well as accommodations and important transportation spots.<br />
<br />
If you can access Google Maps on your mobile phone, you can even view it there. If you need it, the short URL is http://g.co/maps/b6as8.<br />
<br />
; Map of Utrecht<br />
<br />
[http://www.inyourpocket.com/ In Your Pocket] has an [http://www.inyourpocket.com/Netherlands/Utrecht Utrecht City Guide] with useful maps and general sightseeing and tourist information.<br />
<br />
; Map of the Uithof<br />
<br />
[http://plattegrond.uu.nl/print/uithofprintversie2008.pdf This PDF map] shows the Uithof campus of Utrecht University.<br />
<br />
; Map of University College Utrecht<br />
<br />
[http://www.uu.nl/university/college/EN/contactvisiting/PublishingImages/internationalcampusutrecht.jpg This JPEG map] shows the UCU campus.<br />
<br />
== Transportation ==<br />
<br />
In this section, we describe means of transportation without a car. If you do plan on driving to and around Utrecht, we hope you can find your own way, since we don't drive that much ourselves. <br />
<br />
=== Getting to Utrecht ===<br />
<br />
Getting a train is the best (and cheapest) way of getting to Utrecht. Utrecht Central Station is where you need to get off. There are direct connections to Utrecht Central Station from Schiphol Airport and Eindhoven. People arriving at Eindhoven Airport will first need to take a bus to Eindhoven Central Station.<br />
<br />
You can use the [http://www.ns.nl/en/travellers/home NS website] (NS, or Nederlands Spoorwegen, is the Dutch Railways service) or the [http://9292.nl/en/ 9292 journey planner] to plan your trip.<br />
<br />
=== Getting around Utrecht ===<br />
<br />
Getting around Utrecht without a car is very easy. There are two basic methods: bicycling and public transport.<br />
<br />
==== Bicycling ====<br />
<br />
If you want the true Dutch commuting experience coming from abroad, consider renting a bike. The [http://www.laagcatharijne.nl/indexeng.html Fietsenstalling Laag Catharijne] is immediately below the Hoge Catharijne, which is the shopping mall connected to the central station. Follow signs to the Wolff "Bioscoop Catharijne" (a small cinema). Instead of going upstairs to the cinema, go downstairs to the ground floor, step outside and look for the bike shop on your left.<br />
<br />
==== Public Transport ====<br />
<br />
Public transport in Utrecht is very convenient and accessible. You can take a bus pretty much anywhere in the metropolitan area, though there are a few trams. The most useful online resource is the [http://9292.nl/en/ 9292 journey planner] (which also has mobile phone apps).<br />
<br />
This [http://en.wikipedia.org/wiki/Public_transport_in_the_Netherlands Wikipedia page] has general information on the public transport system in the Netherlands. Expatica also has a helpful [http://www.expatica.com/nl/leisure/travel_tourism/guide-to-public-transport-in-the-Netherlands-17782.html guide], including information about the [http://www.expatica.com/nl/essentials_moving_to/essentials/Using-the-new-OV_chipkaart-system_14436.html ticketing system].<br />
<br />
You can buy tickets to buses and trams from the driver. If you plan on spending more time traveling, you can also get day tickets and other things from train stations.<br />
<br />
== Venues ==<br />
<br />
We have one venue for the DHD and one venue for UHac. (We previously had two venues for UHac, but that has since changed.)<br />
<br />
=== DHD at Ordina ===<br />
<br />
Ordina is gratefully sponsoring the DHD with their fine facilities and delicious food (Seriously! We held the first DHD there, and we're happy to go back.)<br />
<br />
==== Address ====<br />
<br />
[http://maps.google.com/maps?q=Ringwade+1,+3439LM+Nieuwegein,+The+Netherlands Ringwade 1, 3439LM Nieuwegein, The Netherlands]<br />
<br />
==== Getting there ====<br />
<br />
There are a number of buses that go near Ordina. To use one of these, we refer you to the [http://9292.nl/en/journeyadvice/station-utrecht-centraal/nieuwegein_ringwade-1 9292 journey planner] (change the date once there). Perhaps the easiest route, however is the tram.<br />
<br />
; By Tram<br />
<br />
From the central station, take the tram (a.k.a. Sneltram or ST) in the direction of "Nieuwegein Zuid" (60) or "IJsselstein-Zuid" (61). Get off at the stop "P+R Westraven" (a.k.a. "Transferium Westraven") The stop before is "Kanaleneiland Zuid."<br />
<br />
; From the P+R Westraven stop<br />
<br />
Walk south (in the same direction as the tram), crossing over the tram tracks and the road &mdash; there is no crosswalk. Continue walking south and then east, following the path to a road that crosses the bridge Liesboschbrug. After walking past a large office building on your left, turn left at Ringwade and walk straight until you see the orange Ordina flags on the left, where you will find the main building's entrance.<br />
<br />
; At Ordina<br />
<br />
Go to the reception desk on the ground floor and tell them you are attending the Dutch HUG Day. They will ask for your name, check it off their list, and tell you where to go.<br />
<br />
<!--<br />
<br />
=== UHac at the BBL ===<br />
<br />
UHac starts out after the DHD in a classroom in the BBL (Buys Ballot Laboratorium) building at the "Uithof" (pronounced similar to "OUT-hof") campus of Utrecht University. Since the organizers are located there, and class is still in session, we don't have to pay a thing.<br />
<br />
==== Address ====<br />
<br />
[http://maps.google.com/maps?q=Princetonplein+5,+3584CC+Utrecht,+The+Netherlands Princetonplein 5, 3584CC Utrecht, The Netherlands]<br />
<br />
==== Getting there ====<br />
<br />
; By car<br />
<br />
Follow [http://www.uu.nl/EN/contactanddirections/deuithofbycar/Pages/default.aspx these directions] to reach the Uithof by car.<br />
<br />
; By bus<br />
<br />
From the central station, take bus 11 or 12. The both go to the Uithof, but they take different routes: bus 11 goes through the city center, and bus 12 stays to the south of the center.<br />
<br />
* With bus 11, take the "Botanische Tuinen" (Botanical Gardens) stop. The stop before is "Wim Sonneveldlaan."<br />
* With bus 12, take the "Padualaan" stop. The stop before is "Rijnsweerd Zuid."<br />
<br />
Once off the bus, walk north (from both stops) to the red building called the "Minnaert" (with its name spelled out in large letters on the facade).<br />
<br />
; Through the Minnaert<br />
<br />
[[Image:Minnaert.jpg|This is the Minnaert building, which is easier to spot. The arrow points to the BBL, immediately behind the Minnaert.]]<br />
<br />
Walk through the Minnaert to the BBL (indicated by the arrow in the photo above). The easiest way to find the path is by following a line of small, circular, metal plates on the walkway to the entrance of the Minnaert. These plates continue inside and lead directly to the BBL. Once you cross a bridge (with a view of bamboo!) into the BBL, simply take the stairs or elevator in the center of the building down to the ground floor and walk to the room.<br />
<br />
--><br />
<br />
=== UHac at Newton ===<br />
<br />
Over the weekend, UHac will be held in classrooms at the Newton building on the University College Utrecht (UCU) campus.<br />
<br />
==== Address ====<br />
<br />
[http://maps.google.com/maps?q=Campusplein+13-14,+3584ED,+Utrecht,+The+Netherlands Campusplein 13-14, 3584ED Utrecht, The Netherlands]<br />
<br />
==== Getting there ====<br />
<br />
; By car<br />
<br />
Follow [http://www.uu.nl/university/college/EN/contactvisiting/Pages/Directions.aspx these directions] to reach UCU by car. '''NOTE:''' Due to construction work, part of Prins Hendriklaan (the road leading to UCU) is currently closed to cars. Getting to the location should still be possible when driving via the Sophocleslaan.<br />
<br />
; By bus<br />
<br />
From the central station, take bus 12 in the direction of "Uithof UMC AZU." Get off at the stop "De Kromme Rijn." The stop before is "Stadion Galgenwaard."<br />
<br />
; From the bus stop<br />
<br />
Walk north/northwest (crossing the street from the bus stop) down Platolaan. The street makes a natural curve to the left and becomes Sophocleslaan and then curves right and becomes Prins Hendriklaan. There you will find the entrance to the UCU campus on your left.<br />
<br />
Walk through the pedestrian gate (and watch for cyclists going in and out). Take the left path walking around the central square. Newton Hall is the first building on the left at the corner of the square.<br />
<br />
; At Newton<br />
<br />
Enter from the south side (farthest from the pedestrian gate). We expect this door to be open during the day. If the door is locked, call Sean Leather or Jurriën Stutterheim (see [[DHD_UHac/Attendees|Attendees]] page for contact information). Our rooms are upstairs: room F all three days and room E on Saturday and Sunday.<br />
<br />
== Accommodation ==<br />
<br />
We have included a number of accommodations on [http://maps.google.com/maps/ms?msid=211877270309020342121.0004b89c16976b3a082db&msa=0 our map]. You might also check out the [http://www.bedandbreakfast.nl/plaats/Utrecht bed and breakfast locations in Utrecht].<br />
<br />
== Eating ==<br />
<br />
=== University College Utrecht ===<br />
<br />
On Saturday and Sunday, the Dining Hall is open for brunch and dinner. All other eating places on campus are closed.<br />
<br />
; Weekend hours<br />
{|<br />
| Brunch:<br />
| 10:30 - 12:30<br />
|-<br />
| Dinner:<br />
| 18:00 - 19:30<br />
|}<br />
<br />
=== Restaurants ===<br />
<br />
These are a few of the restaurants around Utrecht.<br />
<br />
==== Italian ====<br />
* [http://maps.google.nl/maps?q=il+pozzo&hl=nl&fb=1&gl=nl&hq=il+pozzo&hnear=0x47c66f4339d32d37:0xd6c8fc4c19af4ae9,Utrecht&cid=0,0,111793244555536424&t=m&z=16&iwloc=A Il Pozzo]<br />
* [http://www.ristorantelafontana.nl/ La Fontana]<br />
* [http://www.pizzeriatricolore.nl/ Tricolore]<br />
* [http://www.bellaitalia-pizza.nl/ Bella Italia]<br />
<br />
==== Vegetarian ====<br />
* [http://www.dewerfkring.com/?lang=en De Werfkring]<br />
<br />
==== Pancakes ====<br />
* [http://www.theehuisrhijnauwen.nl/theehuis/home.html Theehuis Rhijnauwen]<br />
* [http://www.deoudemuntkelder.nl/ De Oude Muntkelder]</div>SeanLeatherhttps://wiki.haskell.org/index.php?title=DHD_UHac/Local&diff=45310DHD UHac/Local2012-04-19T10:20:38Z<p>SeanLeather: /* Getting around Utrecht */ Updates to public transport</p>
<hr />
<div>This page should contain all the information you need to know to get to Utrecht, get around, and get out. If it doesn't, let us know.<br />
<br />
== Before you arrive! ==<br />
<br />
=== What to bring ===<br />
* A laptop with support for wireless networking. Ethernet access will probably not be available. If you really need ethernet access, please contact the organisers.<br />
* Power adapters if necessary. Power sockets in the Netherlands are 220-240V CEE 7/4 (a.k.a. "[http://en.wikipedia.org/wiki/Schuko Schuko]").<br />
* Mobile phone<br />
* A debit card, credit card and/or enough cash to sleep/eat/drink. Credit cards are generally not accepted in Dutch stores (and even restaurants), so be prepared to pay in some other way.<br />
<br />
=== Get organized ===<br />
<br />
* Pick a project or projects to work at UHac<br />
* Add your project, or add your name to one of the projects on the [[DHD_UHac/Projects|Projects]] page<br />
* Prepare your laptop with the necessary software, including the latest [http://hackage.haskell.org/platform/ Haskell platform] or [http://www.haskell.org/ghc/ GHC]<br />
* Get excited!<br />
<br />
== Maps ==<br />
<br />
; Google Map<br />
<br />
Use '''[http://maps.google.com/maps/ms?msid=211877270309020342121.0004b89c16976b3a082db&msa=0 this map]''' to familiarize yourself with the locations relevant to the event. This includes the venues as well as accommodations and important transportation spots.<br />
<br />
If you can access Google Maps on your mobile phone, you can even view it there. If you need it, the short URL is http://g.co/maps/b6as8.<br />
<br />
; Map of Utrecht<br />
<br />
[http://www.inyourpocket.com/ In Your Pocket] has an [http://www.inyourpocket.com/Netherlands/Utrecht Utrecht City Guide] with useful maps and general sightseeing and tourist information.<br />
<br />
; Map of the Uithof<br />
<br />
[http://plattegrond.uu.nl/print/uithofprintversie2008.pdf This PDF map] shows the Uithof campus of Utrecht University.<br />
<br />
; Map of University College Utrecht<br />
<br />
[http://www.uu.nl/university/college/EN/contactvisiting/PublishingImages/internationalcampusutrecht.jpg This JPEG map] shows the UCU campus.<br />
<br />
== Transportation ==<br />
<br />
In this section, we describe means of transportation without a car. If you do plan on driving to and around Utrecht, we hope you can find your own way, since we don't drive that much ourselves. <br />
<br />
=== Getting to Utrecht ===<br />
<br />
Getting a train is the best (and cheapest) way of getting to Utrecht. Utrecht Central Station is where you need to get off. There are direct connections to Utrecht Central Station from Schiphol Airport and Eindhoven. People arriving at Eindhoven Airport will first need to take a bus to Eindhoven Central Station.<br />
<br />
You can use the [http://www.ns.nl/en/travellers/home NS website] (NS, or Nederlands Spoorwegen, is the Dutch Railways service) or the [http://9292.nl/en/ 9292 journey planner] to plan your trip.<br />
<br />
=== Getting around Utrecht ===<br />
<br />
Getting around Utrecht without a car is very easy. There are two basic methods: bicycling and public transport.<br />
<br />
==== Bicycling ====<br />
<br />
If you want the true Dutch commuting experience coming from abroad, consider renting a bike. The [http://www.laagcatharijne.nl/indexeng.html Fietsenstalling Laag Catharijne] is immediately below the Hoge Catharijne, which is the shopping mall connected to the central station. Follow signs to the Wolff "Bioscoop Catharijne" (a small cinema). Instead of going upstairs to the cinema, go downstairs to the ground floor, step outside and look for the bike shop on your left.<br />
<br />
==== Public Transport ====<br />
<br />
Public transport in Utrecht is very convenient and accessible. You can take a bus pretty much anywhere in the metropolitan area, though there are a few trams. The most useful online resource is the [http://9292.nl/en/ 9292 journey planner] (which also has mobile phone apps).<br />
<br />
This [http://en.wikipedia.org/wiki/Public_transport_in_the_Netherlands Wikipedia page] has general information on the public transport system in the Netherlands. Expatica also has a helpful [http://www.expatica.com/nl/leisure/travel_tourism/guide-to-public-transport-in-the-Netherlands-17782.html guide], including information about the [http://www.expatica.com/nl/essentials_moving_to/essentials/Using-the-new-OV_chipkaart-system_14436.html ticketing system].<br />
<br />
You can buy tickets to buses and trams from the driver. If you plan on spending more time traveling, you can also get day tickets and other things from train stations.<br />
<br />
== Venues ==<br />
<br />
We have one venue for the DHD and one venue for UHac. (We previously had two venues for UHac, but that has since changed.)<br />
<br />
=== DHD at Ordina ===<br />
<br />
Ordina is gratefully sponsoring the DHD with their fine facilities and delicious food (Seriously! We held the first DHD there, and we're happy to go back.)<br />
<br />
==== Address ====<br />
<br />
[http://maps.google.com/maps?q=Ringwade+1,+3439LM+Nieuwegein,+The+Netherlands Ringwade 1, 3439LM Nieuwegein, The Netherlands]<br />
<br />
==== Getting there ====<br />
<br />
There are a number of buses that go near Ordina. To use one of these, we refer you to the [http://9292.nl/en/journeyadvice/station-utrecht-centraal/nieuwegein_ringwade-1 9292 journey planner] (change the date once there). Perhaps the easiest route, however is the tram.<br />
<br />
; By Tram<br />
<br />
From the central station, take the tram (a.k.a. Sneltram or ST) in the direction of "Nieuwegein Zuid" (60) or "IJsselstein-Zuid" (61). Get off at the stop "P+R Westraven" (a.k.a. "Transferium Westraven") The stop before is "Kanaleneiland Zuid."<br />
<br />
; From the P+R Westraven stop<br />
<br />
Walk south (in the same direction as the tram), crossing over the tram tracks and the road &mdash; there is no crosswalk. Continue walking south and then east, following the path to a road that crosses the bridge Liesboschbrug. After walking past a large office building on your left, turn left at Ringwade and walk straight until you see the orange Ordina flags on the left, where you will find the main building's entrance.<br />
<br />
; At Ordina<br />
<br />
Go to the reception desk on the ground floor and tell them you are attending the Dutch HUG Day. They will ask for your name, check it off their list, and tell you where to go.<br />
<br />
<!--<br />
<br />
=== UHac at the BBL ===<br />
<br />
UHac starts out after the DHD in a classroom in the BBL (Buys Ballot Laboratorium) building at the "Uithof" (pronounced similar to "OUT-hof") campus of Utrecht University. Since the organizers are located there, and class is still in session, we don't have to pay a thing.<br />
<br />
==== Address ====<br />
<br />
[http://maps.google.com/maps?q=Princetonplein+5,+3584CC+Utrecht,+The+Netherlands Princetonplein 5, 3584CC Utrecht, The Netherlands]<br />
<br />
==== Getting there ====<br />
<br />
; By car<br />
<br />
Follow [http://www.uu.nl/EN/contactanddirections/deuithofbycar/Pages/default.aspx these directions] to reach the Uithof by car.<br />
<br />
; By bus<br />
<br />
From the central station, take bus 11 or 12. The both go to the Uithof, but they take different routes: bus 11 goes through the city center, and bus 12 stays to the south of the center.<br />
<br />
* With bus 11, take the "Botanische Tuinen" (Botanical Gardens) stop. The stop before is "Wim Sonneveldlaan."<br />
* With bus 12, take the "Padualaan" stop. The stop before is "Rijnsweerd Zuid."<br />
<br />
Once off the bus, walk north (from both stops) to the red building called the "Minnaert" (with its name spelled out in large letters on the facade).<br />
<br />
; Through the Minnaert<br />
<br />
[[Image:Minnaert.jpg|This is the Minnaert building, which is easier to spot. The arrow points to the BBL, immediately behind the Minnaert.]]<br />
<br />
Walk through the Minnaert to the BBL (indicated by the arrow in the photo above). The easiest way to find the path is by following a line of small, circular, metal plates on the walkway to the entrance of the Minnaert. These plates continue inside and lead directly to the BBL. Once you cross a bridge (with a view of bamboo!) into the BBL, simply take the stairs or elevator in the center of the building down to the ground floor and walk to the room.<br />
<br />
--><br />
<br />
=== UHac at Newton ===<br />
<br />
Over the weekend, UHac will be held in classrooms at the Newton building on the University College Utrecht (UCU) campus.<br />
<br />
==== Address ====<br />
<br />
[http://maps.google.com/maps?q=Campusplein+13-14,+3584ED,+Utrecht,+The+Netherlands Campusplein 13-14, 3584ED Utrecht, The Netherlands]<br />
<br />
==== Getting there ====<br />
<br />
; By car<br />
<br />
Follow [http://www.uu.nl/university/college/EN/contactvisiting/Pages/Directions.aspx these directions] to reach UCU by car. '''NOTE:''' Due to construction work, part of Prins Hendriklaan (the road leading to UCU) is currently closed to cars. Getting to the location should still be possible when driving via the Sophocleslaan.<br />
<br />
; By bus<br />
<br />
From the central station, take bus 12 in the direction of "Uithof UMC AZU." Get off at the stop "De Kromme Rijn." The stop before is "Stadion Galgenwaard."<br />
<br />
; From the bus stop<br />
<br />
Walk north/northwest (crossing the street from the bus stop) down Platolaan. The street makes a natural curve to the left and becomes Sophocleslaan and then curves right and becomes Prins Hendriklaan. There you will find the entrance to the UCU campus on your left.<br />
<br />
Walk through the pedestrian gate (and watch for cyclists going in and out). Take the left path walking around the central square. Newton Hall is the first building on the left at the corner of the square.<br />
<br />
; At Newton<br />
<br />
Enter from the south side (farthest from the pedestrian gate). We expect this door to be open during the day. If the door is locked, call Sean Leather or Jurriën Stutterheim (see [[DHD_UHac/Attendees|Attendees]] page for contact information).<br />
<br />
== Accommodation ==<br />
<br />
We have included a number of accommodations on [http://maps.google.com/maps/ms?msid=211877270309020342121.0004b89c16976b3a082db&msa=0 our map]. You might also check out the [http://www.bedandbreakfast.nl/plaats/Utrecht bed and breakfast locations in Utrecht].<br />
<br />
== Eating ==<br />
<br />
=== University College Utrecht ===<br />
<br />
On Saturday and Sunday, the Dining Hall is open for brunch and dinner. All other eating places on campus are closed.<br />
<br />
; Weekend hours<br />
{|<br />
| Brunch:<br />
| 10:30 - 12:30<br />
|-<br />
| Dinner:<br />
| 18:00 - 19:30<br />
|}<br />
<br />
=== Restaurants ===<br />
<br />
These are a few of the restaurants around Utrecht.<br />
<br />
==== Italian ====<br />
* [http://maps.google.nl/maps?q=il+pozzo&hl=nl&fb=1&gl=nl&hq=il+pozzo&hnear=0x47c66f4339d32d37:0xd6c8fc4c19af4ae9,Utrecht&cid=0,0,111793244555536424&t=m&z=16&iwloc=A Il Pozzo]<br />
* [http://www.ristorantelafontana.nl/ La Fontana]<br />
* [http://www.pizzeriatricolore.nl/ Tricolore]<br />
* [http://www.bellaitalia-pizza.nl/ Bella Italia]<br />
<br />
==== Vegetarian ====<br />
* [http://www.dewerfkring.com/?lang=en De Werfkring]<br />
<br />
==== Pancakes ====<br />
* [http://www.theehuisrhijnauwen.nl/theehuis/home.html Theehuis Rhijnauwen]<br />
* [http://www.deoudemuntkelder.nl/ De Oude Muntkelder]</div>SeanLeather