https://wiki.haskell.org/api.php?action=feedcontributions&user=Bracker&feedformat=atomHaskellWiki - User contributions [en]2024-03-29T04:41:31ZUser contributionsMediaWiki 1.35.5https://wiki.haskell.org/index.php?title=Diagrams/GSoC&diff=55547Diagrams/GSoC2013-03-12T14:48:24Z<p>Bracker: /* Make Plotting As Easy As Doing It in R */</p>
<hr />
<div>Are you a potential Google Summer of Code student searching for a project to propose? Consider contributing to [http://projects.haskell.org/diagrams/ diagrams]! It's an active project with a small, friendly, and knowledgeable [http://projects.haskell.org/diagrams/community.html developer community]. Contributions to diagrams directly improve people's ability to communicate ideas effectively, and raise the profile of the Haskell programming language. Most of all, it's fun---you get to tangibly experience your contributions in the form of beautiful or useful images.<br />
<br />
This page collects some suggested project ideas. We're happy to discuss any of the below ideas, or your own ideas, to help you come up with a solid proposal for a project you're excited about---send email to the [http://groups.google.com/group/diagrams-discuss mailing list].<br />
<br />
More info:<br />
<br />
* http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html<br />
* http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page<br />
* http://www.google-melange.com/gsoc/events/google/gsoc2013<br />
<br />
== Project ideas ==<br />
<br />
=== GTK application for creating diagrams interactively ===<br />
<br />
Having a tight feedback loop between coding and seeing the reflected changes in a diagram is important. Right now some of the backends have a "looped" compilation mode, but it's somewhat clunky and still a lot slower than it could be, probably due to overheads of compilation, linking, etc.<br />
<br />
The idea would be to develop a GTK application allowing the user to edit diagrams code (either with an in-application editing pane or in their own editor, perhaps using [http://hackage.haskell.org/package/fsnotify fsnotify] to watch for changes) and see the updated diagram immediately. Additional potential features include:<br />
<br />
* the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file<br />
* using sliders, input boxes, etc. to interactively display parameterized diagrams, perhaps in a type-directed way (see [http://hackage.haskell.org/package/craftwerk-gtk craftwerk-gtk] for inspiration)<br />
* Interactive editing of diagrams, e.g. dragging a displayed component and having an appropriate translation call automatically added to the code, or some other sort of support for interactively generating points, vectors, scaling factors, etc. using mouse input<br />
* Support for developing animations (e.g. with a slider for moving back+forth in time)<br />
<br />
=== Path operations ===<br />
<br />
It would be nice if diagrams could support various operations on paths such as intersection and union, curve fitting, and path simplification. See also [[Diagrams/Dev/Paths]], which has quite a bit of information on current efforts to implement path offsets and other path-related things.<br />
<br />
A student taking this on would probably already need some experience in computational geometry and paths in particular; implementing path algorithms properly is notoriously tricky (though having an incomplete and buggy implementation that nonetheless works "most of the time" would still be better than nothing!).<br />
<br />
=== Taking advantage of diagram tree structure ===<br />
<br />
Diagrams are stored using a [http://hackage.haskell.org/package/dual%2Dtree fancy tree data structure], but currently diagrams backends cannot take advantage of this information: diagrams are simply compiled into a list of primitives with attributes, and these are handed off to the backend. This has some important implications:<br />
<br />
* Sometimes it leads to inefficiency. For example, the diagrams code <code>fc blue (hcat $ replicate 1000 (circle 1))</code> results in backends setting the fill color 1000 times (once for each circle), when instead the fill color ought to be set just once.<br />
<br />
* There are additional features which could be implemented if backends were able to observe the tree structure, such as grouping for transparency.<br />
<br />
The project would consist in first figuring out how best to change the backend interface to allow observing the tree structure, and then implementing new features and improvements to backends based on this new ability. <br />
<br />
The devil's in the details: working with the diagram trees can be tricky. This is not a project for the faint of heart, but if you like getting down into tricky details, understanding them, and coming up with creative and elegant ways to achieve a goal given a number of constraints, this could be a fun project with a big impact.<br />
<br />
=== Constraint Based Diagrams ===<br />
<br />
Generate diagrams that meet some declarative constraint specification---perhaps something<br />
along the lines of http://wadler.blogspot.com/2011/06/combinator-library-for-design-of.html . The idea is to allow users to specify constraints on their diagram layout (e.g. "A should be no further left than B", "C and D should be at least 2 and at most 8 units apart"), probably using simple linear inequalities, and then solve them to generate an appropriate layout.<br />
<br />
A large part of the project would be in simply coming up with a good design for the user API and how to collect constraints; the rest would consist in figuring out how to solve the constraints (either directly, or by hooking up to some other library to e.g. solve systems of linear constraints).<br />
<br />
=== 3D diagrams ===<br />
<br />
Diagrams notionally supports arbitrary vector spaces, but no one has yet done the necessary work to make three-dimensional diagrams a reality. This project would have two main components:<br />
<br />
* Add three-dimensional primitives and functions to [https://github.com/diagrams/diagrams-lib diagrams-lib].<br />
<br />
* Work on one (or more) backends that can render 3D diagrams in some way. Options include developing the stub [https://github.com/diagrams/diagrams-povray diagrams-povray] backend, or developing an OpenGL backend.<br />
<br />
=== Make Plotting As Easy As Doing It in R ===<br />
<br />
From diagram-discuss:<br />
<br />
The above code produces four plots: a scatterplot (something you would <br />
often see in statistics), a plot of a function and, well, two empty <br />
grids. As a statistician, I usually work a lot with R together with a <br />
more or less sophisticated plotting package. The currently best <br />
plotting system for R is probably [http://had.co.nz/ggplot2/ ggplot ]. Now, I started using <br />
Bryan O'Sullivan's [http://hackage.haskell.org/package/statistics/ statistics package] for some of my calculations. <br />
Once in Haskell mode, you obviously don't want to switch back and <br />
forth between languages. So, I was wondering if it is possible to <br />
produce professional looking plots with diagrams' DSL, and how <br />
difficult it could be to put together a DSL for (statistical) <br />
plotting. <br />
<br />
I was thinking of something similar to ggplot's functionality. Making <br />
it easy to overlay plots, producing and combining legends, etc. <br />
Creating scatterplots and histograms and boxplots. Overlaying them <br />
with error regions and density estimates respectively. Then do the <br />
same for different subsets of the original data. Doing this with <br />
diagrams DSL could proof to be extremely powerful. Each "dot" in a <br />
plot could potentially be any diagram you want, dots, circles, stars, <br />
numbers or characters -- and if plots are nothing but diagrams, you <br />
could even plot plots into a plot. A real pain for most plotting <br />
systems is to combine multiple plots into one and to generate a common <br />
legend for all of them. This, for example, should be trivial to do <br />
within diagrams DSL. <br />
<br />
I would be more than happy to help in such a project. As the code <br />
above probably suggests, I am not the strongest Haskell hacker around. <br />
In fact, I am a statistician/mathematician who happens to use Haskell <br />
for some of his projects. That's it. Would anyone be interested in <br />
picking up such a project? As I said, I would be happy to help and <br />
get involved. Because I think there is a real need for something like <br />
this, and it would be very powerful to have eDSL for statistical <br />
plotting within Haskell.<br />
<br />
There seems to some interest in this idea: <br />
https://groups.google.com/d/topic/diagrams-discuss/TR9_Q8YnhMo/discussion<br />
<br />
'''Interested Students:'''<br />
<br />
* Jan Bracker<br />
<br />
== External Rendering ==<br />
<br />
The idea here would be to allow for special external rendering of some primitive that Diagrams does not support. For instance, it would be nice to be able to express LaTeX expressions and when the backend renders, offload the work externally then incorporate it with the output. There are several dimensions to supporting this well and making it as backend agnostic as possible. Somewhat related is the idea of external layout such as asking GraphViz to layout some structure then doing the rendering based on those positions. At the simplest this is just turning some new primitive into an `Image` primitive on the fly in the `Renderable` instance.<br />
<br />
== Variable Precision ==<br />
<br />
It would be nice to be able to trade off precision of the vector output of some<br />
backend with the size of that output. For instance the factorization diagrams<br />
are rather large when rendered to SVG, but their size could be cut in half by<br />
emitting doubles formatted to two significant digits. There is a nice balance<br />
that could be struck at a high level where we ensure that we are always within<br />
some fraction of what will likely be a pixel in the final output. Then at the<br />
level of the backend we would only need to choose the representation that is<br />
the smallest for any particular number.<br />
<br />
This could be aided by generalized R2.<br />
<br />
== Sources for more ideas ==<br />
<br />
* http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html</div>Brackerhttps://wiki.haskell.org/index.php?title=Diagrams/GSoC&diff=55546Diagrams/GSoC2013-03-12T14:48:01Z<p>Bracker: /* Make Plotting As Easy As Doing It in R */</p>
<hr />
<div>Are you a potential Google Summer of Code student searching for a project to propose? Consider contributing to [http://projects.haskell.org/diagrams/ diagrams]! It's an active project with a small, friendly, and knowledgeable [http://projects.haskell.org/diagrams/community.html developer community]. Contributions to diagrams directly improve people's ability to communicate ideas effectively, and raise the profile of the Haskell programming language. Most of all, it's fun---you get to tangibly experience your contributions in the form of beautiful or useful images.<br />
<br />
This page collects some suggested project ideas. We're happy to discuss any of the below ideas, or your own ideas, to help you come up with a solid proposal for a project you're excited about---send email to the [http://groups.google.com/group/diagrams-discuss mailing list].<br />
<br />
More info:<br />
<br />
* http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html<br />
* http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page<br />
* http://www.google-melange.com/gsoc/events/google/gsoc2013<br />
<br />
== Project ideas ==<br />
<br />
=== GTK application for creating diagrams interactively ===<br />
<br />
Having a tight feedback loop between coding and seeing the reflected changes in a diagram is important. Right now some of the backends have a "looped" compilation mode, but it's somewhat clunky and still a lot slower than it could be, probably due to overheads of compilation, linking, etc.<br />
<br />
The idea would be to develop a GTK application allowing the user to edit diagrams code (either with an in-application editing pane or in their own editor, perhaps using [http://hackage.haskell.org/package/fsnotify fsnotify] to watch for changes) and see the updated diagram immediately. Additional potential features include:<br />
<br />
* the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file<br />
* using sliders, input boxes, etc. to interactively display parameterized diagrams, perhaps in a type-directed way (see [http://hackage.haskell.org/package/craftwerk-gtk craftwerk-gtk] for inspiration)<br />
* Interactive editing of diagrams, e.g. dragging a displayed component and having an appropriate translation call automatically added to the code, or some other sort of support for interactively generating points, vectors, scaling factors, etc. using mouse input<br />
* Support for developing animations (e.g. with a slider for moving back+forth in time)<br />
<br />
=== Path operations ===<br />
<br />
It would be nice if diagrams could support various operations on paths such as intersection and union, curve fitting, and path simplification. See also [[Diagrams/Dev/Paths]], which has quite a bit of information on current efforts to implement path offsets and other path-related things.<br />
<br />
A student taking this on would probably already need some experience in computational geometry and paths in particular; implementing path algorithms properly is notoriously tricky (though having an incomplete and buggy implementation that nonetheless works "most of the time" would still be better than nothing!).<br />
<br />
=== Taking advantage of diagram tree structure ===<br />
<br />
Diagrams are stored using a [http://hackage.haskell.org/package/dual%2Dtree fancy tree data structure], but currently diagrams backends cannot take advantage of this information: diagrams are simply compiled into a list of primitives with attributes, and these are handed off to the backend. This has some important implications:<br />
<br />
* Sometimes it leads to inefficiency. For example, the diagrams code <code>fc blue (hcat $ replicate 1000 (circle 1))</code> results in backends setting the fill color 1000 times (once for each circle), when instead the fill color ought to be set just once.<br />
<br />
* There are additional features which could be implemented if backends were able to observe the tree structure, such as grouping for transparency.<br />
<br />
The project would consist in first figuring out how best to change the backend interface to allow observing the tree structure, and then implementing new features and improvements to backends based on this new ability. <br />
<br />
The devil's in the details: working with the diagram trees can be tricky. This is not a project for the faint of heart, but if you like getting down into tricky details, understanding them, and coming up with creative and elegant ways to achieve a goal given a number of constraints, this could be a fun project with a big impact.<br />
<br />
=== Constraint Based Diagrams ===<br />
<br />
Generate diagrams that meet some declarative constraint specification---perhaps something<br />
along the lines of http://wadler.blogspot.com/2011/06/combinator-library-for-design-of.html . The idea is to allow users to specify constraints on their diagram layout (e.g. "A should be no further left than B", "C and D should be at least 2 and at most 8 units apart"), probably using simple linear inequalities, and then solve them to generate an appropriate layout.<br />
<br />
A large part of the project would be in simply coming up with a good design for the user API and how to collect constraints; the rest would consist in figuring out how to solve the constraints (either directly, or by hooking up to some other library to e.g. solve systems of linear constraints).<br />
<br />
=== 3D diagrams ===<br />
<br />
Diagrams notionally supports arbitrary vector spaces, but no one has yet done the necessary work to make three-dimensional diagrams a reality. This project would have two main components:<br />
<br />
* Add three-dimensional primitives and functions to [https://github.com/diagrams/diagrams-lib diagrams-lib].<br />
<br />
* Work on one (or more) backends that can render 3D diagrams in some way. Options include developing the stub [https://github.com/diagrams/diagrams-povray diagrams-povray] backend, or developing an OpenGL backend.<br />
<br />
=== Make Plotting As Easy As Doing It in R ===<br />
<br />
From diagram-discuss:<br />
<br />
The above code produces four plots: a scatterplot (something you would <br />
often see in statistics), a plot of a function and, well, two empty <br />
grids. As a statistician, I usually work a lot with R together with a <br />
more or less sophisticated plotting package. The currently best <br />
plotting system for R is probably [http://had.co.nz/ggplot2/ ggplot ]. Now, I started using <br />
Bryan O'Sullivan's [http://hackage.haskell.org/package/statistics/ statistics package] for some of my calculations. <br />
Once in Haskell mode, you obviously don't want to switch back and <br />
forth between languages. So, I was wondering if it is possible to <br />
produce professional looking plots with diagrams' DSL, and how <br />
difficult it could be to put together a DSL for (statistical) <br />
plotting. <br />
<br />
I was thinking of something similar to ggplot's functionality. Making <br />
it easy to overlay plots, producing and combining legends, etc. <br />
Creating scatterplots and histograms and boxplots. Overlaying them <br />
with error regions and density estimates respectively. Then do the <br />
same for different subsets of the original data. Doing this with <br />
diagrams DSL could proof to be extremely powerful. Each "dot" in a <br />
plot could potentially be any diagram you want, dots, circles, stars, <br />
numbers or characters -- and if plots are nothing but diagrams, you <br />
could even plot plots into a plot. A real pain for most plotting <br />
systems is to combine multiple plots into one and to generate a common <br />
legend for all of them. This, for example, should be trivial to do <br />
within diagrams DSL. <br />
<br />
I would be more than happy to help in such a project. As the code <br />
above probably suggests, I am not the strongest Haskell hacker around. <br />
In fact, I am a statistician/mathematician who happens to use Haskell <br />
for some of his projects. That's it. Would anyone be interested in <br />
picking up such a project? As I said, I would be happy to help and <br />
get involved. Because I think there is a real need for something like <br />
this, and it would be very powerful to have eDSL for statistical <br />
plotting within Haskell.<br />
<br />
There seems to some interest in this idea: <br />
https://groups.google.com/d/topic/diagrams-discuss/TR9_Q8YnhMo/discussion<br />
<br />
'''Interested Students:'''<br />
<br />
* Jan Bracker<br />
<br />
== External Rendering ==<br />
<br />
The idea here would be to allow for special external rendering of some primitive that Diagrams does not support. For instance, it would be nice to be able to express LaTeX expressions and when the backend renders, offload the work externally then incorporate it with the output. There are several dimensions to supporting this well and making it as backend agnostic as possible. Somewhat related is the idea of external layout such as asking GraphViz to layout some structure then doing the rendering based on those positions. At the simplest this is just turning some new primitive into an `Image` primitive on the fly in the `Renderable` instance.<br />
<br />
== Variable Precision ==<br />
<br />
It would be nice to be able to trade off precision of the vector output of some<br />
backend with the size of that output. For instance the factorization diagrams<br />
are rather large when rendered to SVG, but their size could be cut in half by<br />
emitting doubles formatted to two significant digits. There is a nice balance<br />
that could be struck at a high level where we ensure that we are always within<br />
some fraction of what will likely be a pixel in the final output. Then at the<br />
level of the backend we would only need to choose the representation that is<br />
the smallest for any particular number.<br />
<br />
This could be aided by generalized R2.<br />
<br />
== Sources for more ideas ==<br />
<br />
* http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=55090Language extensions2012-12-18T18:18:05Z<p>Bracker: </p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* Derive:<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveDataTypeable]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveGeneric]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveFunctor]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveFoldable]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveTraversable]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#id616911 GeneralizedNewtypeDeriving]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[KindSignatures]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Monomorphism restriction|NoMonomorphismRestriction]]<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Scoped type variables|ScopedTypeVariables]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#tuple-sections TupleSections] : Allow tuples to be partially applied.<br />
* [[GHC/Type families|TypeFamilies]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
* [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns ViewPatterns]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=55089Language extensions2012-12-18T18:16:19Z<p>Bracker: /* List of language extensions by name */</p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* Derive:<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveDataTypeable]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveGeneric]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveFunctor]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveFoldable]<br />
** [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#deriving-typeable DeriveTraversable]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[KindSignatures]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Monomorphism restriction|NoMonomorphismRestriction]]<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Scoped type variables|ScopedTypeVariables]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#tuple-sections TupleSections] : Allow tuples to be partially applied.<br />
* [[GHC/Type families|TypeFamilies]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
* [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns ViewPatterns]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=54641Language extensions2012-11-11T20:30:33Z<p>Bracker: /* List of language extensions by name */</p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* [[Generics|DeriveGeneric]]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[KindSignatures]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Monomorphism restriction|NoMonomorphismRestriction]]<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Scoped type variables|ScopedTypeVariables]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#tuple-sections TupleSections] : Allow tuples to be partially applied.<br />
* [[GHC/Type families|TypeFamilies]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
* [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns ViewPatterns]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=54588Language extensions2012-11-01T18:30:27Z<p>Bracker: /* List of language extensions by name */</p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* [[Generics|DeriveGeneric]]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[KindSignatures]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Monomorphism restriction|NoMonomorphismRestriction]]<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Scoped type variables|ScopedTypeVariables]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [[GHC/Type families|TypeFamilies]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
* [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns ViewPatterns]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=54361Language extensions2012-10-15T21:00:44Z<p>Bracker: </p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* [[Generics|DeriveGeneric]]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[KindSignatures]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Monomorphism restriction|NoMonomorphismRestriction]]<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Scoped type variables|ScopedTypeVariables]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [[GHC/Type families|TypeFamilies]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=54299Language extensions2012-10-12T01:29:54Z<p>Bracker: /* List of language extensions by name */</p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* [[Generics|DeriveGeneric]]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[KindSignatures]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Scoped type variables|ScopedTypeVariables]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [[GHC/Type families|TypeFamilies]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=54095Language extensions2012-09-27T16:51:56Z<p>Bracker: </p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* [[Generics|DeriveGeneric]]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Scoped type variables|ScopedTypeVariables]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [[GHC/Type families|TypeFamilies]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=54084Language extensions2012-09-26T19:31:16Z<p>Bracker: </p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* [[Generics|DeriveGeneric]]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Scoped type variables|ScopedTypeVariables]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=Language_extensions&diff=44735Language extensions2012-03-04T12:38:37Z<p>Bracker: Started listing the different language extensions with a short description.</p>
<hr />
<div>Language extensions are used to enable language features in Haskell that may seem useful in certain cases. They can be used to loosen restrictions in the type system or add completely new language constructs to Haskell.<br />
<br />
They can be enabled using the [http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/pragmas.html#language-pragma LANGUAGE pragma] or (in GHC) using the flag -X. The LANGUAGE pragma should be preferred here.<br />
<br />
Before just using the language extension that fits your need, [[Use of language extensions|think about<br />
when it is useful]] and what risk it may bring to your program.<br />
<br />
== List of language extensions by name ==<br />
<br />
This list is far from complete and needs extension.<br />
<br />
* [[Datatype contexts|DatatypeContexts]] : Add type constraints to your datatype.<br />
* [[Default signatures|DefaultSignatures]]<br />
* [[Generics|DeriveGeneric]]<br />
* [[Existential type|ExistentialQuantification]]<br />
* [[Flexible contexts|FlexibleContexts]]<br />
* [[Flexiblae instances|FlexibleInstances]] : Allow a type parameter to occure twice within a type class instance.<br />
* [[Functional dependencies|FunctionalDependencies]] : Are used to constrain the parameters of type classes.<br />
* [[GADT]]s : Generalised algebraic datatypes - A more general approach to algebraic datatypes.<br />
* [[Implicit parameters|ImplicitParams]]<br />
* [[Multi-parameter type class|MultiParamTypeClasses]] : Enable multiple type parameters in type classes.<br />
* [[Overlapping instance|OverlappingInstances]]<br />
* [[Rank-N types|Rank2Types]]<br />
* [[Rank-N types|RankNTypes]]<br />
* [[Template Haskell|TemplateHaskell]]<br />
* [[Undecidable instance|UndecidableInstances]]<br />
<br />
<br />
[[Category:Language extensions]]</div>Brackerhttps://wiki.haskell.org/index.php?title=OpenGLTutorial1&diff=44734OpenGLTutorial12012-03-04T10:47:11Z<p>Bracker: typo</p>
<hr />
<div>''This tutorial [http://blog.mikael.johanssons.org/archive/2006/09/opengl-programming-in-haskell-a-tutorial-part-1/] was originally written by Mikael Vejdemo Johansson, and was copied here with permission.''<br />
<br />
After having failed following the [http://www.cs.hs-rm.de/~panitz/hopengl/skript.html googled tutorial in HOpenGL programming], I thought I'd write down the steps I actually can get to work in a tutorial-like fashion. It may be a good idea to read this in parallell to the tutorial linked, since Panitz actually brings a lot of good explanations, even though his syntax isn't up to speed with the latest HOpenGL at all points.<br />
<br />
Note: GHCI interactive shell has problems running these program on some platforms (such as Mac OS X). <strong>Compile these programs with ghc, and run the generated executables.<br />
</strong><br />
<br />
==Hello World==<br />
First of all, we'll want to load the OpenGL libraries, throw up a window, and generally get to grips with what needs to be done to get a program running at all. <br />
<br />
<haskell><br />
import Graphics.Rendering.OpenGL<br />
import Graphics.UI.GLUT<br />
<br />
main :: IO ()<br />
main = do <br />
(progname, _) <- getArgsAndInitialize<br />
createWindow "Hello World"<br />
displayCallback $= flush<br />
mainLoop<br />
</haskell><br />
<br />
This code throws up a window, with a given title, and sets the main display function to do nothing but flush the (empty) graphics buffer. This is the skeleton that we'll be building on to.<br />
<br />
Save it to HelloWorld.hs and compile it by running <hask>ghc -package GLUT HelloWorld.hs -o HelloWorld</hask>.<br />
<br />
You will see a window open, with the title "Hello World", with either a blank canvas, or with some garbage graphics content pulled from somewhere in your system's graphics memory.<br />
<br />
In either case, this program is profoundly worthless.<br />
<br />
At a minimum, let's have our program display a clean blank canvas:<br />
<br />
So we modify our code to the following:<br />
<br />
<haskell><br />
import Graphics.Rendering.OpenGL<br />
import Graphics.UI.GLUT<br />
<br />
main :: IO ()<br />
main = do<br />
(progname, _) <- getArgsAndInitialize<br />
createWindow "Hello World"<br />
displayCallback $= display<br />
mainLoop<br />
<br />
display :: IO ()<br />
display = do<br />
clear [ ColorBuffer ]; flush<br />
<br />
</haskell><br />
<br />
This defines a function "display" that calls a few OpenGL functions: "clear" to clear out the graphics color state (so we get a blank canvas), and "flush" to push our OpenGL commands down to the system graphics for actual display.<br />
<br />
We don't call "display" directly. (In fact, we don't call any graphics drawing functions directly). Instead, we set a display callback, and then call mainLoop. In mainLoop, OpenGL akes over, handles all the details of interacting with the OS and refreshing our window, calling our displayCallback to draw graphics.<br />
<br />
displayCallback is a Data.IORef (mutable state variable), which we set using a call to <hask>($=)</hask>.<br />
<br />
Save this to the HelloWorld.hs, recompile, and rerun. This program displays an endless series of blank canvases (a solid blank image).<br />
<br />
The displayCallback is a globally defined IORef, which can be accessed through a host of functions defined in Data.IORef. In [http://hackage.haskell.org/packages/archive/OpenGL/2.2.2.0/doc/html/Graphics-Rendering-OpenGL-GL-StateVar.html OpenGL StateVar module], there is a HasSetter type class and an IORef implementation providing functions <hask>($=)</hask> (assignment) and <hask>get</hask> to fascilitate interactions with these state variables. <br />
<br />
<haskell><br />
height = newIORef 1.0<br />
currentheight <- get height<br />
height $= 1.5<br />
</haskell><br />
<br />
==Using the drawing canvas==<br />
So, we have a window, we have a display callback that clears the canvas. Don't we want more out of it? Sure we do. So let's draw some things.<br />
<haskell><br />
import Graphics.Rendering.OpenGL<br />
import Graphics.UI.GLUT<br />
myPoints :: [(GLfloat,GLfloat,GLfloat)]<br />
myPoints = map (\k -> (sin(2*pi*k/12),cos(2*pi*k/12),0.0)) [1..12]<br />
main = do <br />
(progname, _) <- getArgsAndInitialize<br />
createWindow "Hello World"<br />
displayCallback $= display<br />
mainLoop<br />
display = do <br />
clear [ColorBuffer]<br />
renderPrimitive Points $ mapM_ (\(x, y, z)->vertex$Vertex3 x y z) myPoints<br />
flush<br />
</haskell><br />
<br />
Now, the important thing to notice in this code extract is that last line. It starts a rendering definition, gives the type to be rendered, and then a sequence of function calls, each of which adds a vertex to the rendering canvas. The statement is basically equivalent to something along the lines of<br />
<haskell><br />
renderPrimitive Points do<br />
vertex Vertex3 ...<br />
vertex Vertex3 ...<br />
</haskell><br />
for appropriate triples of coordinate values at the appropriate places. This results in the rendition here:<br />
<br />
[[image:OG-Points.png]]<br />
<br />
We can replace <code>Points</code> with other primitives, leading to the rendering of:<br />
<br />
===<code>Triangles</code>===<br />
[[image:OG-Triangles.png]]<br />
<br />
Each three coordinates following each other define a triangle. The last n mod 3 coordinates are ignored.<br />
<br />
Keyword <code>Triangles</code><br />
<br />
===Triangle strips===<br />
[[image:OG-Trianglestrip.png]]<br />
<br />
Triangles are drawn according to a “moving window” of size three, so the two last coordinates in the previous triangle become the two first in the next triangle.<br />
<br />
Keyword <code>TriangleStrip</code><br />
<br />
===Triangle fans===<br />
[[image:OG-Trianglesfan.png]]<br />
<br />
<code>TriangleFan</code>s have the first given coordinate as a basepoint, and takes each pair of subsequent coordinates to define a triangle together with the first coordinate.<br />
<br />
Keyword <code>TriangleFan</code><br />
<br />
===Lines===<br />
[[image:OG-Lines.png]]<br />
<br />
Each pair of coordinates define a line.<br />
<br />
Keyword <code>Lines</code><br />
<br />
===Line loops===<br />
[[image:OG-Lineloop.png]]<br />
<br />
With <code>LineLoop</code>s, each further coordinate defines a line together with the last coordinate used. Once all coordinates are used up, an additional line is drawn back to the beginning.<br />
<br />
Keyword <code>LineLoop</code><br />
<br />
===Line strips===<br />
[[image:OG-Linestrip.png]]<br />
<br />
<code>LineStrip</code>s are like <code>LineLoop</code>s, only without the last link added.<br />
<br />
Keyword <code>LineStrip</code><br />
<br />
===Quadrangles===<br />
[[image:OG-Quad.png]]<br />
<br />
For the <code>Quads</code> keyword, each four coordinates given define a quadrangle.<br />
<br />
Keyword <code>Quads</code><br />
<br />
===Quadrangle strips===<br />
[[image:OG-Quadstrip.png]]<br />
<br />
And a <code>QuadStrip</code> works as the <code>TriangleStrip</code>, only the window is 4 coordinates wide and steps 2 steps each time, so each new pair of coordinates attaches a new quadrangle to the last edge of the last quadrangle.<br />
<br />
Keyword <code>QuadStrip</code><br />
<br />
===Polygon===<br />
[[image:OG-Polygon.png]]<br />
<br />
A <code>Polygon</code> is a filled line loop. Simple as that!<br />
<br />
Keyword <code>Polygon</code><br />
<br />
There are more things we can do on our canvas than just spreading out coordinates. Within the command list constructed after a renderPrimitive, we can give several different commands that control what things are supposed to look like, so for instance we could use the following:<br />
<haskell><br />
display = do <br />
clear [ColorBuffer]<br />
renderPrimitive Quads $ do<br />
color $ (Color3 (1.0::GLfloat) 0 0)<br />
vertex $ (Vertex3 (0::GLfloat) 0 0)<br />
vertex $ (Vertex3 (0::GLfloat) 0.2 0)<br />
vertex $ (Vertex3 (0.2::GLfloat) 0.2 0)<br />
vertex $ (Vertex3 (0.2::GLfloat) 0 0)<br />
color $ (Color3 (0::GLfloat) 1 0)<br />
vertex $ (Vertex3 (0::GLfloat) 0 0)<br />
vertex $ (Vertex3 (0::GLfloat) (-0.2) 0)<br />
vertex $ (Vertex3 (0.2::GLfloat) (-0.2) 0)<br />
vertex $ (Vertex3 (0.2::GLfloat) 0 0)<br />
color $ (Color3 (0::GLfloat) 0 1)<br />
vertex $ (Vertex3 (0::GLfloat) 0 0)<br />
vertex $ (Vertex3 (0::GLfloat) (-0.2) 0)<br />
vertex $ (Vertex3 ((-0.2)::GLfloat) (-0.2) 0)<br />
vertex $ (Vertex3 ((-0.2)::GLfloat) 0 0)<br />
color $ (Color3 (1::GLfloat) 0 1)<br />
vertex $ (Vertex3 (0::GLfloat) 0 0)<br />
vertex $ (Vertex3 (0::GLfloat) 0.2 0)<br />
vertex $ (Vertex3 ((-0.2::GLfloat)) 0.2 0)<br />
vertex $ (Vertex3 ((-0.2::GLfloat)) 0 0)<br />
flush<br />
</haskell><br />
in order to produce these four coloured squares:<br />
<br />
[[image:OG-Colorsquares.png]]<br />
<br />
where each color command sets the color for the next item drawn, and the vertex commands give vertices for the four squares.<br />
<br />
==Callbacks - how we react to changes==<br />
We have already seen one callback in action: <code>displayCallback</code>. The Callbacks are state variables of the HOpenGL system, and are called in order to handle various things that may happen to the place the drawing canvas lives. For a first exercise, go resize the latest window you've used. Go on, do it now.<br />
<br />
I bet it looked ugly, didn't it?<br />
<br />
This is because we have no code handling what to do if the window should suddenly change. Handling this is done in a callback, residing in the <code>IORef reshapeCallback</code>. Similarly, repainting is done in <code>displayCallback</code>, keyboard and mouse input is in <code>keyboardMouseCallback</code>, and so on. We can refer to the HOpenGL documentation for [http://hackage.haskell.org/packages/archive/GLUT/latest/doc/html/Graphics-UI-GLUT-Callbacks-Window.html window callbacks] and for [http://hackage.haskell.org/packages/archive/GLUT/latest/doc/html/Graphics-UI-GLUT-Callbacks-Global.html global callbacks]. Window callbacks are things like display, keyboard and mouse, and reshape. Global callbacks deal with timing issues (for those snazzy animations) and the menu interface systems.<br />
<br />
In order for a callback to possibly not be defined, most are typed within the <code>Maybe</code> monad, so by setting the state variable to <code>Nothing</code>, a callback can be disabled. Thus, setting callbacks is done using the keyword <code>Just</code>. We'll add a callback for reshaping the window to our neat code, changing the main function to:<br />
<haskell><br />
main = do <br />
(progname, _) <- getArgsAndInitialize<br />
createWindow "Hello World"<br />
displayCallback $= display<br />
reshapeCallback $= Just reshape<br />
mainLoop<br />
reshape s@(Size w h) = do<br />
viewport $= (Position 0 0, s)<br />
postRedisplay Nothing<br />
</haskell><br />
<br />
Here, the code for the reshape function resizes the viewport so that our drawing area contains the entire new window. After setting the new viewport, it also tells the windowing system that something has happened to the window, and that therefore, the display function should be called.<br />
<br />
==Summary==<br />
So, in conclusion, so far we can display a window, post basic callbacks to get the windowhandling to run smoothly, and draw in our window. Next installment of the tutorial will bring you 3d drawing, keyboard and mouse interactions, the incredible power of matrices and the ability to rotate 3d objects for your leisure. Possibly, we'll even look into animations.<br />
<br />
[[OpenGLTutorial2|Continue with part 2]]<br />
<br />
[[Category:Graphics]]<br />
[[Category:How to]]<br />
[[Category:User interfaces]]<br />
[[Category:Libraries]]</div>Bracker