https://wiki.haskell.org/api.php?action=feedcontributions&user=BayleShanks&feedformat=atomHaskellWiki - User contributions [en]2019-09-18T23:08:48ZUser contributionsMediaWiki 1.27.4https://wiki.haskell.org/index.php?title=Class_system_extension_proposal&diff=58980Class system extension proposal2014-10-08T01:58:22Z<p>BayleShanks: Is this related to InstanceTemplates?</p>
<hr />
<div>[[Category:Proposals]]<br />
==Allowing superclass methods to be overridden in derived classes==<br />
===Motivation===<br />
<br />
The current class system in Haskell is based on the idea that you can often provide default implementations for class methods at the same time as defining the class, by using other methods of the class or its ancestors. However consider the following hierarchy, adapted from [[Functor hierarchy proposal]] and [[The Other Prelude]]:<br />
<haskell><br />
class Functor m where<br />
fmap :: (a -> b) -> m a -> m b<br />
<br />
class Functor m => Applicative m where<br />
return :: a -> m a<br />
<br />
apply :: m (a -> b) -> m a -> m b<br />
<br />
(>>) :: m a -> m b -> m b<br />
ma >> mb = (fmap (const id) ma) `apply` mb<br />
<br />
class Applicative m => Monad m where<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
</haskell><br />
For all concrete instances of <hask>Monad</hask> we can define <hask>fmap</hask>, <hask>apply</hask>, and <hask>(>>)</hask> in terms of <hask>return</hask> and <hask>(>>=)</hask> as follows:<br />
<haskell><br />
fmap f ma = ma >>= (\a -> return (f a))<br />
<br />
apply mf ma = mf >>= \f -> ma >>= \a -> return (f a)<br />
<br />
ma >> mb = ma >>= \_ -> mb</haskell><br />
In other words, we'd like to be able to write:<br />
<haskell><br />
class Applicative m => Monad m where<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
<br />
fmap f ma = ma >>= (\a -> return (f a))<br />
<br />
apply mf ma = mf >>= \f -> ma >>= \a -> return (f a)<br />
<br />
ma >> mb = ma >>= \_ -> mb<br />
</haskell><br />
and be able to define new instances of <hask>Monad</hask> just by supplying definitions for <hask>return</hask> and <hask>(>>=)</hask> by writing:<br />
<haskell><br />
instance Monad T where<br />
ma >>= a_mb = ... -- some definition<br />
<br />
return a = ... -- some definition<br />
</haskell><br />
<br />
However in Haskell at present we can't do this, because we are only allowed to provide default implementations for a class method in the class where the method is introduced (ie the class containing the method signature) and similarly we are only allowed to provide an implementation for a method in an instance for the class itself, not a derived class. Therefore with the above hierarchy, we would have to manually define instances of <hask>Functor</hask> and <hask>Applicative</hask> whenever we define an instance of <hask>Monad</hask>.<br />
<br />
It is worth pointing out several reasons why we desire to be able to just define new <hask>Monad</hask> instances whithout having to explicitly define instances for <hask>Functor</hask> and <hask>Applicative</hask>:<br />
* The idea of making <hask>Monad</hask> a subclass of <hask>Applicative</hask> was only discovered after many people had already used <hask>Monad</hask> in their programs. Therefore many existing programs already contain instance declarations for <hask>Monad</hask> as outlined above, so we would prefer not to have to change them just because the hierarchy has been refined to add extra functionality these existing programs don't use. This also applies to other hierachies in wide use at the moment, where changes have been proposed eg the <hask>Num</hask> hierarchy.<br />
* The implementation of <hask>(>>)</hask> in terms of <hask>(>>=)</hask> for <hask>Monad</hask> is much simpler than the default implementation provided by <hask>Applicative</hask>.<br />
* The example shows that sometimes the default implementation of a method depends on which subclass we are using, and so acts as a counterexample to the current assumption that default implementations can be provided in the class where the method is introduced.<br />
<br />
===Concrete proposal===<br />
# Class and instance declarations would allow method implementations to be given for any methods in the class or any ancestor class.<br />
# Whenever an instance declaration is visible there would always be a full set of instance declarations for all ancestor classes, by supplementing the set of explicitly given instance declarations that are visible in a module by automatically generated implicit instance declarations.<br />
# The most specific method implementation would always be chosen (ie prefer an explicit instance method over a class method and prefer a subclass method to a superclass method)<br />
# Modules would only export explicit instance declarations<br />
<br />
===Clarifications===<br />
* Separate compilation is still possible because all that's happening in the proposal is that the set of explicit instance declarations in scope in the module would be supplemented by a set of compiler-generated implicit instance declarations which are only visible in the module being compiled.<br />
<br />
===Implications===<br />
One implication of this proposal would be that the resolution of an overloaded method would depend on the instances in scope in the module where the method is called. Therefore overloading would need to be resolved before modules are conceptually merged together (especially important when considering whole program optimization), and in particular overloading of the body of an inlined function would need to be resolved using the module where the function was defined not the module where it is inlined.<br />
<br />
Another implication is that the current class system where each level in the hierarchy is independent from other levels (via separate instance declarations), solves the problem of "multiple inheritance": given <code>(Functor m, Applicative m, Monad m)</code> the compiler can find the definition for <code>fmap</code> just by looking at the instance for <code>Functor m</code> alone, whereas with the proposal the compiler would have to consider all the predicates in the context to determine the source of each overloaded function. This may or may not be a problem.<br />
<br />
==Explicit import/export of instances==<br />
This is needed so that large programs can be built without fear of colliding instance declarations between different packages. A possible syntax could be:<br />
<haskell><br />
module M<br />
-- exported instances <br />
( instance Monad T<br />
, instance Functor (F a) hiding (Functor (F Int), Functor (F Char))<br />
, F(..)<br />
) where<br />
<br />
import Foo (instance Monad a hiding Monad Maybe)<br />
<br />
data T a<br />
data F a b<br />
</haskell><br />
where the context is elided because this isn't used in instance selection (at the moment). The import directive tells the compiler to use all <hask>Monad</hask> instances exported by <hask>Foo</hask> except for the <hask>Monad Maybe</hask> instance (it doesn't matter whether or not <hask>Foo</hask> actually does export a <hask>Monad Maybe</hask> instance - all that matters here is that we don't want it if there is one).<br />
<br />
==Typeclass synonyms==<br />
<br />
This is needed for the same reason that we need type synonyms: to make complex types managable.<br />
<br />
See http://repetae.net/john/recent/out/classalias.html.<br />
<br />
=== Superclass defaults ===<br />
<br />
The above propsal handles two separate issues, contexts with lots of class names, and defaults. The compatible [[superclass defaults]] propsal separates these two issues.<br />
<br />
==Extensible superclasses==<br />
<br />
This increases modularity by allowing us to add a new superclass to a class without modifying the class itself, just as at present we can always add new subclasses.<br />
<br />
See http://taichi.ddns.comp.nus.edu.sg/taichiwiki/GPHomePage for a motivating example.<br />
<br />
More details can be found in the paper ''Modular Generic Programming with Extensible Superclasses'', available in ps format from<br />
http://www.comp.nus.edu.sg/~sulzmann/publications/wgp06-modulargeneric.ps or in pdf from http://users.ox.ac.uk/~wolf2335/publications/generic.pdf.<br />
<br />
==Quantified contexts==<br />
A minor annoyance is that the <hask>Monoid</hask>, <hask>MonadPlus</hask> and <hask>ArrowPlus</hask> are all essentially the same. Allowing forall in contexts gives a way to combine these classes back into one. See [[Quantified contexts|the proposal]] for details.<br />
<br />
==Links==<br />
Is this related to https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates ?</div>BayleShankshttps://wiki.haskell.org/index.php?title=Functor-Applicative-Monad_Proposal&diff=58979Functor-Applicative-Monad Proposal2014-10-08T00:22:07Z<p>BayleShanks: sp</p>
<hr />
<div>Haskell calls a couple of historical accidents its own. While some of them, such as the "number classes" hierarchy, can be justified by pragmatism or lack of a strictly better suggestion, there is one thing that stands out as, well, not that: Applicative not being a superclass of Monad.<br />
<br />
The topic has been discussed multiple times in the past (cf. link section at the very end). '''This article was updated to describe the current, and very likely to succeed, Haskell 2014 Applicative => Monad proposal (AMP)'''.<br />
<br />
Some relevant links:<br />
* [https://github.com/quchen/articles/blob/master/applicative_monad.md Initial text of the Haskell 2014 AMP]<br />
* [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/19482 AMP mailing list discussion]<br />
* Phase one: ticket [http://hackage.haskell.org/trac/ghc/ticket/8004 #8004]<br />
<br />
<br />
<br />
== Proposal contents ==<br />
<br />
The list of changes is as follows:<br />
<br />
# Applicative becomes a superclass of Monad, and is added to the Prelude.<br />
# Alternative becomes a superclass of MonadPlus (in addition to Monad, of course).<br />
# <s><hask>join</hask> is promoted into the Monad typeclass.</s> - Left out due to nontrivial breaking interaction with [[Roles]]. Will "probably be fixed in the future", but for now it's off the table.<br />
<br />
The general rationale behind these changes:<br />
<br />
# ''Break as little code as possible.'' For example, do not move <hask>return</hask> to Applicative and remove <hask>pure</hask>. Instead, leave <hask>return</hask> in Monad, and give it <hask>pure</hask> as default implementation.<br />
# ''Change only things that are closely related to the proposal.'' For example, using <hask>join</hask> in a monad definition requires it to be a functor, so it goes hand in hand with the AMP. On the other hand, removing <hask>fail</hask> has nothing to do with what we're trying to accomplish.<br />
<br />
<br />
<br />
== Future-proofing current code ==<br />
<br />
GHC 7.8 will issue two types of warnings in order to encourage wide-scale code fixing. The following describes how to get rid of them, and as a result ensures your code builds both now and after the AMP is finished.<br />
<br />
=== Missing superclasses ===<br />
<br />
(Warnings of the type "Warning: X is an instance of C, but not D")<br />
<br />
* Add Applicative/Functor instances for all your Monads. You can simply derive these instances from the Monad by adding the following code:<br />
<haskell><br />
import Control.Applicative (Applicative(..))<br />
import Control.Monad (liftM, ap)<br />
<br />
-- Monad m<br />
<br />
instance Functor m where<br />
fmap = liftM<br />
<br />
instance Applicative m where<br />
pure = return<br />
(<*>) = ap<br />
</haskell><br />
<br />
* Add an Alternative instance for all instances of MonadPlus. This can again be done easily using<br />
<haskell><br />
import Control.Applicative (Alternative(..))<br />
import Control.Monad (mzero, mplus)<br />
<br />
-- MonadPlus m<br />
<br />
instance Alternative m where<br />
(<|>) = mplus<br />
empty = mzero<br />
</haskell><br />
<br />
=== Future Prelude names ===<br />
<br />
"The name X clashes with a future Prelude name" - Prelude will export functions called <hask><*></hask>, <hask>join</hask> and <hask>pure</hask>, so if a module defines its own versions of them, there will be name clashes. There are multiple ways of getting rid of this type of warning (in a future-proof way).<br />
<br />
# Change your code to not define functions named <hask><*></hask>, <hask>join</hask> or <hask>pure</hask>.<br />
# Import Prelude definitions you need explicitly. For example, <hask>import Prelude (map, (+))</hask> would not import <hask>join</hask>, so no warning is issued as the module is compatible with the Prelude exporting <hask>join</hask>. <hask>hiding</hask>.<br />
# Due to GHC internals, you cannot use <hask>hiding (join, (<*>), pure)</hask> to silence the warnings, although this method would be future-proof. If you want to use <hask>hiding</hask>, you will have to silence the warnings using a sledgehammer <code>-fno-warn-amp</code> compiler flag. (If you do so make sure you know what you're doing, otherwise your module ''will'' break in 7.10.) To make 7.10 not complain about the then unrecognized flag, it's best to specify it in a CPP block,<br />
<haskell><br />
{-# LANGUAGE CPP #-}<br />
#if __GLASGOW_HASKELL__ >= 707 && __GLASGOW_HASKELL__ < 710<br />
{-# OPTIONS_GHC -fno-warn-amp #-}<br />
#endif<br />
</haskell><br />
<br />
== Discussion and consequences ==<br />
<br />
<br />
=== It's the right thing to do™ ===<br />
<br />
Math. You've all heard this one, it's good and compelling so I don't need to spell it out.<br />
<br />
<br />
=== Redundant functions ===<br />
<br />
* <hask>pure</hask> and <hask>return</hask> do the same thing.<br />
* <hask>>></hask> and <hask>*></hask> are identical.<br />
* <hask>liftM</hask> and <hask>liftA</hask> are <hask>fmap</hask>. The <hask>liftM*</hask> are <hask>liftA*</hask>, <hask><*></hask> is <hask>ap</hask>.<br />
* Prelude's <hask>sequence</hask> requires <hask>Monad</hask> right now, while <hask>Applicative</hask> is sufficient to implement it. The more general version of this issue is captured by <hask>Data.Traversable</hask>, whose main typeclass implements the *same* functionality twice, namely <hask>traverse</hask> and <hask>mapM</hask>, and <hask>sequenceA</hask> and <hask>sequence</hask>.<br />
* The <hask>WrappedMonad</hask> type from <hask>Control.Applicative</hask> provides a semi-automatic way to using Functor/Applicative/Alternative functions for Monad/MonadPlus instances as a makeshift patch.<br />
<br />
That very much violates the "don't repeat yourself" principle, and even more so it ''forces'' the programmer to repeat himself to achieve maximal generality. It may be too late to take all redundancies out, but at least we can prevent new ones from being created.<br />
<br />
(Note that it is not proposed to remove any functions for compatibility reasons. Maybe some of them can be phased out in the long run, but that's beyond scope here.)<br />
<br />
<br />
=== Using Functor/Applicative functions in monadic code ===<br />
<br />
Whenever there's Monad code, you can use Functor/Applicative functions, without introducing an additional constraint. Keep in mind that "Functor/Applicative functions" does not only include what their typeclasses define but many more, for example <hask>void</hask>, <hask>(<$>)</hask>, <hask>(<**>)</hask>.<br />
<br />
Even if you think you have monadic code, strictly using the least restrictive functions may result in something that requires only Applicative. This is similar to writing a function that needs <hask>Int</hask>, but it turns out any <hask>Integral</hask> will do - more polymorphism for free.<br />
<br />
<br />
=== Compatibility issues ===<br />
<br />
These are the kinds of issues to be expected:<br />
<br />
# Monads lacking Functor or Applicative instances. This is easily fixable by either setting <hask>fmap = liftM</hask>, <hask>pure = return</hask> and <hask>(<*>) = ap</hask>, although more efficient implementations may exist, or by moving an already existing definition from <hask>Control.Applicative</hask> to the appropriate module.<br />
# This one is specific to building GHC: importing <hask>Control.Monad/Applicative</hask> introduces a circular module dependency. In this case, one can rely on handwritten implementations of the desired function, e.g. <hask>ap f x = f >>= ...</hask>.<br />
# Libraries using their own <hask>(<*>)</hask>. This one is potentially the most laborious consequence. For building GHC though, this only concerns Hoopl, and a handful of renames.<br />
<br />
<br />
<br />
=== Beginner friendliness ===<br />
<br />
How often did you say ...<br />
<br />
* "A Monad is always an Applicative but due to historical reasons it's not but you can easily verify it by setting <hask>pure = return</hask> and <hask>(<*>) = ap</hask>"<br />
* "<hask>liftM</hask> is <hask>fmap</hask> but not really." - "So when should I use <hask>fmap</hask> and when <hask>liftM</hask>?" - ''sigh''<br />
<br />
With the new hierarchy, the answer would ''always'' be "use the least restrictive one".<br />
<br />
== Applying the AMP to GHC and then Haskell in practice ==<br />
<br />
Proposed is a gradual introduction of the AMP in three phases:<br />
<br />
<br />
=== '''Done''': Prepare GHC ===<br />
<br />
Using a GHC fork with the full patch applied, find and fix all compilation errors introduced by the change by adding Functor/Applicative instances for all Monads.<br />
<br />
According to SPJ, adding an ad-hoc warning of sorts "Monad without Applicative detected" is not a problem, which will be crucial for the next phase. More specifically, issue a warning if:<br />
<br />
* Monad without Applicative<br />
* MonadPlus without Alternative<br />
* One of <hask><*></hask>, <hask>pure</hask>, <hask>join</hask> is defined in a different context to avoid naming conflicts, as these functions will go into the Prelude<br />
<br />
=== '''Current stage''': Prepare Hackage ===<br />
<br />
The warning just mentioned will hint to all authors that they should fix (or help others fix) the non-complying packages. This will ideally lead to libraries eventually adding Applicative instances, and changing their APIs if they redefine operators like <hask><*></hask>.<br />
<br />
After enough time has passed by so libraries adapted to the circumstances, move on to the next phase.<br />
<br />
<br />
=== Apply the proposal ===<br />
<br />
Once Hackage is prepared, applying the changes to the Base package is painless. However, this is not primarily a GHC, but a Haskell change. The previous steps were basically preparing the landscape, and when we've (hopefully) found out that it is a good idea to go through with it, it can be proposed to go into the Report. If we make it this far, the AMP should pass quite easily.<br />
<br />
<br />
<br />
== Previous proposals ==<br />
<br />
* Early 2011: [http://hackage.haskell.org/trac/ghc/ticket/4834 GHC ticket] &ndash; changes similar to this proposal, but closed as "not GHC, but Haskell". See [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/14883/focus=14905 here] for the associated discussion.<br />
* [[The Other Prelude]]<br />
<br />
<br />
[[Category:Proposals]]<br />
[[Category:Functor]]<br />
[[Category:Applicative Functor]]<br />
[[Category:Monad]]</div>BayleShankshttps://wiki.haskell.org/index.php?title=Monomorphism_restriction&diff=55310Monomorphism restriction2013-01-26T11:32:34Z<p>BayleShanks: Why does the example from History of Haskell not fail?</p>
<hr />
<div>The monomorphism restriction is probably the most annoying and controversial feature of Haskell's type system. And is turned off with the use of the NoMonomorphismRestriction language pragma. All seem to agree that it is evil, but whether or not it is considered a necessary evil depends on who you ask.<br />
<br />
The definition of the restriction is fairly technical, but to a first approximation it means that you often cannot overload a function unless you provide an explicit type signature. In summary:<br />
<br />
<haskell><br />
-- This is allowed<br />
f1 x = show x<br />
<br />
-- This is not allowed<br />
f2 = \x -> show x<br />
<br />
-- ...but this is allowed<br />
f3 :: (Show a) => a -> String<br />
f3 = \x -> show x<br />
<br />
-- This is not allowed<br />
f4 = show<br />
<br />
-- ...but this is allowed<br />
f5 :: (Show a) => a -> String<br />
f5 = show<br />
</haskell><br />
<br />
Arguably, these should all be equivalent, but thanks to the monomorphism restriction, they are not.<br />
<br />
The difference between the first and second version is that the first version binds x via a "simple pattern binding" (see section 4.4.3.2 of the Haskell 98 report), and is therefore unrestricted, but the second version does not. The reason why one is allowed and the other is not is that it's considered clear that sharing f1 will not share any computation, and less clear that sharing f2 will have the same effect. If this seems arbitrary, that's because it is. It is difficult to design an objective rule which disallows subjective unexpected behaviour. Some people are going to fall foul of the rule even though they're doing quite reasonable things.<br />
<br />
So why is the restriction imposed? The reasoning behind it is fairly subtle, and is fully explained in the [http://haskell.org/onlinereport/ Haskell 98 report]. Basically, it solves one practical problem (without the restriction, there would be some ambiguous types) and one semantic problem (without the restriction, there would be some repeated evaluation where a programmer might expect the evaluation to be shared). Those who are for the restriction argue that these cases should be dealt with correctly. Those who are against the restriction argue that these cases are so rare that it's not worth sacrificing the type-independence of eta reduction.<br />
<br />
:An example, from [http://research.microsoft.com/~simonpj/papers/history-of-haskell/index.htm A History of Haskell]: Consider the <code>genericLength</code> function, from <code>Data.List</code><br />
<br />
:<haskell><br />
genericLength :: Num a => [b] -> a<br />
</haskell><br />
<br />
:And consider the function:<br />
<br />
<haskell><br />
f xs = (len,len)<br />
where<br />
len = genericLength xs<br />
</haskell><br />
<br />
:<code>len</code> has type <code>Num a => a</code> and, without the monomorphism restriction, it could be computed ''twice''. --[[User:ARG|ARG]]<br />
<br />
----<br />
<br />
It is not clear to me how this whole thing about being computed once or twice works. Isn't type checking/inference something that happens at compile-time and shouldn't have any effect on what happens at run-time, as long as the typecheck passes? [[User:Dainichi|Dainichi]]<br />
<br />
The trouble is that typeclasses essentially introduce additional function parameters -- specifically, the dictionary of code implementing the instances in question. In the case of typeclass polymorphic pattern bindings, you end up turning something that looked like a pattern binding -- a constant that would only ever be evaluated once, into what is really a function binding, something which will not be memoised. [[User:CaleGibbard|CaleGibbard]] 23:46, 1 February 2008 (UTC)<br />
<br />
The type of <code>f</code>, if no signature is given, then the compiler doesn't know that the two elements of the returned pair are of the same type. It's return value will be:<br />
<br />
<haskell><br />
f::(Num a, Num b) => [x] -> (a, b)<br />
</haskell><br />
<br />
This means that <i>while compiling f</i> the compiler is unable to memoise len - clearly if a /= b then different code is executed to compute the first and second appearance of len in the pair. It's possible the compiler could do something more clever <i>when f is actually applied</i> if a == b, but I'm supposing this isn't a straight-forward thing to implement in the compilers. [[User:Dozer|Dozer]] 23:54, 4 February 2008 (GMT)<br />
<br />
Thank you, the nature of the ''problem'' is getting clearer now, but I'm still confused about how the restriction of top level definitions is supposed to ''solve'' this problem. To me, the given example explains why f's type is inferred to be <haskell>Num a => [x] -> (a, a)</haskell>, not <haskell>(Num a, Num b) => [x] -> (a, b)</haskell>, but not why this means that you cannot define top-level overloading outside pattern bindings. Is there an example which makes this clearer?<br />
<br />
Maybe I need to read up on the Hindley–Milner type system, but this seems related to the existence of functions (such as genericLength and read) that are polymorphic in their return type. Would MR need to exist without these functions? <br />
<br />
I'm a bit confused about functions like this, since I somehow feel they belong to more of a system with dependent types. <br />
<br />
--[[User:Dainichi|Dainichi]] 06:53 15 Aug 2011 (UTC)<br />
<br />
The following compiles for me on ghc 7.4.1:<br />
<br />
<haskell><br />
module Main where<br />
import Data.List<br />
<br />
main = putStrLn $ show (f [])<br />
<br />
f xs = (len,len)<br />
where<br />
len = genericLength xs<br />
</haskell><br />
<br />
If i add <code>f2 = \x -> show x</code>, compilation fails, demonstrating that i still have the monomorphism restriction enabled. <br />
<br />
This is not due to type inference from the putStrLn $ show (f []) doing anything; in fact, this compiles fine:<br />
<br />
<br />
<haskell><br />
module Main where<br />
import Data.List<br />
<br />
main = putStrLn ""<br />
<br />
f xs = (len,len)<br />
where<br />
len = genericLength xs<br />
<br />
-- f2 = \x -> show x <br />
</haskell><br />
<br />
whereas this fails to compile:<br />
<br />
<haskell><br />
module Main where<br />
import Data.List<br />
<br />
main = putStrLn ""<br />
<br />
--f xs = (len,len)<br />
-- where<br />
-- len = genericLength xs<br />
<br />
f2 = \x -> show x<br />
</haskell><br />
<br />
Why does the example from History of Haskell not fail? -- [[BayleShanks]] <br />
<br />
<br />
----<br />
<br />
Oversimplifying the debate somewhat: Those in favour tend to be those who have written Haskell [[Implementations]] and those against tend to be those who have written complex combinator libraries (and hence have hit their collective heads against the restriction all too often). It often boils down to the fact that programmers want to avoid [http://catb.org/esr/jargon/html/L/legalese.html legalese], and language implementors want to avoid [http://catb.org/esr/jargon/html/C/cruft.html cruft].<br />
<br />
In almost all cases, you can get around the restriction by including explicit type declarations. Those who are for the restriction are usually quick to point out that including explicit type declarations is good programming practice anyway. In a few very rare cases, however, you may need to supply a type signature which is not valid Haskell. (Such type signatures require a type system extension such as [[Scoped type variables]].) Unless you're writing some weird combinator libraries, or are in the habit of not writing type declarations, you're unlikely to come across it. Even so, most Haskell [[Implementations]] provide a way to turn the restriction off.<br />
<br />
See also: [http://haskell.org/onlinereport/decls.html#sect4.5.5 Section 4.5.5, Haskell 98 report].<br />
<br />
-- [[Andrew Bromage]]<br />
<br />
Some question or suggestion: As I understand the problem arises from the situation that two different forms of assignment are described by the same notation. There are two forms of assignment, namely the inspection of data structures ("unpacking", "pattern binding") and the definition of functions ("function binding"). Unique examples are:<br />
<br />
<haskell><br />
let f x = y -- function definition<br />
let F x = y -- data structure decomposition<br />
</haskell><br />
<br />
In the first case we have the identifier f starting with lower case. This means this is a function binding. The second assignment starts with F, which must be a constructor. That's why this is a pattern binding. The monomorphism restriction applies only to the pattern binding. I think this was not defined in order to please compiler writers, but has shown to be useful in practice, or am I wrong? But the different handling of these binding types leads to a problem since both types have a common case.<br />
<br />
<haskell><br />
let x = y -- function or pattern binding?<br />
</haskell><br />
<br />
So, what speaks against differentiating the assignments notationally, say<br />
<br />
<haskell><br />
let f x = y -- function definition<br />
let F x <= y -- data structure decomposition<br />
</haskell><br />
<br />
and keep the monomorphism restriction as it is?<br />
<br />
-- [[Henning Thielemann]]<br />
<br />
The problem isn't just pattern bindings, it's that pattern bindings which are typeclass polymorphic are actually function bindings in disguise, since the usual implementation of typeclasses adds parameters to such definitions, to allow the definition to take the typeclass dictionaries involved. Thus, such pattern bindings have different properties with respect to sharing (they're generally less shared than you want). In especially bad cases, without the MR, it is possible to have programs which run exponentially slower without type signatures than when signatures are added. Just distinguishing pattern bindings with a new notation doesn't solve the problem, since they'll have to be converted into function bindings in that case anyway. If you intend to keep the MR, then you don't need to change anything. The issue with the MR is just the fact that it's annoying to have eta-reduction fail in the absence of explicit type signatures, and the fact that it makes otherwise perfectly valid programs fail to compile on speculation that there might be loss of sharing (when there usually isn't, or at least the impact isn't large enough to worry about).<br />
<br />
John Hughes recently advocated the removal of the MR on the Haskell Prime mailing list, and suggested replacing it with two forms of pattern binding: one for call-by-name (polymorphic, not shared), and one for call-by-need (monomorphic, guaranteed shared). This might be similar to what you're suggesting. If you look at it too closely, it seems like a good solution, but the overall impact on Haskell code seems too large to me, to resolve a distinction which it ought to be statically possible to determine.<br />
<br />
I'm of the opinion that it would be better to find a way to restore sharing lost through the typeclass transformation in some way, or else implement typeclasses in an altogether different way which doesn't run into this problem. Additional runtime machinery seems like a likely candidate for this -- the interactions with garbage collection are somewhat subtle, but I think it should be doable. It's also possible to restore the sharing via whole-program analysis, but advocates of separate compilation will probably complain, unless we were to find a mechanism to fix the problem from the object code (and potentially temporaries) at link time.<br />
<br />
:- [[Cale Gibbard]]<br />
<br />
--------------------<br />
I think it'd be useful to collect a set of examples of the Monormorphism Restriction biting people in an unexpected way. This may help to inform the debate over the MR by giving real-life examples. Add more examples here if (an only if) they constitute an unexpected MR-related incident in your life or someone else's. No invented examples! -- [[Simon Peyton Jones]]<br />
<br />
* GHC Trac bug [http://hackage.haskell.org/trac/ghc/ticket/1749 1749]<br />
* In trying to build an editor with undoable actions:<br />
<haskell><br />
class EditAction e a | e -> a where<br />
apply :: a -> e -> a<br />
<br />
data ListAction a = Append a | Remove<br />
<br />
instance EditAction (ListAction a) [a] where<br />
apply list (Append a) = a:list<br />
apply (x:xs) Remove = xs<br />
<br />
-- Apply all the EditActions to the input<br />
--edit :: EditAction e a => a -> [e] -> a -- monomorphism restriction - I have to put this in!<br />
edit = foldl apply<br />
</haskell><br />
<br />
----<br />
Back before forM was in the Control.Monad library, I once spent about 1/2 an hour trying to figure out why my action in the ST monad was having its '<hask>s</hask>' parameter squished to <hask>()</hask>. I tore the code apart for quite a while before discovering that it was that the MR was applying to my definition of <hask>forM</hask>:<br />
<br />
<haskell><br />
forM = flip mapM<br />
</haskell><br />
<br />
----<br />
I recently got tired of typing <hask>print "blah"</hask> in a ghci shell session and tried <hask>let p = print</hask>. Thanks to MR and Haskell defaulting, the type of <hask>p</hask> silently became <hask>() -> IO ()</hask>. No surprise that my new "short" version of print was only capable of printing void values -<br />
<br />
<hask><br />
Prelude> p ()<br />
()<br />
Prelude> p "blah"<br />
<br />
<interactive>:1:2:<br />
Couldn't match expected type `()' against inferred type `[Char]'<br />
In the first argument of `p', namely `"blah"'<br />
In the expression: p "blah"<br />
In the definition of `it': it = p "blah"<br />
</hask><br />
<br />
----<br />
<br />
<haskell><br />
import Graphics.UI.Gtk<br />
import Graphics.UI.Gtk.Glade<br />
<br />
-- xmlGetWidget' :: WidgetClass widget => (GObject -> widget) -> String -> IO widget<br />
xmlGetWidget' = xmlGetWidget undefined<br />
<br />
main :: IO ()<br />
main<br />
= do<br />
initGUI<br />
window <- xmlGetWidget' castToWindow "window1"<br />
button <- xmlGetWidget' castToButton "button1"<br />
widgetShowAll window<br />
mainGUI<br />
</haskell><br />
<br />
If I comment main, I cannot compile this code because of the monomorphism restriction. With main, it'll infer the type:<br />
<br />
<haskell><br />
xmlGetWidget' :: (GObject -> Window) -> String -> IO Window<br />
</haskell><br />
<br />
And give me a type error in the button line. If I uncomment the type signature, it'll work.<br />
----<br />
<br />
I wasn't expecting the following to fail...<br />
<br />
<haskell><br />
square :: (Num a) => a -> a <br />
square x = x * x <br />
dx = 0.0000001<br />
deriv1 :: (Fractional a) => (a -> a) -> (a -> a)<br />
deriv1 g = (\x -> ((g (x + 2) - (g x)) / dx )) <br />
main = printf "res==%g %g\n" (square 5.12::Double) ((deriv1 square) 2::Float)<br />
</haskell><br />
<br />
and for this to work.<br />
<br />
<haskell><br />
square :: (Num a) => a -> a <br />
square x = x * x <br />
dx = 0.0000001<br />
deriv1 :: (Fractional a) => (a -> a) -> (a -> a)<br />
deriv1 g = (\x -> ((g (x + 2) - (g x)) / 0.0000001 )) <br />
main = printf "res==%g %g\n" (square 5.12::Double) ((deriv1 square) 2::Float)<br />
</haskell><br />
<br />
The fix was to add<br />
<br />
<haskell><br />
dx :: Fractional a => a<br />
</haskell><br />
<br />
--Harry<br />
<br />
----<br />
<br />
Along the same lines as Simon's question above, does anyone have any real examples of being bitten by the lack of MR? I know what it's for, but I can't really think of any realistic cases when it would be a problem. --pumpkin<br />
<br />
[[Category:Glossary]]<br />
[[Category:Language]]</div>BayleShankshttps://wiki.haskell.org/index.php?title=Monomorphism_restriction&diff=55309Monomorphism restriction2013-01-26T11:25:52Z<p>BayleShanks: the example from History of Haskell does not invoke the monomorphism restriction</p>
<hr />
<div>The monomorphism restriction is probably the most annoying and controversial feature of Haskell's type system. And is turned off with the use of the NoMonomorphismRestriction language pragma. All seem to agree that it is evil, but whether or not it is considered a necessary evil depends on who you ask.<br />
<br />
The definition of the restriction is fairly technical, but to a first approximation it means that you often cannot overload a function unless you provide an explicit type signature. In summary:<br />
<br />
<haskell><br />
-- This is allowed<br />
f1 x = show x<br />
<br />
-- This is not allowed<br />
f2 = \x -> show x<br />
<br />
-- ...but this is allowed<br />
f3 :: (Show a) => a -> String<br />
f3 = \x -> show x<br />
<br />
-- This is not allowed<br />
f4 = show<br />
<br />
-- ...but this is allowed<br />
f5 :: (Show a) => a -> String<br />
f5 = show<br />
</haskell><br />
<br />
Arguably, these should all be equivalent, but thanks to the monomorphism restriction, they are not.<br />
<br />
The difference between the first and second version is that the first version binds x via a "simple pattern binding" (see section 4.4.3.2 of the Haskell 98 report), and is therefore unrestricted, but the second version does not. The reason why one is allowed and the other is not is that it's considered clear that sharing f1 will not share any computation, and less clear that sharing f2 will have the same effect. If this seems arbitrary, that's because it is. It is difficult to design an objective rule which disallows subjective unexpected behaviour. Some people are going to fall foul of the rule even though they're doing quite reasonable things.<br />
<br />
So why is the restriction imposed? The reasoning behind it is fairly subtle, and is fully explained in the [http://haskell.org/onlinereport/ Haskell 98 report]. Basically, it solves one practical problem (without the restriction, there would be some ambiguous types) and one semantic problem (without the restriction, there would be some repeated evaluation where a programmer might expect the evaluation to be shared). Those who are for the restriction argue that these cases should be dealt with correctly. Those who are against the restriction argue that these cases are so rare that it's not worth sacrificing the type-independence of eta reduction.<br />
<br />
:An example, from [http://research.microsoft.com/~simonpj/papers/history-of-haskell/index.htm A History of Haskell]: Consider the <code>genericLength</code> function, from <code>Data.List</code><br />
<br />
:<haskell><br />
genericLength :: Num a => [b] -> a<br />
</haskell><br />
<br />
:And consider the function:<br />
<br />
<haskell><br />
f xs = (len,len)<br />
where<br />
len = genericLength xs<br />
</haskell><br />
<br />
:<code>len</code> has type <code>Num a => a</code> and, without the monomorphism restriction, it could be computed ''twice''. --[[User:ARG|ARG]]<br />
<br />
----<br />
<br />
It is not clear to me how this whole thing about being computed once or twice works. Isn't type checking/inference something that happens at compile-time and shouldn't have any effect on what happens at run-time, as long as the typecheck passes? [[User:Dainichi|Dainichi]]<br />
<br />
The trouble is that typeclasses essentially introduce additional function parameters -- specifically, the dictionary of code implementing the instances in question. In the case of typeclass polymorphic pattern bindings, you end up turning something that looked like a pattern binding -- a constant that would only ever be evaluated once, into what is really a function binding, something which will not be memoised. [[User:CaleGibbard|CaleGibbard]] 23:46, 1 February 2008 (UTC)<br />
<br />
The type of <code>f</code>, if no signature is given, then the compiler doesn't know that the two elements of the returned pair are of the same type. It's return value will be:<br />
<br />
<haskell><br />
f::(Num a, Num b) => [x] -> (a, b)<br />
</haskell><br />
<br />
This means that <i>while compiling f</i> the compiler is unable to memoise len - clearly if a /= b then different code is executed to compute the first and second appearance of len in the pair. It's possible the compiler could do something more clever <i>when f is actually applied</i> if a == b, but I'm supposing this isn't a straight-forward thing to implement in the compilers. [[User:Dozer|Dozer]] 23:54, 4 February 2008 (GMT)<br />
<br />
Thank you, the nature of the ''problem'' is getting clearer now, but I'm still confused about how the restriction of top level definitions is supposed to ''solve'' this problem. To me, the given example explains why f's type is inferred to be <haskell>Num a => [x] -> (a, a)</haskell>, not <haskell>(Num a, Num b) => [x] -> (a, b)</haskell>, but not why this means that you cannot define top-level overloading outside pattern bindings. Is there an example which makes this clearer?<br />
<br />
Maybe I need to read up on the Hindley–Milner type system, but this seems related to the existence of functions (such as genericLength and read) that are polymorphic in their return type. Would MR need to exist without these functions? <br />
<br />
I'm a bit confused about functions like this, since I somehow feel they belong to more of a system with dependent types. <br />
<br />
--[[User:Dainichi|Dainichi]] 06:53 15 Aug 2011 (UTC)<br />
<br />
The following compiles for me on ghc 7.4.1:<br />
<br />
<haskell><br />
module Main where<br />
import Data.List<br />
<br />
main = putStrLn $ show (f [])<br />
<br />
f xs = (len,len)<br />
where<br />
len = genericLength xs<br />
</haskell><br />
<br />
If i add <code>f2 = \x -> show x</code>, compilation fails, demonstrating that i still have the monomorphism restriction enabled. Why does the example from History of Haskell not fail? -- BayleShanks <br />
<br />
<br />
----<br />
<br />
Oversimplifying the debate somewhat: Those in favour tend to be those who have written Haskell [[Implementations]] and those against tend to be those who have written complex combinator libraries (and hence have hit their collective heads against the restriction all too often). It often boils down to the fact that programmers want to avoid [http://catb.org/esr/jargon/html/L/legalese.html legalese], and language implementors want to avoid [http://catb.org/esr/jargon/html/C/cruft.html cruft].<br />
<br />
In almost all cases, you can get around the restriction by including explicit type declarations. Those who are for the restriction are usually quick to point out that including explicit type declarations is good programming practice anyway. In a few very rare cases, however, you may need to supply a type signature which is not valid Haskell. (Such type signatures require a type system extension such as [[Scoped type variables]].) Unless you're writing some weird combinator libraries, or are in the habit of not writing type declarations, you're unlikely to come across it. Even so, most Haskell [[Implementations]] provide a way to turn the restriction off.<br />
<br />
See also: [http://haskell.org/onlinereport/decls.html#sect4.5.5 Section 4.5.5, Haskell 98 report].<br />
<br />
-- [[Andrew Bromage]]<br />
<br />
Some question or suggestion: As I understand the problem arises from the situation that two different forms of assignment are described by the same notation. There are two forms of assignment, namely the inspection of data structures ("unpacking", "pattern binding") and the definition of functions ("function binding"). Unique examples are:<br />
<br />
<haskell><br />
let f x = y -- function definition<br />
let F x = y -- data structure decomposition<br />
</haskell><br />
<br />
In the first case we have the identifier f starting with lower case. This means this is a function binding. The second assignment starts with F, which must be a constructor. That's why this is a pattern binding. The monomorphism restriction applies only to the pattern binding. I think this was not defined in order to please compiler writers, but has shown to be useful in practice, or am I wrong? But the different handling of these binding types leads to a problem since both types have a common case.<br />
<br />
<haskell><br />
let x = y -- function or pattern binding?<br />
</haskell><br />
<br />
So, what speaks against differentiating the assignments notationally, say<br />
<br />
<haskell><br />
let f x = y -- function definition<br />
let F x <= y -- data structure decomposition<br />
</haskell><br />
<br />
and keep the monomorphism restriction as it is?<br />
<br />
-- [[Henning Thielemann]]<br />
<br />
The problem isn't just pattern bindings, it's that pattern bindings which are typeclass polymorphic are actually function bindings in disguise, since the usual implementation of typeclasses adds parameters to such definitions, to allow the definition to take the typeclass dictionaries involved. Thus, such pattern bindings have different properties with respect to sharing (they're generally less shared than you want). In especially bad cases, without the MR, it is possible to have programs which run exponentially slower without type signatures than when signatures are added. Just distinguishing pattern bindings with a new notation doesn't solve the problem, since they'll have to be converted into function bindings in that case anyway. If you intend to keep the MR, then you don't need to change anything. The issue with the MR is just the fact that it's annoying to have eta-reduction fail in the absence of explicit type signatures, and the fact that it makes otherwise perfectly valid programs fail to compile on speculation that there might be loss of sharing (when there usually isn't, or at least the impact isn't large enough to worry about).<br />
<br />
John Hughes recently advocated the removal of the MR on the Haskell Prime mailing list, and suggested replacing it with two forms of pattern binding: one for call-by-name (polymorphic, not shared), and one for call-by-need (monomorphic, guaranteed shared). This might be similar to what you're suggesting. If you look at it too closely, it seems like a good solution, but the overall impact on Haskell code seems too large to me, to resolve a distinction which it ought to be statically possible to determine.<br />
<br />
I'm of the opinion that it would be better to find a way to restore sharing lost through the typeclass transformation in some way, or else implement typeclasses in an altogether different way which doesn't run into this problem. Additional runtime machinery seems like a likely candidate for this -- the interactions with garbage collection are somewhat subtle, but I think it should be doable. It's also possible to restore the sharing via whole-program analysis, but advocates of separate compilation will probably complain, unless we were to find a mechanism to fix the problem from the object code (and potentially temporaries) at link time.<br />
<br />
:- [[Cale Gibbard]]<br />
<br />
--------------------<br />
I think it'd be useful to collect a set of examples of the Monormorphism Restriction biting people in an unexpected way. This may help to inform the debate over the MR by giving real-life examples. Add more examples here if (an only if) they constitute an unexpected MR-related incident in your life or someone else's. No invented examples! -- [[Simon Peyton Jones]]<br />
<br />
* GHC Trac bug [http://hackage.haskell.org/trac/ghc/ticket/1749 1749]<br />
* In trying to build an editor with undoable actions:<br />
<haskell><br />
class EditAction e a | e -> a where<br />
apply :: a -> e -> a<br />
<br />
data ListAction a = Append a | Remove<br />
<br />
instance EditAction (ListAction a) [a] where<br />
apply list (Append a) = a:list<br />
apply (x:xs) Remove = xs<br />
<br />
-- Apply all the EditActions to the input<br />
--edit :: EditAction e a => a -> [e] -> a -- monomorphism restriction - I have to put this in!<br />
edit = foldl apply<br />
</haskell><br />
<br />
----<br />
Back before forM was in the Control.Monad library, I once spent about 1/2 an hour trying to figure out why my action in the ST monad was having its '<hask>s</hask>' parameter squished to <hask>()</hask>. I tore the code apart for quite a while before discovering that it was that the MR was applying to my definition of <hask>forM</hask>:<br />
<br />
<haskell><br />
forM = flip mapM<br />
</haskell><br />
<br />
----<br />
I recently got tired of typing <hask>print "blah"</hask> in a ghci shell session and tried <hask>let p = print</hask>. Thanks to MR and Haskell defaulting, the type of <hask>p</hask> silently became <hask>() -> IO ()</hask>. No surprise that my new "short" version of print was only capable of printing void values -<br />
<br />
<hask><br />
Prelude> p ()<br />
()<br />
Prelude> p "blah"<br />
<br />
<interactive>:1:2:<br />
Couldn't match expected type `()' against inferred type `[Char]'<br />
In the first argument of `p', namely `"blah"'<br />
In the expression: p "blah"<br />
In the definition of `it': it = p "blah"<br />
</hask><br />
<br />
----<br />
<br />
<haskell><br />
import Graphics.UI.Gtk<br />
import Graphics.UI.Gtk.Glade<br />
<br />
-- xmlGetWidget' :: WidgetClass widget => (GObject -> widget) -> String -> IO widget<br />
xmlGetWidget' = xmlGetWidget undefined<br />
<br />
main :: IO ()<br />
main<br />
= do<br />
initGUI<br />
window <- xmlGetWidget' castToWindow "window1"<br />
button <- xmlGetWidget' castToButton "button1"<br />
widgetShowAll window<br />
mainGUI<br />
</haskell><br />
<br />
If I comment main, I cannot compile this code because of the monomorphism restriction. With main, it'll infer the type:<br />
<br />
<haskell><br />
xmlGetWidget' :: (GObject -> Window) -> String -> IO Window<br />
</haskell><br />
<br />
And give me a type error in the button line. If I uncomment the type signature, it'll work.<br />
----<br />
<br />
I wasn't expecting the following to fail...<br />
<br />
<haskell><br />
square :: (Num a) => a -> a <br />
square x = x * x <br />
dx = 0.0000001<br />
deriv1 :: (Fractional a) => (a -> a) -> (a -> a)<br />
deriv1 g = (\x -> ((g (x + 2) - (g x)) / dx )) <br />
main = printf "res==%g %g\n" (square 5.12::Double) ((deriv1 square) 2::Float)<br />
</haskell><br />
<br />
and for this to work.<br />
<br />
<haskell><br />
square :: (Num a) => a -> a <br />
square x = x * x <br />
dx = 0.0000001<br />
deriv1 :: (Fractional a) => (a -> a) -> (a -> a)<br />
deriv1 g = (\x -> ((g (x + 2) - (g x)) / 0.0000001 )) <br />
main = printf "res==%g %g\n" (square 5.12::Double) ((deriv1 square) 2::Float)<br />
</haskell><br />
<br />
The fix was to add<br />
<br />
<haskell><br />
dx :: Fractional a => a<br />
</haskell><br />
<br />
--Harry<br />
<br />
----<br />
<br />
Along the same lines as Simon's question above, does anyone have any real examples of being bitten by the lack of MR? I know what it's for, but I can't really think of any realistic cases when it would be a problem. --pumpkin<br />
<br />
[[Category:Glossary]]<br />
[[Category:Language]]</div>BayleShankshttps://wiki.haskell.org/index.php?title=Web/Frameworks/HAppS&diff=22307Web/Frameworks/HAppS2008-08-08T08:20:30Z<p>BayleShanks: new page</p>
<hr />
<div>HAppS (short for Haskell Application Server) is a web framework.<br />
<br />
Features:<br />
* monadic framework for ACID transactions<br />
* an HTTP server (outperforms Apache/PHP in informal benchmarks)<br />
* SMTP server and mail delivery agent<br />
* DNS resolver in pure Haskell<br />
* XML and XSLT support. <br />
<br />
Disadvantages:<br />
* By using HAppS's state management, you are committing yourself to keeping your entire state in memory at all times, rather than disk -- YOUR STATE MUST ALWAYS FIT IN MEMORY<br />
* Nearly undocumented, rapidly changing. Since there is little documentation, you may find yourself looking at blog post tutorials, but since it is rapidly changing, about half of these tutorials are out of date.<br />
* Large set of available library functions. You don't need most of them, but because documentation is poor, it can be intimidating.<br />
<br />
Introductions to the big idea:<br />
* HAppS was inspired by Prevayler. The following excerpt from http://www.prevayler.org/wiki/ explains the big idea:<br />
<br />
"...data is kept hot in Memory with changes journaled for system recovery.<br />
<br />
Prevayler' s architecture is illustrated in the diagram shown here. Prevayler [1] serves as a transactional barrier for the business objects [2] of your application, held in Memory. You encapsulate all modifications of your business objects into instances of the Transaction interface [3], much like a " command " pattern (though different from a command in some details of the pattern). Whenever you ask Prevayler to execute a transaction on your business objects [4], Prevayler first writes the transaction object to a journal [5] so that data is not lost if your system crashes. Prevayler can also write a snapshot of your entire business object graph [6] as often as you wish. Prevayler uses the latest snapshot together with the journals to automatically recover your business objects from disk [7] on application startup by restoring the snapshot and then re-executing every transaction that was originally executed after that snapshot was taken." (see the diagram at [http://www.krasama.com/prevayler-diagram.png])<br />
<br />
* Very informative video presentation by Alex Jacobson to BayFP: http://www.bayfp.org/blog/2007/10/16/alex-jacobson-on-happs-videos-slides/<br />
<br />
Tutorials / tutorial blog posts / examples:<br />
* [[HAppS_tutorial2]]<br />
* http://softwaresimply.blogspot.com/search/label/happs<br />
* http://dbpatterson.com/articles/5<br />
* http://happs.org/HAppS/HAppS-Begin/public/<br />
* http://groups.google.com/group/HAppS/msg/7a5b25bf6b5b2285<br />
* http://www.happstutorial.com:5001/<br />
* http://src.seereason.com/happs-logon-example/<br />
<br />
Combining HAppS with other stuff:<br />
* Formlets: http://blog.tupil.com/formlets-in-haskell/<br />
* HSP: http://groups.google.com/group/HAppS/browse_thread/thread/c2f58dc5a6503bf7<br />
* Asterisk: http://nhlab.blogspot.com/2008/07/extending-asterisk-with-happs.html<br />
<br />
Websites using HAppS:<br />
* http://hpaste.org/<br />
<br />
Other lists of HAppS links:<br />
* http://www.reddit.com/r/programming/search?q=happs<br />
<br />
Old, out-of-date tutorials:<br />
* [[HAppS_tutorial]]<br />
* http://bluebones.net/2007/09/simple-haskell-web-programming-with-happs/<br />
<br />
Email list: http://groups.google.com/group/HAppS<br />
<br />
IRC logs: http://tuukka.iki.fi/tmp/logindex<br />
<br />
Some of the devs: <br />
* [http://groups.google.com/groups/profile?enc_user=vIwLsxAAAADJ_Fv0E9DM-qQqB32tBiDt Lemmih]<br />
* http://groups.google.com/groups/profile?enc_user=yBFxyxUAAAAmB_yb8VbTfVtwU9Ww1sJkfCy8ocgRtCJ7uxDEly48KQ<br />
<br />
For alternatives to HAppS, see [[Applications_and_libraries/Web_programming]].</div>BayleShankshttps://wiki.haskell.org/index.php?title=Web/Frameworks/HAppS&diff=22302Web/Frameworks/HAppS2008-08-08T07:46:17Z<p>BayleShanks: </p>
<hr />
<div>HAppS (short for Haskell Application Server) is a web framework.<br />
<br />
Features:<br />
* monadic framework for ACID transactions<br />
* an HTTP server (outperforms Apache/PHP in informal benchmarks)<br />
* SMTP server and mail delivery agent<br />
* DNS resolver in pure Haskell<br />
* XML and XSLT support. <br />
<br />
Disadvantages:<br />
* Nearly undocumented, rapidly changing. Since there is little documentation, you may find yourself looking at blog post tutorials, but since it is rapidly changing, about half of these tutorials are out of date.<br />
* Large set of available library functions. You don't need most of them, but because documentation is poor, it can be intimidating.<br />
<br />
Introductions to the big idea:<br />
* HAppS was inspired by Prevayler. The following excerpt from http://www.prevayler.org/wiki/ explains the big idea:<br />
<br />
"...data is kept hot in Memory with changes journaled for system recovery.<br />
<br />
Prevayler' s architecture is illustrated in the diagram shown here. Prevayler [1] serves as a transactional barrier for the business objects [2] of your application, held in Memory. You encapsulate all modifications of your business objects into instances of the Transaction interface [3], much like a " command " pattern (though different from a command in some details of the pattern). Whenever you ask Prevayler to execute a transaction on your business objects [4], Prevayler first writes the transaction object to a journal [5] so that data is not lost if your system crashes. Prevayler can also write a snapshot of your entire business object graph [6] as often as you wish. Prevayler uses the latest snapshot together with the journals to automatically recover your business objects from disk [7] on application startup by restoring the snapshot and then re-executing every transaction that was originally executed after that snapshot was taken." (see the diagram at [http://www.krasama.com/prevayler-diagram.png])<br />
<br />
* Very informative video presentation by Alex Jacobson to BayFP: http://www.bayfp.org/blog/2007/10/16/alex-jacobson-on-happs-videos-slides/<br />
<br />
Tutorials / tutorial blog posts / examples:<br />
* [[HAppS_tutorial2]]<br />
* http://softwaresimply.blogspot.com/search/label/happs<br />
* http://dbpatterson.com/articles/5<br />
* http://happs.org/HAppS/HAppS-Begin/public/<br />
* http://groups.google.com/group/HAppS/msg/7a5b25bf6b5b2285<br />
* http://www.happstutorial.com:5001/<br />
* http://src.seereason.com/happs-logon-example/<br />
<br />
Combining HAppS with other stuff:<br />
* Formlets: http://blog.tupil.com/formlets-in-haskell/<br />
* HSP: http://groups.google.com/group/HAppS/browse_thread/thread/c2f58dc5a6503bf7<br />
* Asterisk: http://nhlab.blogspot.com/2008/07/extending-asterisk-with-happs.html<br />
<br />
Websites using HAppS:<br />
* http://hpaste.org/<br />
<br />
Other lists of HAppS links:<br />
* http://www.reddit.com/r/programming/search?q=happs<br />
<br />
Old, out-of-date tutorials:<br />
* [[HAppS_tutorial]]<br />
* http://bluebones.net/2007/09/simple-haskell-web-programming-with-happs/<br />
<br />
Email list: http://groups.google.com/group/HAppS<br />
<br />
IRC logs: http://tuukka.iki.fi/tmp/logindex<br />
<br />
Some of the devs: <br />
* [http://groups.google.com/groups/profile?enc_user=vIwLsxAAAADJ_Fv0E9DM-qQqB32tBiDt Lemmih]<br />
* http://groups.google.com/groups/profile?enc_user=yBFxyxUAAAAmB_yb8VbTfVtwU9Ww1sJkfCy8ocgRtCJ7uxDEly48KQ<br />
<br />
For alternatives to HAppS, see [[Applications_and_libraries/Web_programming]].</div>BayleShankshttps://wiki.haskell.org/index.php?title=Web/Frameworks/HAppS&diff=22301Web/Frameworks/HAppS2008-08-08T07:45:59Z<p>BayleShanks: </p>
<hr />
<div>HAppS (short for Haskell Application Server) is a web framework.<br />
<br />
Features:<br />
* monadic framework for ACID transactions<br />
* an HTTP server (outperforms Apache/PHP in informal benchmarks)<br />
* SMTP server and mail delivery agent<br />
* DNS resolver in pure Haskell<br />
* XML and XSLT support. <br />
<br />
Disadvantages:<br />
* Nearly undocumented, rapidly changing. Since there is little documentation, you may find yourself looking at blog post tutorials, but since it is rapidly changing, about half of these tutorials are out of date.<br />
* Large set of available library functions. You don't need most of them, but because documentation is poor, it can be intimidating.<br />
<br />
Introductions to the big idea:<br />
* HAppS was inspired by Prevayler. The following excerpt from http://www.prevayler.org/wiki/ explains the big idea:<br />
<br />
"...data is kept hot in Memory with changes journaled for system recovery.<br />
<br />
Prevayler' s architecture is illustrated in the diagram shown here. Prevayler [1] serves as a transactional barrier for the business objects [2] of your application, held in Memory. You encapsulate all modifications of your business objects into instances of the Transaction interface [3], much like a " command " pattern (though different from a command in some details of the pattern). Whenever you ask Prevayler to execute a transaction on your business objects [4], Prevayler first writes the transaction object to a journal [5] so that data is not lost if your system crashes. Prevayler can also write a snapshot of your entire business object graph [6] as often as you wish. Prevayler uses the latest snapshot together with the journals to automatically recover your business objects from disk [7] on application startup by restoring the snapshot and then re-executing every transaction that was originally executed after that snapshot was taken." (see the diagram at www.krasama.com/prevayler-diagram.png )<br />
<br />
* Very informative video presentation by Alex Jacobson to BayFP: http://www.bayfp.org/blog/2007/10/16/alex-jacobson-on-happs-videos-slides/<br />
<br />
Tutorials / tutorial blog posts / examples:<br />
* [[HAppS_tutorial2]]<br />
* http://softwaresimply.blogspot.com/search/label/happs<br />
* http://dbpatterson.com/articles/5<br />
* http://happs.org/HAppS/HAppS-Begin/public/<br />
* http://groups.google.com/group/HAppS/msg/7a5b25bf6b5b2285<br />
* http://www.happstutorial.com:5001/<br />
* http://src.seereason.com/happs-logon-example/<br />
<br />
Combining HAppS with other stuff:<br />
* Formlets: http://blog.tupil.com/formlets-in-haskell/<br />
* HSP: http://groups.google.com/group/HAppS/browse_thread/thread/c2f58dc5a6503bf7<br />
* Asterisk: http://nhlab.blogspot.com/2008/07/extending-asterisk-with-happs.html<br />
<br />
Websites using HAppS:<br />
* http://hpaste.org/<br />
<br />
Other lists of HAppS links:<br />
* http://www.reddit.com/r/programming/search?q=happs<br />
<br />
Old, out-of-date tutorials:<br />
* [[HAppS_tutorial]]<br />
* http://bluebones.net/2007/09/simple-haskell-web-programming-with-happs/<br />
<br />
Email list: http://groups.google.com/group/HAppS<br />
<br />
IRC logs: http://tuukka.iki.fi/tmp/logindex<br />
<br />
Some of the devs: <br />
* [http://groups.google.com/groups/profile?enc_user=vIwLsxAAAADJ_Fv0E9DM-qQqB32tBiDt Lemmih]<br />
* http://groups.google.com/groups/profile?enc_user=yBFxyxUAAAAmB_yb8VbTfVtwU9Ww1sJkfCy8ocgRtCJ7uxDEly48KQ<br />
<br />
For alternatives to HAppS, see [[Applications_and_libraries/Web_programming]].</div>BayleShankshttps://wiki.haskell.org/index.php?title=Web/Frameworks/HAppS&diff=22300Web/Frameworks/HAppS2008-08-08T07:45:08Z<p>BayleShanks: new page</p>
<hr />
<div>HAppS (short for Haskell Application Server) is a web framework.<br />
<br />
Features:<br />
* monadic framework for ACID transactions<br />
* an HTTP server (outperforms Apache/PHP in informal benchmarks)<br />
* SMTP server and mail delivery agent<br />
* DNS resolver in pure Haskell<br />
* XML and XSLT support. <br />
<br />
Disadvantages:<br />
* Nearly undocumented, rapidly changing. Since there is little documentation, you may find yourself looking at blog post tutorials, but since it is rapidly changing, about half of these tutorials are out of date.<br />
* Large set of available library functions. You don't need most of them, but because documentation is poor, it can be intimidating.<br />
<br />
Introductions to the big idea:<br />
* HAppS was inspired by Prevayler. The following excerpt from http://www.prevayler.org/wiki/ explains the big idea:<br />
<br />
"...data is kept hot in Memory with changes journaled for system recovery.<br />
<br />
Prevayler' s architecture is illustrated in the diagram shown here. Prevayler [1] serves as a transactional barrier for the business objects [2] of your application, held in Memory. You encapsulate all modifications of your business objects into instances of the Transaction interface [3], much like a " command " pattern (though different from a command in some details of the pattern). Whenever you ask Prevayler to execute a transaction on your business objects [4], Prevayler first writes the transaction object to a journal [5] so that data is not lost if your system crashes. Prevayler can also write a snapshot of your entire business object graph [6] as often as you wish. Prevayler uses the latest snapshot together with the journals to automatically recover your business objects from disk [7] on application startup by restoring the snapshot and then re-executing every transaction that was originally executed after that snapshot was taken." http://www.krasama.com/prevayler-diagram.png<br />
<br />
* Very informative video presentation by Alex Jacobson to BayFP: http://www.bayfp.org/blog/2007/10/16/alex-jacobson-on-happs-videos-slides/<br />
<br />
Tutorials / tutorial blog posts / examples:<br />
* [[HAppS_tutorial2]]<br />
* http://softwaresimply.blogspot.com/search/label/happs<br />
* http://dbpatterson.com/articles/5<br />
* http://happs.org/HAppS/HAppS-Begin/public/<br />
* http://groups.google.com/group/HAppS/msg/7a5b25bf6b5b2285<br />
* http://www.happstutorial.com:5001/<br />
* http://src.seereason.com/happs-logon-example/<br />
<br />
Combining HAppS with other stuff:<br />
* Formlets: http://blog.tupil.com/formlets-in-haskell/<br />
* HSP: http://groups.google.com/group/HAppS/browse_thread/thread/c2f58dc5a6503bf7<br />
* Asterisk: http://nhlab.blogspot.com/2008/07/extending-asterisk-with-happs.html<br />
<br />
Websites using HAppS:<br />
* http://hpaste.org/<br />
<br />
Other lists of HAppS links:<br />
* http://www.reddit.com/r/programming/search?q=happs<br />
<br />
Old, out-of-date tutorials:<br />
* [[HAppS_tutorial]]<br />
* http://bluebones.net/2007/09/simple-haskell-web-programming-with-happs/<br />
<br />
Email list: http://groups.google.com/group/HAppS<br />
<br />
IRC logs: http://tuukka.iki.fi/tmp/logindex<br />
<br />
Some of the devs: <br />
* [http://groups.google.com/groups/profile?enc_user=vIwLsxAAAADJ_Fv0E9DM-qQqB32tBiDt Lemmih]<br />
* http://groups.google.com/groups/profile?enc_user=yBFxyxUAAAAmB_yb8VbTfVtwU9Ww1sJkfCy8ocgRtCJ7uxDEly48KQ<br />
<br />
For alternatives to HAppS, see [[Applications_and_libraries/Web_programming]].</div>BayleShankshttps://wiki.haskell.org/index.php?title=Applications_and_libraries/Web_programming&diff=22282Applications and libraries/Web programming2008-08-07T19:32:57Z<p>BayleShanks: + HAppS page</p>
<hr />
<div>Web, HTTP, HTML and XML programming.<br />
<br />
== Applications ==<br />
<br />
See also the [[Libraries_and_tools/Network|network category]].<br />
<br />
=== Haskell web applications ===<br />
<br />
;[http://hpaste.org/ hpaste: the haskell pastebin]<br />
:A pastebin site for Haskell runnning on top of [[HAppS]]. [http://www.scannedinavian.com/~eric/hpaste Source].<br />
<br />
;[http://pass.net/ pass.net]<br />
:Replaces registration, confirmation mails, and multiple passwords with a single login. at your email domain. Runs on HAppS.<br />
<br />
;[http://www.parallelnetz.de/ Parallel web]<br />
:Suggests that you travel through a parallel web with translated content. It's based on Simon Marlow's Haskell Web Server.<br />
:For Haskellers: Test the Monad Transformer in [http://saxophone.jpberlin.de/MonadTransformer?source=http://www.haskell.org/haskellwiki/Category:Monad a parallel Haskell wiki].<br />
:For Germans: Search in [http://saxophone.jpberlin.de/Saxophone?source=http://www.google.de/ Saxon dialect] or check out the [http://saxophone.jpberlin.de/Ehmulator?source=http://www.stoiber.de/ Ehmulator].<br />
:Hosted on [http://sourceforge.net/projects/parallelweb SourceForge].<br />
<br />
=== Web servers ===<br />
<br />
;[http://darcs.haskell.org/hws/ HWS]<br />
:Simon Marlow's concurrent Haskell web server<br />
<br />
;[http://www.cs.chalmers.se/~bringert/darcs/hws-cgi/ HWS with plugins]<br />
:HWS updated with plugins, flexible logging, support for listening on multiple sockets<br />
<br />
;[http://www.informatik.uni-freiburg.de/~thiemann/WASH/#wsp Wash Server Pages]<br />
:An extended version of Simon Marlow's webserver (hws) that runs WASH modules as servlets.<br />
<br />
=== Site verification ===<br />
<br />
;[http://www.dsic.upv.es/users/elp/GVerdi GVerdi]<br />
:A Rule-based System for Web site Verification<br />
<br />
=== Wikis ===<br />
<br />
;[http://www.flippac.org/projects/flippi/ Flippi]<br />
:A wiki written in Haskell<br />
<br />
;[http://pandocwiki.googlecode.com/ PandocWiki]<br />
:A simple wiki using HAppS and Pandoc<br />
<br />
;[http://latexki.nomeata.de/ latexki]<br />
:Subversion based Wiki for collaborative editing of LaTeX documents,<br />
<br />
;[http://hikij.wellquite.org/ Hikij]<br />
:A wiki written in Haskell and Javascript<br />
<br />
=== Content-management systems ===<br />
<br />
;[http://hope.bringert.net/ Hope]<br />
: An extensible Haskell content management system<br />
<br />
;[http://www.acooke.org/jara/halipeto/index.html Halipeto]<br />
:Halipeto by Andrew Cooke is a simple system for generating web pages from templates and a database. It currently only includes support for a simple database based on text files. ''Full documentation but unmaintained.''<br />
<br />
=== XML ===<br />
<br />
;[http://www.cs.york.ac.uk/fp/Xtract/ Xtract]<br />
:Xtract is a `grep'-like command-line tool for searching XML and HTML documents. Note that Xtract is now part of HaXml, listed below in Libraries.<br />
<br />
;[http://www.cse.unsw.edu.au/~chak/haskell/lambdaFeed/ lambdaFeed]<br />
:Manuel Chakravarty's RSS 2.0 feed generator. It reads news items - in a non-XML, human-friendly format - distributed over multiple channels and renders them into the RSS 2.0 XML format understood by most news aggregators as well as into HTML for inclusion into web pages.<br />
<br />
;[http://johnmacfarlane.net/pandoc/ Pandoc]<br />
:Pandoc is a Haskell library for converting from one markup format to another, and a command-line tool that uses this library. It can read markdown and (subsets of) reStructuredText, HTML, and LaTeX, and it can write markdown, reStructuredText, HTML, DocBook XML, LaTeX, ConTeXt, RTF, groff man, and S5 HTML slide shows. It also supports extensions to markdown syntax for footnotes, inline LaTeX, definition lists, strikeout, tables, and more.<br />
<br />
=== CSS ===<br />
<br />
;[http://zamez.org/factorcss Factor CSS]<br />
:This tool takes a CSS stylesheet on input and produces an almost equivalent stylesheet on output, but with rulesets split, combined, and reordered to "factor out" common declarations. This helps reveal shared components. The resulting stylesheet may also be smaller.<br />
<br />
== Libraries ==<br />
<br />
=== HTTP ===<br />
<br />
;[http://www.haskell.org/http/ HTTP and Browser Modules]<br />
:A significantly RFC compliant HTTP/1.1 client implementation. This is an updated version of [http://homepages.paradise.net.nz/warrickg/haskell/http/ Warrick Gray's original version].<br />
<br />
===AJAX===<br />
<br />
<br />
;[http://darcs.haskell.org/SoC/hsp.clientside/ HSP Clientside]<br />
:HSPClientside is a library for generating client-side scripts (in JavaScript) from [http://www.cs.chalmers.se/~d00nibro/hsp/ Haskell Server Pages] (HSP).<br />
<br />
=== Web frameworks ===<br />
<br />
;[http://happs.org/ HAppS - Haskell Application Server]<br />
:The Haskell Application Server contains a monadic framework for ACID transactions, an HTTP server (outperforms Apache/PHP in informal benchmarks), an SMTP server and mail delivery agent. A DNS resolver in pure Haskell. And XML and XSLT support. See also [[HAppS]], [[HAppS tutorial]].<br />
<br />
;[http://pass.net/s/repo Pass.Net] <br />
:Provides web sites with a simple shared web API to manage user logins, confirmation emails, forgotten passwords, etc. Most application frameworks dont have complete libraries to cover all of this functionality. Outsourcing this to Pass.net means less complexity in your application and less worrying about mail delivery, mail server integration, etc. Pass.Net is currently beta. We expect it to be fully live and reliable by the end of the year. Pass.Net is written in Haskell using HAppS and provides an easy to use Haskell library for HAppS user. Clients in python, php, and java coming soon.<br />
<br />
;[http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ WASH]<br />
:A family of combinator libraries for programming Web applications. WASH/HTML is for generating dynamic HTML documents, combining flexibility and safety. WASH/CGI is for server-side Web scripting with sessions, compositional forms, and graphics.<br />
<br />
;[http://www2-data.informatik.unibw-muenchen.de/EdComb/index.html EdComb]<br />
:Another combinator library -- for [[Libraries and tools/Editors|editors]]! But a very fruitfully general approach to the concept of ''editor'' is presented. Therefore, these editor combinators can be used also e.g. as browser combinators, with interesting new possibilities for browsers.<br />
<br />
;[http://www.cs.chalmers.se/~d00nibro/hsp Haskell Server Pages]<br />
:Using Haskell as a server-side scripting language, extended to allow embedded XML/XHTML fragments in Haskell code.<br />
<br />
;[http://darcs.haskell.org/~lemmih/hasp/ HASP]<br />
:HASP is a fork of Niklas Broberg?s Haskell Server Pages. Changes includes:<br />
* support for all GHC extensions<br />
* front-end based on FastCGI instead of its own web server<br />
* minor bug fixes and performance tuning.<br />
<br />
;[http://home.tiscali.be/stevevh/ Generative Implementation Strategies for Data-Centric Web Applications]<br />
:Generic presentation layer abstractions of administrative web applications are the central theme of this thesis. The domain-engineering approach results in a framework to support user interfaces generated from high-level descriptions. A domain-specific language describes user interfaces. The [hoyweghenSoft.zip Haskell-based generator] transforms these descriptions to user interfaces implemented with JavaScript and XHTML.<br />
<br />
;[http://www.cs.uu.nl/wiki/WebFunctions/WebHome WebFunctions]<br />
:WebFunctions is a [[EDSL]] for developing websites, implemented in Haskell. WebFunctions is a domain specific embedded language for web authoring.<br />
<br />
;[http://www.cin.ufpe.br/~haskell/hwsproxygen/ HWSProxyGen]<br />
:A web services proxy generator for the Haskell functional language, implemented in Haskell and C#. The final purpose is to show that Haskell and functional languages in general can be used as a viable way to the implementation of distributed components and applications, interacting with services implemented in different languages and/or platforms.<br />
<br />
;[[Hajax]] is a proposed tool to develop Ajax applications (stand-alone Web applications that execute into the browser environment) in Haskell.<br />
<br />
;[[Haskell_in_web_browser|Haskell Web Toolkit]] is a client-side (for programs running inside inside web browser) API layer on top of DOM, part of [[Yhc/Javascript|Yhc Javascript backend]]<br />
<br />
=== URI ===<br />
<br />
;[http://haskell.org/ghc/docs/latest/html/libraries/network/Network-URI.html Network.URI]<br />
:Included in the GHC distribution, this is very complete URI parser implementing the syntax specified by RFC3986. Based on Graham Klyne's [http://lists.w3.org/Archives/Public/uri/2003Mar/0010.html URI handling] implementation from the W3C uri mailing list, and since updated for compatibility with both GHC and Hugs. Highly recommended for parsing URLs and any other kind of URI.<br />
<br />
=== XML ===<br />
<br />
;[http://www.cs.york.ac.uk/fp/HaXml/ HaXml: utilities for using XML with Haskell]<br />
:Includes an XML parser, an HTML parser, a pretty-printer, a combinator library for generic XML transformations, and two Haskell&gt;-&lt;XML converters using type-based translation.<br />
<br />
;[http://www.fh-wedel.de/~si/HXmlToolbox/ HXT: Haskell XML Toolbox]<br />
:The Haskell XML Toolbox (HXT) bases on the ideas of HaXml and HXML, but introduces a more general approach based on arrows for processing XML with Haskell. The Haskell XML Toolbox uses a generic data model for representing XML documents, including the DTD subset and the document subset, in Haskell. It contains an XML parser, an HTML parser, namespaces are supported, XPath expressions can be used for selecting and transforming parts of a document. Validation can be performed with respect to DTDs and RelaxNG schema. A [[HXT|Getting started page]] describes the programming model behind HXT and gives some simple examples.<br />
<br />
;[http://darcs.haskell.org/wraxml WraXML]<br />
:A little wrapper to HaXML and HXT: It provides a more natural data structure for representing XML trees, and converts between HaXML or HXT and its custom tree structure. The operations on the tree need not to be of type (a -> [a]), thus using these functions is a bit more type safe. It has a custom lazy HTML parser using TagSoup and a custom lazy formatter. The library is currently much oriented to HTML rather than XML.<br />
<br />
;[http://wiki.di.uminho.pt/wiki/bin/view/PURe/2LT 2LT: Two-Level Transformation]<br />
:A two-level data transformation consists of a type-level transformation of a data format coupled with value-level transformations of data instances corresponding to that format. Examples of two-level data transformations include XML schema evolution coupled with document migration, and data mappings used for interoperability and persistence. A library of two-level transformation combinators. These combinators are used to compose transformation systems which, when applied to an input type, produce an output type, together with the conversion functions that mediate between input and out types. Front-ends for XML and SQL. These front-ends support (i) reading a schema, (ii) applying a two-level transformation system to produce a new schema, (iii) convert a document/database corresponding to the input schema to a document/database corresponding to the output schema, and vice versa. Referential constraints and primary key information are propagated through the schema transformation.<br />
<br />
;[http://www.mail-archive.com/haskell@haskell.org/msg18396.html HSXML]<br />
:A direct Haskell embedding of SXML<br />
<br />
;[http://m13s07.vlinux.de/darcs/StaticDTD/v2/ StaticDTD]<br />
:StaticDTD: complete static validness against a DTD.<br />
<br />
=== HTML ===<br />
<br />
;[http://www.cse.ogi.edu/~andy/html/intro.htm The Haskell Html Library] by Andy Gill<br />
:This library is a collection of combinators, allowing your Haskell programs to generate HTML. It is available in the standard libraries as [http://haskell.org/ghc/docs/latest/html/libraries/base/Text-Html.html Text.Html].<br />
<br />
;[http://www.haskell.org/ghc/docs/latest/html/libraries/xhtml/Text-XHtml.html XHtml library]<br />
:This is a version of [http://haskell.org/ghc/docs/latest/html/libraries/base/Text-Html.html Text.Html], modified to produce XHTML 1.0 Transitional.<br />
<br />
;[http://www.dtek.chalmers.se/~tumm/vieux/ Vieux: A Nevow implementation]<br />
:Vieux is a html-template system for Haskell. The basic idea is to define a xhtml template which is used to generate a xhtml document by Vieux.<br />
<br />
;[http://www.wellquite.org/chunks/ Text.HTML.Chunks]<br />
:Text.HTML.Chunks is a templating system inspired by the Perl HTML::Chunks module. The major change for the Haskell version is that the use of the templates is statically verified.<br />
<br />
;[http://www-users.cs.york.ac.uk/~ndm/tagsoup/ TagSoup]<br />
: TagSoup is a library for extracting information out of unstructured HTML code, sometimes known as tag-soup. The HTML does not have to be well formed, or render properly within any particular framework. This library is for situations where the author of the HTML is not cooperating with the person trying to extract the information, but is also not trying to hide the information. The library provides a basic data type for a list of unstructured tags, a parser to convert HTML into this tag type, and useful functions and combinators for finding and extracting information. <br />
<br />
=== CGI ===<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/libraries/cgi/Network-CGI.html Network.CGI]<br />
:Simple Library for writing CGI programs. This version of the library is for systems with version 2.0 or greater of the network package. This includes GHC 6.6 and later. Features include:<br />
:* Access to CGI parameters (e.g. form input) from both GET and POST requests.<br />
:* Access to CGI environment variables.<br />
:* Ability to set arbitrary response headers.<br />
:* Support for HTTP cookies.<br />
:* Efficient file upload support.<br />
:* Wrapper [http://www.haskell.org/ghc/docs/6.6/html/libraries/cgi/Network-CGI-Compat.html functions] for compatibility with the former [http://haskell.org/ghc/docs/latest/html/libraries/network/Network-CGI.html Network.CGI] module.<br />
<br />
;[http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fastcgi FastCGI library]<br />
:A library for using NewCGI programs with [http://www.fastcgi.com/ FastCGI].<br />
<br />
=== XML-RPC and CORBA ===<br />
<br />
;[http://www.haskell.org/haxr/ HaXR - the Haskell XML-RPC library]<br />
:An XML-RPC client and server library. [http://www.xmlrpc.com/ XML-RPC] is "remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned."<br />
<br />
;[http://www.dcs.shef.ac.uk/~simonf/HAIFA.html HAIFA]<br />
:HAIFA is an implementation of parts of the web-service architecture in Haskell. Notably it includes an XML serializer, a partial implementation of XML Schema and SOAP/1.1.<br />
<br />
;[http://sourceforge.net/projects/haskell-corba/ haskell-corba]<br />
:This package allows Haskell programmers to write CORBA clients and servers using the [http://www.mico.org MICO open-source CORBA implementation]. It defines a Haskell language mapping for CORBA, and includes an IDL compiler which generates Haskell stub and skeleton modules from IDL files.<br />
<br />
<br />
=== Finance ===<br />
<br />
;[http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Quote-Yahoo Finance-Quote-Yahoo]<br />
:Obtain quote data from finance.yahoo.com<br />
<br />
== See also ==<br />
<br />
* [[Practical web programming in Haskell]]<br />
* Mailing list on [http://www.haskell.org/mailman/listinfo/web-devel web development]<br />
<br />
== Hackage ==<br />
<br />
* [http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Web Web libraries on Hackage]<br />
* [http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Network Network libraries on Hackage]<br />
<br />
{{LibrariesPage}}</div>BayleShankshttps://wiki.haskell.org/index.php?title=Applications_and_libraries/Web_programming&diff=22281Applications and libraries/Web programming2008-08-07T19:32:37Z<p>BayleShanks: +HAppS page</p>
<hr />
<div>Web, HTTP, HTML and XML programming.<br />
<br />
== Applications ==<br />
<br />
See also the [[Libraries_and_tools/Network|network category]].<br />
<br />
=== Haskell web applications ===<br />
<br />
;[http://hpaste.org/ hpaste: the haskell pastebin]<br />
:A pastebin site for Haskell runnning on top of HAppS. [http://www.scannedinavian.com/~eric/hpaste Source].<br />
<br />
;[http://pass.net/ pass.net]<br />
:Replaces registration, confirmation mails, and multiple passwords with a single login. at your email domain. Runs on HAppS.<br />
<br />
;[http://www.parallelnetz.de/ Parallel web]<br />
:Suggests that you travel through a parallel web with translated content. It's based on Simon Marlow's Haskell Web Server.<br />
:For Haskellers: Test the Monad Transformer in [http://saxophone.jpberlin.de/MonadTransformer?source=http://www.haskell.org/haskellwiki/Category:Monad a parallel Haskell wiki].<br />
:For Germans: Search in [http://saxophone.jpberlin.de/Saxophone?source=http://www.google.de/ Saxon dialect] or check out the [http://saxophone.jpberlin.de/Ehmulator?source=http://www.stoiber.de/ Ehmulator].<br />
:Hosted on [http://sourceforge.net/projects/parallelweb SourceForge].<br />
<br />
=== Web servers ===<br />
<br />
;[http://darcs.haskell.org/hws/ HWS]<br />
:Simon Marlow's concurrent Haskell web server<br />
<br />
;[http://www.cs.chalmers.se/~bringert/darcs/hws-cgi/ HWS with plugins]<br />
:HWS updated with plugins, flexible logging, support for listening on multiple sockets<br />
<br />
;[http://www.informatik.uni-freiburg.de/~thiemann/WASH/#wsp Wash Server Pages]<br />
:An extended version of Simon Marlow's webserver (hws) that runs WASH modules as servlets.<br />
<br />
=== Site verification ===<br />
<br />
;[http://www.dsic.upv.es/users/elp/GVerdi GVerdi]<br />
:A Rule-based System for Web site Verification<br />
<br />
=== Wikis ===<br />
<br />
;[http://www.flippac.org/projects/flippi/ Flippi]<br />
:A wiki written in Haskell<br />
<br />
;[http://pandocwiki.googlecode.com/ PandocWiki]<br />
:A simple wiki using HAppS and Pandoc<br />
<br />
;[http://latexki.nomeata.de/ latexki]<br />
:Subversion based Wiki for collaborative editing of LaTeX documents,<br />
<br />
;[http://hikij.wellquite.org/ Hikij]<br />
:A wiki written in Haskell and Javascript<br />
<br />
=== Content-management systems ===<br />
<br />
;[http://hope.bringert.net/ Hope]<br />
: An extensible Haskell content management system<br />
<br />
;[http://www.acooke.org/jara/halipeto/index.html Halipeto]<br />
:Halipeto by Andrew Cooke is a simple system for generating web pages from templates and a database. It currently only includes support for a simple database based on text files. ''Full documentation but unmaintained.''<br />
<br />
=== XML ===<br />
<br />
;[http://www.cs.york.ac.uk/fp/Xtract/ Xtract]<br />
:Xtract is a `grep'-like command-line tool for searching XML and HTML documents. Note that Xtract is now part of HaXml, listed below in Libraries.<br />
<br />
;[http://www.cse.unsw.edu.au/~chak/haskell/lambdaFeed/ lambdaFeed]<br />
:Manuel Chakravarty's RSS 2.0 feed generator. It reads news items - in a non-XML, human-friendly format - distributed over multiple channels and renders them into the RSS 2.0 XML format understood by most news aggregators as well as into HTML for inclusion into web pages.<br />
<br />
;[http://johnmacfarlane.net/pandoc/ Pandoc]<br />
:Pandoc is a Haskell library for converting from one markup format to another, and a command-line tool that uses this library. It can read markdown and (subsets of) reStructuredText, HTML, and LaTeX, and it can write markdown, reStructuredText, HTML, DocBook XML, LaTeX, ConTeXt, RTF, groff man, and S5 HTML slide shows. It also supports extensions to markdown syntax for footnotes, inline LaTeX, definition lists, strikeout, tables, and more.<br />
<br />
=== CSS ===<br />
<br />
;[http://zamez.org/factorcss Factor CSS]<br />
:This tool takes a CSS stylesheet on input and produces an almost equivalent stylesheet on output, but with rulesets split, combined, and reordered to "factor out" common declarations. This helps reveal shared components. The resulting stylesheet may also be smaller.<br />
<br />
== Libraries ==<br />
<br />
=== HTTP ===<br />
<br />
;[http://www.haskell.org/http/ HTTP and Browser Modules]<br />
:A significantly RFC compliant HTTP/1.1 client implementation. This is an updated version of [http://homepages.paradise.net.nz/warrickg/haskell/http/ Warrick Gray's original version].<br />
<br />
===AJAX===<br />
<br />
<br />
;[http://darcs.haskell.org/SoC/hsp.clientside/ HSP Clientside]<br />
:HSPClientside is a library for generating client-side scripts (in JavaScript) from [http://www.cs.chalmers.se/~d00nibro/hsp/ Haskell Server Pages] (HSP).<br />
<br />
=== Web frameworks ===<br />
<br />
;[http://happs.org/ HAppS - Haskell Application Server]<br />
:The Haskell Application Server contains a monadic framework for ACID transactions, an HTTP server (outperforms Apache/PHP in informal benchmarks), an SMTP server and mail delivery agent. A DNS resolver in pure Haskell. And XML and XSLT support. See also [[HAppS]], [[HAppS tutorial]].<br />
<br />
;[http://pass.net/s/repo Pass.Net] <br />
:Provides web sites with a simple shared web API to manage user logins, confirmation emails, forgotten passwords, etc. Most application frameworks dont have complete libraries to cover all of this functionality. Outsourcing this to Pass.net means less complexity in your application and less worrying about mail delivery, mail server integration, etc. Pass.Net is currently beta. We expect it to be fully live and reliable by the end of the year. Pass.Net is written in Haskell using HAppS and provides an easy to use Haskell library for HAppS user. Clients in python, php, and java coming soon.<br />
<br />
;[http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ WASH]<br />
:A family of combinator libraries for programming Web applications. WASH/HTML is for generating dynamic HTML documents, combining flexibility and safety. WASH/CGI is for server-side Web scripting with sessions, compositional forms, and graphics.<br />
<br />
;[http://www2-data.informatik.unibw-muenchen.de/EdComb/index.html EdComb]<br />
:Another combinator library -- for [[Libraries and tools/Editors|editors]]! But a very fruitfully general approach to the concept of ''editor'' is presented. Therefore, these editor combinators can be used also e.g. as browser combinators, with interesting new possibilities for browsers.<br />
<br />
;[http://www.cs.chalmers.se/~d00nibro/hsp Haskell Server Pages]<br />
:Using Haskell as a server-side scripting language, extended to allow embedded XML/XHTML fragments in Haskell code.<br />
<br />
;[http://darcs.haskell.org/~lemmih/hasp/ HASP]<br />
:HASP is a fork of Niklas Broberg?s Haskell Server Pages. Changes includes:<br />
* support for all GHC extensions<br />
* front-end based on FastCGI instead of its own web server<br />
* minor bug fixes and performance tuning.<br />
<br />
;[http://home.tiscali.be/stevevh/ Generative Implementation Strategies for Data-Centric Web Applications]<br />
:Generic presentation layer abstractions of administrative web applications are the central theme of this thesis. The domain-engineering approach results in a framework to support user interfaces generated from high-level descriptions. A domain-specific language describes user interfaces. The [hoyweghenSoft.zip Haskell-based generator] transforms these descriptions to user interfaces implemented with JavaScript and XHTML.<br />
<br />
;[http://www.cs.uu.nl/wiki/WebFunctions/WebHome WebFunctions]<br />
:WebFunctions is a [[EDSL]] for developing websites, implemented in Haskell. WebFunctions is a domain specific embedded language for web authoring.<br />
<br />
;[http://www.cin.ufpe.br/~haskell/hwsproxygen/ HWSProxyGen]<br />
:A web services proxy generator for the Haskell functional language, implemented in Haskell and C#. The final purpose is to show that Haskell and functional languages in general can be used as a viable way to the implementation of distributed components and applications, interacting with services implemented in different languages and/or platforms.<br />
<br />
;[[Hajax]] is a proposed tool to develop Ajax applications (stand-alone Web applications that execute into the browser environment) in Haskell.<br />
<br />
;[[Haskell_in_web_browser|Haskell Web Toolkit]] is a client-side (for programs running inside inside web browser) API layer on top of DOM, part of [[Yhc/Javascript|Yhc Javascript backend]]<br />
<br />
=== URI ===<br />
<br />
;[http://haskell.org/ghc/docs/latest/html/libraries/network/Network-URI.html Network.URI]<br />
:Included in the GHC distribution, this is very complete URI parser implementing the syntax specified by RFC3986. Based on Graham Klyne's [http://lists.w3.org/Archives/Public/uri/2003Mar/0010.html URI handling] implementation from the W3C uri mailing list, and since updated for compatibility with both GHC and Hugs. Highly recommended for parsing URLs and any other kind of URI.<br />
<br />
=== XML ===<br />
<br />
;[http://www.cs.york.ac.uk/fp/HaXml/ HaXml: utilities for using XML with Haskell]<br />
:Includes an XML parser, an HTML parser, a pretty-printer, a combinator library for generic XML transformations, and two Haskell&gt;-&lt;XML converters using type-based translation.<br />
<br />
;[http://www.fh-wedel.de/~si/HXmlToolbox/ HXT: Haskell XML Toolbox]<br />
:The Haskell XML Toolbox (HXT) bases on the ideas of HaXml and HXML, but introduces a more general approach based on arrows for processing XML with Haskell. The Haskell XML Toolbox uses a generic data model for representing XML documents, including the DTD subset and the document subset, in Haskell. It contains an XML parser, an HTML parser, namespaces are supported, XPath expressions can be used for selecting and transforming parts of a document. Validation can be performed with respect to DTDs and RelaxNG schema. A [[HXT|Getting started page]] describes the programming model behind HXT and gives some simple examples.<br />
<br />
;[http://darcs.haskell.org/wraxml WraXML]<br />
:A little wrapper to HaXML and HXT: It provides a more natural data structure for representing XML trees, and converts between HaXML or HXT and its custom tree structure. The operations on the tree need not to be of type (a -> [a]), thus using these functions is a bit more type safe. It has a custom lazy HTML parser using TagSoup and a custom lazy formatter. The library is currently much oriented to HTML rather than XML.<br />
<br />
;[http://wiki.di.uminho.pt/wiki/bin/view/PURe/2LT 2LT: Two-Level Transformation]<br />
:A two-level data transformation consists of a type-level transformation of a data format coupled with value-level transformations of data instances corresponding to that format. Examples of two-level data transformations include XML schema evolution coupled with document migration, and data mappings used for interoperability and persistence. A library of two-level transformation combinators. These combinators are used to compose transformation systems which, when applied to an input type, produce an output type, together with the conversion functions that mediate between input and out types. Front-ends for XML and SQL. These front-ends support (i) reading a schema, (ii) applying a two-level transformation system to produce a new schema, (iii) convert a document/database corresponding to the input schema to a document/database corresponding to the output schema, and vice versa. Referential constraints and primary key information are propagated through the schema transformation.<br />
<br />
;[http://www.mail-archive.com/haskell@haskell.org/msg18396.html HSXML]<br />
:A direct Haskell embedding of SXML<br />
<br />
;[http://m13s07.vlinux.de/darcs/StaticDTD/v2/ StaticDTD]<br />
:StaticDTD: complete static validness against a DTD.<br />
<br />
=== HTML ===<br />
<br />
;[http://www.cse.ogi.edu/~andy/html/intro.htm The Haskell Html Library] by Andy Gill<br />
:This library is a collection of combinators, allowing your Haskell programs to generate HTML. It is available in the standard libraries as [http://haskell.org/ghc/docs/latest/html/libraries/base/Text-Html.html Text.Html].<br />
<br />
;[http://www.haskell.org/ghc/docs/latest/html/libraries/xhtml/Text-XHtml.html XHtml library]<br />
:This is a version of [http://haskell.org/ghc/docs/latest/html/libraries/base/Text-Html.html Text.Html], modified to produce XHTML 1.0 Transitional.<br />
<br />
;[http://www.dtek.chalmers.se/~tumm/vieux/ Vieux: A Nevow implementation]<br />
:Vieux is a html-template system for Haskell. The basic idea is to define a xhtml template which is used to generate a xhtml document by Vieux.<br />
<br />
;[http://www.wellquite.org/chunks/ Text.HTML.Chunks]<br />
:Text.HTML.Chunks is a templating system inspired by the Perl HTML::Chunks module. The major change for the Haskell version is that the use of the templates is statically verified.<br />
<br />
;[http://www-users.cs.york.ac.uk/~ndm/tagsoup/ TagSoup]<br />
: TagSoup is a library for extracting information out of unstructured HTML code, sometimes known as tag-soup. The HTML does not have to be well formed, or render properly within any particular framework. This library is for situations where the author of the HTML is not cooperating with the person trying to extract the information, but is also not trying to hide the information. The library provides a basic data type for a list of unstructured tags, a parser to convert HTML into this tag type, and useful functions and combinators for finding and extracting information. <br />
<br />
=== CGI ===<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/libraries/cgi/Network-CGI.html Network.CGI]<br />
:Simple Library for writing CGI programs. This version of the library is for systems with version 2.0 or greater of the network package. This includes GHC 6.6 and later. Features include:<br />
:* Access to CGI parameters (e.g. form input) from both GET and POST requests.<br />
:* Access to CGI environment variables.<br />
:* Ability to set arbitrary response headers.<br />
:* Support for HTTP cookies.<br />
:* Efficient file upload support.<br />
:* Wrapper [http://www.haskell.org/ghc/docs/6.6/html/libraries/cgi/Network-CGI-Compat.html functions] for compatibility with the former [http://haskell.org/ghc/docs/latest/html/libraries/network/Network-CGI.html Network.CGI] module.<br />
<br />
;[http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fastcgi FastCGI library]<br />
:A library for using NewCGI programs with [http://www.fastcgi.com/ FastCGI].<br />
<br />
=== XML-RPC and CORBA ===<br />
<br />
;[http://www.haskell.org/haxr/ HaXR - the Haskell XML-RPC library]<br />
:An XML-RPC client and server library. [http://www.xmlrpc.com/ XML-RPC] is "remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned."<br />
<br />
;[http://www.dcs.shef.ac.uk/~simonf/HAIFA.html HAIFA]<br />
:HAIFA is an implementation of parts of the web-service architecture in Haskell. Notably it includes an XML serializer, a partial implementation of XML Schema and SOAP/1.1.<br />
<br />
;[http://sourceforge.net/projects/haskell-corba/ haskell-corba]<br />
:This package allows Haskell programmers to write CORBA clients and servers using the [http://www.mico.org MICO open-source CORBA implementation]. It defines a Haskell language mapping for CORBA, and includes an IDL compiler which generates Haskell stub and skeleton modules from IDL files.<br />
<br />
<br />
=== Finance ===<br />
<br />
;[http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Quote-Yahoo Finance-Quote-Yahoo]<br />
:Obtain quote data from finance.yahoo.com<br />
<br />
== See also ==<br />
<br />
* [[Practical web programming in Haskell]]<br />
* Mailing list on [http://www.haskell.org/mailman/listinfo/web-devel web development]<br />
<br />
== Hackage ==<br />
<br />
* [http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Web Web libraries on Hackage]<br />
* [http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Network Network libraries on Hackage]<br />
<br />
{{LibrariesPage}}</div>BayleShankshttps://wiki.haskell.org/index.php?title=Tutorials&diff=18276Tutorials2008-01-13T10:52:59Z<p>BayleShanks: + cs.wwc.edu/KU/PR/Haskell.html</p>
<hr />
<div>==Introductions to Haskell==<br />
<br />
These are the recommended places to start learning, short of buying a textbook.<br />
<br />
=== Best places to start ===<br />
<br />
;[http://darcs.haskell.org/yaht/yaht.pdf Yet Another Haskell Tutorial]<br />
:By Hal Daume III et al. A recommended tutorial for Haskell that is still under construction but covers already much ground. Also a classic text. Now available [http://en.wikibooks.org/wiki/Haskell/YAHT as a wikibook].<br />
<br />
;[http://en.wikibooks.org/wiki/Haskell Haskell Wikibook] <br />
:A communal effort by several authors to produce the definitive Haskell textbook. Its very much a work in progress at the moment, and contributions are welcome.<br />
<br />
;[http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutorial/overview.html Write Yourself a Scheme in 48 Hours in Haskell]<br />
:A Haskell Tutorial, by Jonathan Tang. Most Haskell tutorials on the web seem to take a language-reference-manual approach to teaching. They show you the syntax of the language, a few language constructs, and then have you construct a few simple functions at the interactive prompt. The "hard stuff" of how to write a functioning, useful program is left to the end, or sometimes omitted entirely. This tutorial takes a different tack. You'll start off with command-line arguments and parsing, and progress to writing a fully-functional Scheme interpreter that implements a good-sized subset of R5RS Scheme. Along the way, you'll learn Haskell's I/O, mutable state, dynamic typing, error handling, and parsing features. By the time you finish, you should be fairly fluent in both Haskell and Scheme.<br />
<br />
=== More tutorials ===<br />
<br />
;[http://www.haskell.org/tutorial/ A Gentle Introduction to Haskell] :By Paul Hudak, John Peterson, and Joseph H. Fasel. The title is misleading. Some knowledge of another functional programming language is expected. The emphasis is on the type system and those features which are really new in Haskell (compared to other functional programming languages). A classic, but not for the faint of heart (it's not so gentle). Also available in [http://gorgonite.developpez.com/livres/traductions/haskell/gentle-haskell/ French] and [http://www.rsdn.ru/article/haskell/haskell_part1.xml Russian].<br />
<br />
;[[H-99: Ninety-Nine Haskell Problems]]<br />
:A collection of programming puzzles, with Haskell solutions. Solving these is a great way to get into Haskell programming.<br />
<br />
;[http://www.haskell.org/~pairwise/intro/intro.html Haskell Tutorial for C Programmers]<br />
:By Eric Etheridge. From the intro: "This tutorial assumes that the reader is familiar with C/C++, Python, Java, or Pascal. I am writing for you because it seems that no other tutorial was written to help students overcome the difficulty of moving from C/C++, Java, and the like to Haskell."<br />
<br />
;[http://www-106.ibm.com/developerworks/edu/os-dw-linuxhask-i.html Beginning Haskell] <br />
:From IBM developerWorks. This tutorial targets programmers of imperative languages wanting to learn about functional programming in the language Haskell. If you have programmed in languages such as C, Pascal, Fortran, C++, Java, Cobol, Ada, Perl, TCL, REXX, JavaScript, Visual Basic, or many others, you have been using an imperative paradigm. This tutorial provides a gentle introduction to the paradigm of functional programming, with specific illustrations in the Haskell 98 language. (Free registration required.)<br />
<br />
;[http://www.informatik.uni-bonn.de/~ralf/teaching/Hskurs_toc.html Online Haskell Course] <br />
:By Ralf Hinze (in German).<br />
<br />
;[http://www.cs.chalmers.se/~rjmh/tutorials.html Tutorial Papers in Functional Programming].<br />
:A collection of links to other Haskell tutorials, from John Hughes.<br />
<br />
;[http://www.cs.ou.edu/cs1323h/textbook/haskell.shtml Two Dozen Short Lessons in Haskell] <br />
:By Rex Page. A draft of a textbook on functional programming, available by ftp. It calls for active participation from readers by omitting material at certain points and asking the reader to attempt to fill in the missing information based on knowledge they have already acquired. The missing information is then supplied on the reverse side of the page. <br />
<br />
;[ftp://ftp.geoinfo.tuwien.ac.at/navratil/HaskellTutorial.pdf Haskell-Tutorial] <br />
:By Damir Medak and Gerhard Navratil. The fundamentals of functional languages for beginners. <br />
<br />
;[http://video.s-inf.de/#FP.2005-SS-Giesl.(COt).HD_Videoaufzeichnung Video Lectures] <br />
:Lectures (in English) by Jürgen Giesl. About 30 hours in total, and great for learning Haskell. The lectures are 2005-SS-FP.V01 through 2005-SS-FP.V26. Videos 2005-SS-FP.U01 through 2005-SS-FP.U11 are exercise answer sessions, so you probably don't want those.<br />
<br />
;[http://www.cs.utoronto.ca/~trebla/fp/ Albert's Functional Programming Course] <br />
:A 15 lesson introduction to most aspects of Haskell.<br />
<br />
;[http://www.iceteks.com/articles.php/haskell/1 Introduction to Haskell]<br />
:By Chris Dutton, An "attempt to bring the ideas of functional programming to the masses here, and an experiment in finding ways to make it easy and interesting to follow".<br />
<br />
;[http://www.csc.depauw.edu/~bhoward/courses/0203Spring/csc122/haskintro/ An Introduction to Haskell]<br />
:A brief introduction, by Brian Howard.<br />
<br />
;[http://web.syntaxpolice.org/lectures/haskellTalk/slides/index.html Introduction to Haskell]<br />
:By Isaac Jones (2003).<br />
<br />
;[http://www.linuxjournal.com/article/9096 Translating Haskell into English]<br />
:By Shannon Behrens, a glimpse of the Zen of Haskell, without requiring that they already be Haskell converts.<br />
<br />
;[http://www.shlomifish.org/lecture/Perl/Haskell/slides/ Haskell for Perl Programmers]<br />
:Brief introduction to Haskell, with a view to what perl programmers are interested in<br />
<br />
;[http://lisperati.com/haskell/ How To Organize a Picnic on a Computer]<br />
:Fun introduction to Haskell, step by step building of a program to seat people at a planned picnic, based on their similarities using data from a survey and a map of the picnic location.<br />
<br />
;[http://cs.wwc.edu/KU/PR/Haskell.html Haskell Tutorial]<br />
<br />
<br />
== Motivation for using Haskell ==<br />
<br />
;[http://www.md.chalmers.se/~rjmh/Papers/whyfp.html Why Functional Programming Matters] <br />
:By [http://www.md.chalmers.se/~rjmh/ John Hughes], The Computer Journal, Vol. 32, No. 2, 1989, pp. 98 - 107. Also in: David A. Turner (ed.): Research Topics in Functional Programming, Addison-Wesley, 1990, pp. 17 - 42.<BR> Exposes the advantages of functional programming languages. Demonstrates how higher-order functions and lazy evaluation enable new forms of modularization of programs.<br />
<br />
;[[Why Haskell matters]] <br />
:Discussion of the advantages of using Haskell in particular. An excellent article.<br />
<br />
;[http://www.cs.ukc.ac.uk/pubs/1997/224/index.html Higher-order + Polymorphic = Reusable] <br />
:By [http://www.cs.ukc.ac.uk/people/staff/sjt/index.html Simon Thompson]. Unpublished, May 1997.<BR> <STRONG>Abstract:</STRONG> This paper explores how certain ideas in object oriented languages have their correspondents in functional languages. In particular we look at the analogue of the iterators of the C++ standard template library. We also give an example of the use of constructor classes which feature in Haskell 1.3 and Gofer.<br />
<br />
;[http://www-128.ibm.com/developerworks/java/library/j-cb07186.html Explore functional programming with Haskell]<br />
:Introduction to the benefits of functional programming in Haskell by Bruce Tate.<br />
<br />
== Blog articles ==<br />
<br />
There are a large number of tutorials covering diverse Haskell topics<br />
published as blogs. Some of the best of these articles are collected<br />
here:<br />
<br />
;[[Blog articles]]<br />
<br />
==Practical Haskell==<br />
<br />
These tutorials examine using Haskell to writing complex real-world applications<br />
<br />
;[http://research.microsoft.com/%7Esimonpj/Papers/marktoberdorf Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell]<br />
:Simon Peyton Jones. Presented at the 2000 Marktoberdorf Summer School. In "Engineering theories of software construction", ed Tony Hoare, Manfred Broy, Ralf Steinbruggen, IOS Press, ISBN 1-58603-1724, 2001, pp47-96. The standard reference for monadic IO in GHC/Haskell. <br><strong>Abstract:</strong>Functional programming may be beautiful, but to write real applications we must grapple with awkward real-world issues: input/output, robustness, concurrency, and interfacing to programs written in other languages.<br />
<br />
;[[Hitchhikers Guide to the Haskell]]<br />
: Tutorial for C/Java/OCaml/... programers by Dmitry Astapov. From the intro: "This text intends to introduce the reader to the practical aspects of Haskell from the very beginning (plans for the first chapters include: I/O, darcs, Parsec, QuickCheck, profiling and debugging, to mention a few)".<br />
<br />
;[http://haskell.org/haskellwiki/IO_inside Haskell I/O inside: Down the Rabbit's Hole]<br />
:By Bulat Ziganshin (2006), a comprehensive tutorial on using IO monad.<br />
<br />
;[http://web.archive.org/web/20060622030538/http://www.reid-consulting-uk.ltd.uk/docs/ffi.html A Guide to Haskell's Foreign Function Interface]<br />
:A guide to using the foreign function interface extension, using the rich set of functions in the Foreign libraries, design issues, and FFI preprocessors.<br />
<br />
;[http://blogs.nubgames.com/code/?p=22 Haskell IO for imperative programmers]<br />
:A short introduction to IO from the perspective of an imperative programmer.<br />
<br />
;[[A brief introduction to Haskell|A Brief Introduction to Haskell]]<br />
:A translation of the article, [http://www.cs.jhu.edu/~scott/pl/lectures/caml-intro.html Introduction to OCaml], to Haskell.<br />
<br />
;[[Roll your own IRC bot]]<br />
:This tutorial is designed as a practical guide to writing real world code in Haskell and hopes to intuitively motivate and introduce some of the advanced features of Haskell to the novice programmer, including monad transformers. Our goal is to write a concise, robust and elegant IRC bot in Haskell.<br />
<br />
;[http://j-van-thiel.speedlinq.nl/EddyAhmed/GladeGtk2Hs.html Developing Gnome Apps with Glade]<br />
:For the absolute beginner in both Glade and Gtk2Hs and covers the basics of Glade and how to access a .glade file and widgets in Gtk2Hs. Estimated learning time: 2 hours.<br />
<br />
;Applications of Functional Programming<br />
:Colin Runciman and David Wakeling (ed.), UCL Press, 1995, ISBN 1-85728-377-5 HB. From the cover:<blockquote>This book is unique in showcasing real, non-trivial applications of functional programming using the Haskell language. It presents state-of-the-art work from the FLARE project and will be an invaluable resource for advanced study, research and implementation.</blockquote><br />
<br />
===Testing===<br />
<br />
;[http://blog.moertel.com/articles/2006/10/31/introductory-haskell-solving-the-sorting-it-out-kata Small overview of QuickCheck]<br />
<br />
;[[Introduction to QuickCheck]]<br />
<br />
==Reference material==<br />
<br />
;[http://haskell.org/haskellwiki/Category:Tutorials A growing list of Haskell tutorials on a diverse range of topics]<br />
:Available on this wiki<br />
<br />
;[http://undergraduate.csse.uwa.edu.au/units/230.301/lectureNotes/tourofprelude.html A Tour of the Haskell Prelude (basic functions)] <br />
:By Bernie Pope and Arjan van IJzendoorn.<br />
<br />
;[http://cs.anu.edu.au/Student/comp1100/haskell/tourofsyntax.html Tour of the Haskell Syntax] <br />
:By Arjan van IJzendoorn.<br />
<br />
;[http://zvon.org/other/haskell/Outputglobal/index.html Haskell Reference] <br />
:By Miloslav Nic.<br />
<br />
;[http://members.chello.nl/hjgtuyl/tourdemonad.html A tour of the Haskell Monad functions]<br />
:By Henk-Jan van Tuyl.<br />
<br />
;[http://www.cse.unsw.edu.au/~en1000/haskell/inbuilt.html Useful Haskell functions]<br />
:An explanation for beginners of many Haskell functions that are predefined in the Haskell Prelude.<br />
<br />
;[http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/ Haskell's Standard List Functions]<br />
:A tour of the standard Haskell functions, directed by what you want to achieve<br />
<br />
;[http://haskell.org/ghc/docs/latest/html/libraries/ Documentation for the standard libraries]<br />
:Complete documentation of the standard Haskell libraries.<br />
<br />
;[http://www.haskell.org/haskellwiki/Category:Idioms Haskell idioms]<br />
:A collection of articles describing some common Haskell idioms. Often quite advanced.<br />
<br />
;[http://www.haskell.org/haskellwiki/Blow_your_mind Useful idioms]<br />
:A collection of short, useful Haskell idioms.<br />
<br />
;[http://www.haskell.org/haskellwiki/Programming_guidelines Programming guidelines]<br />
:Some Haskell programming and style conventions.<br />
<br />
;[http://www.md.chalmers.se/~rjmh/Combinators/LightningTour/index.htm Lightning Tour of Haskell]<br />
:By John Hughes, as part of a Chalmers programming course<br />
<br />
;[http://www.cs.chalmers.se/~augustss/AFP/manuals/haskeller.dvi.gz The Little Haskeller] <br />
:By Cordelia Hall and John Hughes. 9. November 1993, 26 pages. An introduction using the Chalmers Haskell B interpreter (hbi). Beware that it relies very much on the user interface of hbi which is quite different for other Haskell systems, and the tutorials cover Haskell 1.2 , not Haskell 98.<br />
<br />
;[http://www.cs.uu.nl/people/jeroen/courses/fp-eng.pdf Functional Programming]<br />
:By Jeroen Fokker, 1995. (153 pages, 600 KB). Textbook for learning functional programming with Gofer (an older implementation of Haskell). Here without Chapters&nbsp;6 and&nbsp;7.<br />
<br />
== Comparisons to other languages ==<br />
<br />
Articles constrasting feature of Haskell with other languages.<br />
<br />
;[http://programming.reddit.com/goto?id=nq1k Haskell versus Scheme]<br />
:Mark C. Chu-Carroll, Haskell and Scheme: Which One and Why?<br />
<br />
;[http://wiki.python.org/moin/PythonVsHaskell Comparing Haskell and Python]<br />
:A short overview of similarities and differences between Haskell and Python.<br />
<br />
;[http://programming.reddit.com/goto?id=nwm2 Monads in OCaml]<br />
:Syntax extension for monads in OCaml<br />
<br />
;[http://www.shlomifish.org/lecture/Perl/Haskell/slides/ Haskell for Perl programmers]<br />
:Short intro for perlers<br />
<br />
;[[A_brief_introduction_to_Haskell|Introduction to Haskell]] versus [http://www.cs.jhu.edu/~scott/pl/lectures/caml-intro.html Introduction to OCaml].<br />
<br />
;[http://www.thaiopensource.com/relaxng/derivative.html An algorithm for RELAX NG validation]<br />
:by James Clark (of RELAX NG fame). Describes an algorithm for validating an XML document against a RELAX NG schema, uses Haskell to describe the algorithm. The algorithm in Haskell and Java is then [http://www.donhopkins.com/drupal/node/117 discussed here].<br />
<br />
;[http://mult.ifario.us/articles/2006/10/11/first-steps-with-haskell-for-web-applications Haskell + FastCGI versus Ruby on Rails]<br />
:A short blog entry documenting performance results with ruby on rails and Haskell with fastcgi<br />
<br />
;[http://haskell.org/papers/NSWC/jfp.ps Haskell vs. Ada vs. C++ vs. Awk vs. ..., An Experiment in Software Prototyping Productivity] (postscript)<br />
:Paul Hudak and Mark P. Jones, 16 pages.<blockquote>Description of the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center requirement for Geometric Region Servers. The resulting programs and development metrics were reviewed by a committee chosen by the US Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++. </blockquote> <br />
<br />
;[http://www.osl.iu.edu/publications/prints/2003/comparing_generic_programming03.pdf A Comparative Study of Language Support for Generic Programming] (pdf)<br />
:Ronald Garcia, Jaakko Jrvi, Andrew Lumsdaine, Jeremy G. Siek, and Jeremiah Willcock. In Proceedings of the 2003 ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA'03), October 2003.<blockquote>An interesting comparison of generic programming support across languages, including: Haskell, SML, C++, Java, C#. Haskell supports all constructs described in the paper -- the only language to do so. </blockquote><br />
<br />
;[http://homepages.inf.ed.ac.uk/wadler/realworld/index.html Functional Programming in the Real World]<br />
:A list of functional programs applied to real-world tasks. The main criterion for being real-world is that the program was written primarily to perform some task, not primarily to experiment with functional programming. Functional is used in the broad sense that includes both `pure' programs (no side effects) and `impure' (some use of side effects). Languages covered include CAML, Clean, Erlang, Haskell, Miranda, Scheme, SML, and others.<br />
<br />
;[http://www.defmacro.org/ramblings/lisp-in-haskell.html Lisp in Haskell]<br />
:Writing A Lisp Interpreter In Haskell, a tutorial<br />
<br />
== Teaching Haskell ==<br />
<br />
;[http://www.cs.ukc.ac.uk/pubs/1997/208/index.html Where do I begin? A problem solving approach to teaching functional programming]<br />
:By [http://www.cs.ukc.ac.uk/people/staff/sjt/index.html Simon Thompson]. In Krzysztof Apt, Pieter Hartel, and Paul Klint, editors, First International Conference on Declarative Programming Languages in Education. Springer-Verlag, September 1997. <br> <STRONG>Abstract:</STRONG> This paper introduces a problem solving method for teaching functional programming, based on Polya's `How To Solve It', an introductory investigation of mathematical method. We first present the language independent version, and then show in particular how it applies to the development of programs in Haskell. The method is illustrated by a sequence of examples and a larger case study. <br />
<br />
;[http://www.cs.ukc.ac.uk/pubs/1995/214/index.html Functional programming through the curriculum]<br />
:By [http://www.cs.ukc.ac.uk/people/staff/sjt/index.html Simon Thompson] and Steve Hill. In Pieter H. Hartel and Rinus Plasmeijer, editors, Functional Programming Languages in Education, LNCS 1022, pages 85-102. Springer-Verlag, December 1995. <br> <STRONG>Abstract:</STRONG> This paper discusses our experience in using a functional language in topics across the computer science curriculum. After examining the arguments for taking a functional approach, we look in detail at four case studies from different areas: programming language semantics, machine architectures, graphics and formal languages. <br />
<br />
;[http://www.cse.unsw.edu.au/~chak/papers/CK02a.html The Risks and Benefits of Teaching Purely Functional Programming in First Year]<br />
:By [http://www.cse.unsw.edu.au/~chak Manuel M. T. Chakravarty] and [http://www.cse.unsw.edu.au/~keller Gabriele Keller]. Journal of Functional Programming 14(1), pp 113-123, 2004. An earlier version of this paper was presented at Functional and Declarative Programming in Education (FDPE02). <br> <strong>Abstract</strong> We argue that teaching purely functional programming as such in freshman courses is detrimental to both the curriculum as well as to promoting the paradigm. Instead, we need to focus on the more general aims of teaching elementary techniques of programming and essential concepts of computing. We support this viewpoint with experience gained during several semesters of teaching large first-year classes (up to 600 students) in Haskell. These classes consisted of computer science students as well as students from other disciplines. We have systematically gathered student feedback by conducting surveys after each semester. This article contributes an approach to the use of modern functional languages in first year courses and, based on this, advocates the use of functional languages in this setting.<br />
<br />
<br />
==Using monads==<br />
<br />
See also the [[Monad]] HaskellWiki page.<br />
<br />
<br />
===Recommended tutorials===<br />
<br />
;[http://www.haskell.org/all_about_monads/html/index.html All About Monads] <br />
:By Jeff Newbern. This tutorial aims to explain the concept of a monad and its application to functional programming in a way that is easy to understand and useful to beginning and intermediate Haskell programmers. Familiarity with the Haskell language is assumed, but no prior experience with monads is required. <br />
<br />
;[[Monads as computation]]<br />
:A tutorial which gives a broad overview to motivate the use of monads as an abstraction in functional programming and describe their basic features. It makes an attempt at showing why they arise naturally from some basic premises about the design of a library.<br />
<br />
;[[Monads as containers]]<br />
:A tutorial describing monads from a rather different perspective: as an abstraction of container-types, rather than an abstraction of types of computation.<br />
<br />
;[http://uebb.cs.tu-berlin.de/~magr/pub/Transformers.en.html Monad Transformers Step by Step]<br />
:By Martin Grabm&uuml;ller. A small tutorial on using monad transformers. In contrast to others found on the web, it concentrates on using them, not on their implementation.<br />
<br />
===Parser===<br />
<br />
;[http://www.haskell.org/sitewiki/images/c/c6/ICMI45-paper-en.pdf The Parser monad and other monad (i.e. a monad with state and I/O string)]. <br />
:The parser monad is used to build modular, flexible, parsers. <br />
<br />
;[http://www.haskell.org/sitewiki/images/c/c6/ICMI45-paper-en.pdf How to build a monadic interpreter in one day] (pdf)<br />
:By Dan Popa. A small tutorial on how to build a language in one day, using the Parser Monad in the front end and a monad with state and I/O string in the back end. Read it if you are interested in learning: <br />
:# language construction and <br />
:# interpreter construction<br />
<br />
===More tutorials===<br />
<br />
;[http://stefan-klinger.de/files/monadGuide.pdf The Haskell Programmer's Guide to the IO Monad - Don't Panic.] <br />
:By Stefan Klinger. This report scratches the surface of category theory, an abstract branch of algebra, just deep enough to find the monad structure. It seems well written.<br />
<br />
;[http://www.prairienet.org/~dsb/monads.htm A (hopefully) painless introduction to monads] <br />
:By Dan Bensen. A straightforward beginner's guide with intuitive explanations and examples.<br />
<br />
;[http://www-users.mat.uni.torun.pl/~fly/materialy/fp/haskell-doc/Monads.html What the hell are Monads?] <br />
:By Noel Winstanley. A basic introduction to monads, monadic programming and IO. This introduction is presented by means of examples rather than theory, and assumes a little knowledge of Haskell. <br />
<br />
;[http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm Monads for the Working Haskell Programmer -- a short tutorial]<br />
:By Theodore Norvell. <br />
<br />
;[http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads! (And Maybe You Already Have.)]<br />
:A short tutorial on monads, introduced from a pragmatic approach, with less category theory references <br />
<br />
;[http://www.cs.chalmers.se/~augustss/AFP/monads.html Systematic Design of Monads]<br />
:By John Hughes and Magnus Carlsson. Many useful monads can be designed in a systematic way, by successively adding facilities to a trivial monad. The capabilities that can be added in this way include state, exceptions, backtracking, and output. Here we give a brief description of the trivial monad, each kind of extension, and sketches of some interesting operations that each monad supports.<br />
<br />
;[[Meet Bob The Monadic Lover]]<br />
:By Andrea Rossato. A by-the-author-supposed-to-be funny and short introduction to Monads, with code but without any reference to category theory: what monads look like and what they are useful for, from the perspective of a ... lover. (There is also the slightly more serious [[The Monadic Way]] by the same author.)<br />
<br />
;[http://www.haskell.org/pipermail/haskell-cafe/2006-November/019190.html Monstrous Monads]<br />
:Andrew Pimlott's humourous introduction to monads, using the metaphor of "monsters".<br />
<br />
;Computational monads [http://programming.reddit.com/info/ox6s/comments/coxiv part 1] and [http://programming.reddit.com/info/ox6s/comments/coxoh part 2].<br />
<br />
;[http://www.loria.fr/~kow/monads/index.html Of monads and space suits]<br />
:By Eric Kow.<br />
<br />
;[[The Monadic Way]]<br />
<br />
;Computational monads [http://programming.reddit.com/info/ox6s/comments/coxiv part 1] and [http://programming.reddit.com/info/ox6s/comments/coxoh part 2].<br />
<br />
;[http://www.alpheccar.org/fr/posts/show/60 Three kind of monads] : sequencing, side effects or containers<br />
<br />
;[[Simple monad examples]]<br />
<br />
;[http://en.wikipedia.org/wiki/Monads_in_functional_programming Article on monads on Wikipedia]<br />
<br />
;[[IO inside]] page<br />
:Explains why I/O in Haskell is implemented with a monad.<br />
<br />
;[http://haskell.org/haskellwiki/Blog_articles#Monads Blog articles]<br />
<br />
See also [[Research papers/Monads and arrows]]<br />
<br />
==Workshops on advanced functional programming==<br />
<br />
;[http://compilers.iecc.com/comparch/article/95-04-024 Advanced Functional Programming: 1st International Spring School on Advanced Functional Programming Techniques], Bastad, Sweden, May 24 - 30, 1995. Tutorial Text (Lecture Notes in Computer Science) <br />
<br />
;[http://www.cse.ogi.edu/PacSoft/conf/summerschool96.html Advanced Functional Programming: 2nd International School], Olympia, Wa, Usa, August 26-30, 1996 Tutorial Text (Lecture Notes in Computer Science) <br />
<br />
;[http://alfa.di.uminho.pt/~afp98/ Advanced Functional Programming: 3rd International School], AFP'98, Braga, Portugal, September 12-19, 1998, Revised Lectures (Lecture Notes in Computer Science) <br />
<br />
;[http://www.cs.uu.nl/~johanj/afp/afp4/ Advanced Functional Programming: 4th International School], AFP 2002, Oxford, UK, August 19-24, 2002, Revised Lectures (Lecture Notes in Computer Science) <br />
<br />
;[http://www.cs.ut.ee/afp04/ Advanced Functional Programming: 5th International School], AFP 2004, Tartu, Estonia, August 14-21, 2004, Revised Lectures (Lecture Notes in Computer Science) <br />
<br />
More advanced materials available from the [[Conferences|conference proceedings]], and the [[Research papers]] collection.<br />
<br />
<br />
[[Category:Tutorials]]</div>BayleShanks