https://wiki.haskell.org/api.php?action=feedcontributions&user=Green+tea&feedformat=atomHaskellWiki - User contributions [en]2022-01-19T08:33:45ZUser contributionsMediaWiki 1.27.4https://wiki.haskell.org/index.php?title=OzHaskell&diff=16190OzHaskell2007-10-17T07:29:26Z<p>Green tea: Added 'Alexis Hazell' as possibly interested in participating.</p>
<hr />
<div>'''There is AngloHaskell and now AmeroHaskell. Doesn't that call for OzHaskell?'''<br />
<br />
Who would be interested to have a Haskell event in Australia, possibly in Sydney? This is just a wild idea without any concrete date or format yet. Jot down any suggestions on this page.<br />
<br />
Interested Haskellers:<br />
<br />
* [[:User:Chak|Manuel Chakravarty]] (Sydney)<br />
* [[:User:TonyMorris|Tony Morris]]<br />
* [[:User:Brecknell|Matthew Brecknell]] (Brisbane)<br />
* [[:User:Mark_Wassell|Mark Wassell]] - Prefer Jan/Feb option.<br />
* [[:User:Rl|Roman Leshchinskiy]]<br />
* [[:User:cbrad|Brad Clow]]<br />
* [[:User:nornagon|Jeremy Apthorp]]<br />
* [[:User:AndrewA|Andrew Appleyard]] (Sydney)<br />
* [[:User:bjpop|Bernie Pope]] (Melbourne)<br />
* [[:User:benl23|Ben Lippmeier]]<br />
* [[:User:RohanDrape|Rohan Drape]]<br />
* [[:User:ivanm|Ivan Miljenovic]] (Brisbane)<br />
* [[:User:EricWilligers|Eric Willigers]]<br />
* [[:User:TonySloane|Tony Sloane]] (Sydney)<br />
* [[:User:Bens|Ben Sinclair]] (Sydney)<br />
* [[:User:andrep|Andre Pang]]<br />
* [[:User:AndrewBromage|Andrew Bromage]] (Melbourne)<br />
* [[:User:Droberts|Dale Roberts]] (Sydney)<br />
* [[:User:GeoffWilson|Geoff Wilson]] (Melbourne)<br />
* [[:User:Saulzar|Oliver Batchelor]] (Brisbane)<br />
* [[:User:Nick|Nick Seow]] (Sydney)<br />
* [[:User:sseefried|Sean Seefried]] (Sydney)<br />
* [[:User:green_tea|Alexis Hazell]] (Melbourne)<br />
(Add your name!)<br />
<br />
== Possible dates ==<br />
<br />
Shall we try to organise something for sometime over the summer? Avoiding the summer holidays, either of the following two periods seem attractive:<br />
<br />
* last week of November/first week of December or<br />
* last week of January/first week of February.<br />
<br />
(Add any additional periods that you would find attractive and/or comment on suitability.)<br />
<br />
Events to avoid clashing with:<br />
<br />
* The 2007 federal election (weekend of 24-25 November).<br />
* linux.conf.au (28 Jan - 2 Feb 2007, unless it's held in conjunction).<br />
* Inevitable family Christmas parties/holiday travel rush (some weekends in December, different for everyone I suspect).<br />
<br />
== Format ==<br />
<br />
How about the following?<br />
<br />
* One day meeting with informal talks and demos (preferably on a Friday)<br />
* There could be a second, even less formal day, for those who want to hang out some more and maybe some hacking<br />
* Run it at the University of New South Wales, Sydney<br />
<br />
(Add your thoughts to the above.)<br />
<br />
== Talks and demos ==<br />
<br />
Do you have anything you'd like to talk about or a system you'd like to demo? '''This is just a tentative list - you commit to nothing.'''<br />
<br />
=== Talk proposals ===<br />
<br />
* Manuel Chakravarty: ''Type-level Programming with Type Families''<br />
::GHC recently gained support for data families and type synonym families (which are a generalisation of our earlier proposal for associated types). In this talk, I'd give an overview over this new language feature, illustrate what it is good for, and discuss why I believe it fits Haskell better than functional dependencies.<br />
* Bernie Pope: ''The GHCi debugger''<br />
:: A new breakpoint debugger has been added to GHCi. In this talk, I'd demonstrate how to use the debugger, and also go into some detail about how it works. I might even discuss the relative advantages and disadvantages of this debugger over tools such as Hat.<br />
<br />
=== Demo proposals ===</div>Green teahttps://wiki.haskell.org/index.php?title=Monad_(sans_metaphors)&diff=15103Monad (sans metaphors)2007-08-17T00:02:40Z<p>Green tea: </p>
<hr />
<div>[[Category:Glossary]]<br />
<br />
=== Introduction ===<br />
Many discussions of Haskell Monads seek to explain them through the use of a variety of metaphors. This page attempts to simply provide a more technical yet straightforward description of Monads in Haskell.<br />
<br />
This article originally appeared as a post to the Haskell-cafe mailing list by Claus Reinke on 2 August 2007.<br />
<br />
=== So what ''is'' a monad? ===<br />
A Monad is a type constructor with two operations, implementing a standard interface and following a few simple rules.<br />
<br />
The Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. <br />
<br />
The Monadic interface gives you two operations: one to throw things into a Monad thing (<hask>return</hask>), and one to chain two Monad things together <hask>(>>=)</hask>. The chaining explicitly caters for information flowing from the first to the second parameter of <hask>(>>=)</hask>.<br />
<br />
The Monad laws tell you two useful facts about Monad things thrown together in that way: whatever it is the Monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the <br />
structure of chaining is irrelevant - only the ordering of chained Monad things matters.<br />
<br />
There are usually other ways to create 'primitive' Monadic things, which can be combined into complex Monadic structures using the operations from the Monad interface.<br />
<br />
There is usually a way to interpret Monadic structures built in this way - a 'run' operation of some kind. Examples include:<br />
<br />
* I/O: The 'primitive Monadic things' are basic I/O operations. The 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO Monad structures sequentially, starting with the leftmost innermost I/O operation in the structure and applying the second argument of <hask>(>>=)</hask> to the result of executing the first.<br />
<br />
* []: The 'primitive Monadic things' are lists. The 'run' operation is the identity, i.e the lists are directly exposed as data structures. <hask>return</hask> creates a singleton list. <hask>(>>=)</hask> applies its second argument to each element of its first argument and concatenates the results (<hask>concatMap</hask>).<br />
<br />
* State: The 'primitive Monadic things' are operations on a state type, returning a result and a state. 'run' is <hask>runState</hask> and applies a (possibly) complex Monadic thing to an input state, returning a result and a (modified) state. <hask>return</hask> returns its parameter, passing its input state unchanged. <hask>(>>=)</hask> applies its first parameter to the input state, applies its second parameter to the result value and result state of the first.</div>Green teahttps://wiki.haskell.org/index.php?title=Monad_(sans_metaphors)&diff=15102Monad (sans metaphors)2007-08-16T23:58:52Z<p>Green tea: </p>
<hr />
<div>[[Category:Glossary]]<br />
<br />
=== Introduction ===<br />
Many discussions of Haskell Monads seek to explain them through the use of a variety of metaphors. This page attempts to simply provide a more technical yet straightforward description of Monads in Haskell.<br />
<br />
This article originally appeared as a post to the Haskell-cafe mailing list by Claus Reinke on 2 August 2007.<br />
<br />
=== So what ''is'' a monad? ===<br />
A Monad is a type constructor with two operations, implementing a standard interface and following a few simple rules.<br />
<br />
The Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. <br />
<br />
The Monadic interface gives you two operations: one to throw things into a Monad thing (<hask>return</hask>), and one to chain two Monad things together <hask>(>>=)</hask>. The chaining explicitly caters for information flowing from the first to the second parameter of <hask>(>>=)</hask>.<br />
<br />
The Monad laws tell you two useful facts about monad things thrown together in that way: whatever it is the Monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the <br />
structure of chaining is irrelevant - only the ordering of chained Monad things matters.<br />
<br />
There are usually other ways to create 'primitive' Monadic things, which can be combined into complex Monadic structures using the operations from the Monad interface.<br />
<br />
There is usually a way to interpret Monadic structures built in this way - a 'run' operation of some kind. Examples include:<br />
<br />
* I/O: The 'primitive Monadic things' are basic I/O operations. The 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO Monad structures sequentially, starting with the leftmost innermost I/O operation in the structure and applying the second argument of <hask>(>>=)</hask> to the result of executing the first.<br />
<br />
* []: The 'primitive Monadic things' are lists. The 'run' operation is the identity, i.e the lists are directly exposed as data structures. <hask>return</hask> creates a singleton list. <hask>(>>=)</hask> applies its second argument to each element of its first argument and concatenates the results (<hask>concatMap</hask>).<br />
<br />
* State: The 'primitive Monadic things' are operations on a state type, returning a result and a state. 'run' is <hask>runState</hask> and applies a (possibly) complex Monadic thing to an input state, returning a result and a (modified) state. <hask>return</hask> returns its parameter, passing its input state unchanged. <hask>(>>=)</hask> applies its first parameter to the input state, applies its second parameter to the result value and result state of the first.</div>Green teahttps://wiki.haskell.org/index.php?title=Monad_(sans_metaphors)&diff=15100Monad (sans metaphors)2007-08-16T23:57:47Z<p>Green tea: Metaphorless Monads moved to Monad (sans metaphors)</p>
<hr />
<div>[[Category:Glossary]]<br />
<br />
=== Introduction ===<br />
Many discussions of Haskell Monads seek to explain them through the use of a variety of metaphors. This page attempts to simply provide a more technical yet straightforward description of Monads in Haskell.<br />
<br />
This article originally appeared as a post to the Haskell-cafe mailing list by Claus Reinke on 2 August 2007.<br />
<br />
=== So what ''is'' a Monad? ===<br />
A Monad is a type constructor with two operations, implementing a standard interface and following a few simple rules.<br />
<br />
The Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. <br />
<br />
The Monadic interface gives you two operations: one to throw things into a Monad thing (<hask>return</hask>), and one to chain two Monad things together <hask>(>>=)</hask>. The chaining explicitly caters for information flowing from the first to the second parameter of <hask>(>>=)</hask>.<br />
<br />
The Monad laws tell you two useful facts about monad things thrown together in that way: whatever it is the Monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the <br />
structure of chaining is irrelevant - only the ordering of chained Monad things matters.<br />
<br />
There are usually other ways to create 'primitive' Monadic things, which can be combined into complex Monadic structures using the operations from the Monad interface.<br />
<br />
There is usually a way to interpret Monadic structures built in this way - a 'run' operation of some kind. Examples include:<br />
<br />
* I/O: The 'primitive Monadic things' are basic I/O operations. The 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO Monad structures sequentially, starting with the leftmost innermost I/O operation in the structure and applying the second argument of <hask>(>>=)</hask> to the result of executing the first.<br />
<br />
* []: The 'primitive Monadic things' are lists. The 'run' operation is the identity, i.e the lists are directly exposed as data structures. <hask>return</hask> creates a singleton list. <hask>(>>=)</hask> applies its second argument to each element of its first argument and concatenates the results (<hask>concatMap</hask>).<br />
<br />
* State: The 'primitive Monadic things' are operations on a state type, returning a result and a state. 'run' is <hask>runState</hask> and applies a (possibly) complex Monadic thing to an input state, returning a result and a (modified) state. <hask>return</hask> returns its parameter, passing its input state unchanged. <hask>(>>=)</hask> applies its first parameter to the input state, applies its second parameter to the result value and result state of the first.</div>Green teahttps://wiki.haskell.org/index.php?title=Metaphorless_Monads&diff=15101Metaphorless Monads2007-08-16T23:57:47Z<p>Green tea: Metaphorless Monads moved to Monad (sans metaphors): New title makes more sense in the context of the Glossary, and follows the HaskellWiki guidelines.</p>
<hr />
<div>#redirect [[Monad (sans metaphors)]]</div>Green teahttps://wiki.haskell.org/index.php?title=Monad_(sans_metaphors)&diff=15089Monad (sans metaphors)2007-08-16T09:22:49Z<p>Green tea: </p>
<hr />
<div>[[Category:Glossary]]<br />
<br />
=== Introduction ===<br />
Many discussions of Haskell Monads seek to explain them through the use of a variety of metaphors. This page attempts to simply provide a more technical yet straightforward description of Monads in Haskell.<br />
<br />
This article originally appeared as a post to the Haskell-cafe mailing list by Claus Reinke on 2 August 2007.<br />
<br />
=== So what ''is'' a Monad? ===<br />
A Monad is a type constructor with two operations, implementing a standard interface and following a few simple rules.<br />
<br />
The Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. <br />
<br />
The Monadic interface gives you two operations: one to throw things into a Monad thing (<hask>return</hask>), and one to chain two Monad things together <hask>(>>=)</hask>. The chaining explicitly caters for information flowing from the first to the second parameter of <hask>(>>=)</hask>.<br />
<br />
The Monad laws tell you two useful facts about monad things thrown together in that way: whatever it is the Monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the <br />
structure of chaining is irrelevant - only the ordering of chained Monad things matters.<br />
<br />
There are usually other ways to create 'primitive' Monadic things, which can be combined into complex Monadic structures using the operations from the Monad interface.<br />
<br />
There is usually a way to interpret Monadic structures built in this way - a 'run' operation of some kind. Examples include:<br />
<br />
* I/O: The 'primitive Monadic things' are basic I/O operations. The 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO Monad structures sequentially, starting with the leftmost innermost I/O operation in the structure and applying the second argument of <hask>(>>=)</hask> to the result of executing the first.<br />
<br />
* []: The 'primitive Monadic things' are lists. The 'run' operation is the identity, i.e the lists are directly exposed as data structures. <hask>return</hask> creates a singleton list. <hask>(>>=)</hask> applies its second argument to each element of its first argument and concatenates the results (<hask>concatMap</hask>).<br />
<br />
* State: The 'primitive Monadic things' are operations on a state type, returning a result and a state. 'run' is <hask>runState</hask> and applies a (possibly) complex Monadic thing to an input state, returning a result and a (modified) state. <hask>return</hask> returns its parameter, passing its input state unchanged. <hask>(>>=)</hask> applies its first parameter to the input state, applies its second parameter to the result value and result state of the first.</div>Green teahttps://wiki.haskell.org/index.php?title=Monad_(sans_metaphors)&diff=15088Monad (sans metaphors)2007-08-16T09:21:07Z<p>Green tea: </p>
<hr />
<div>[[Category:Glossary]]<br />
<br />
=== Introduction ===<br />
Many discussions of Haskell Monads seek to explain them through the use of a variety of metaphors. This page attempts to simply provide a more technical yet straightforward description of Monads in Haskell.<br />
<br />
This article originally appeared as a post to the Haskell-cafe mailing list by Claus Reinke on 2 August 2007.<br />
<br />
=== So what ''is'' a Monad? ===<br />
A Monad is a type constructor with two operations, implementing a standard interface and following a few simple rules.<br />
<br />
The Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. <br />
<br />
The Monadic interface gives you two operations: one to throw things into a Monad thing (<hask>return</hask>), and one to chain two Monad things together (<hask>>>=</hask>). The chaining explicitly caters for information flowing from the first to the second parameter of <hask>(>>=)</hask>.<br />
<br />
The Monad laws tell you two useful facts about monad things thrown together in that way: whatever it is the Monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the <br />
structure of chaining is irrelevant - only the ordering of chained Monad things matters.<br />
<br />
There are usually other ways to create 'primitive' Monadic things, which can be combined into complex Monadic structures using the operations from the Monad interface.<br />
<br />
There is usually a way to interpret Monadic structures built in this way - a 'run' operation of some kind. Examples include:<br />
<br />
* I/O: The 'primitive Monadic things' are basic I/O operations. The 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO Monad structures sequentially, starting with the leftmost innermost I/O operation in the structure and applying the second argument of <hask>(>>=)</hask> to the result of executing the first.<br />
<br />
* []: The 'primitive Monadic things' are lists. The 'run' operation is the identity, i.e the lists are directly exposed as data structures. <hask>return</hask> creates a singleton list. <hask>(>>=)</hask> applies its second argument to each element of its first argument and concatenates the results (<hask>concatMap</hask>).<br />
<br />
* State: The 'primitive Monadic things' are operations on a state type, returning a result and a state. 'run' is <hask>runState</hask> and applies a (possibly) complex Monadic thing to an input state, returning a result and a (modified) state. <hask>return</hask> returns its parameter, passing its input state unchanged. <hask>(>>=)</hask> applies its first parameter to the input state, applies its second parameter to the result value and result state of the first.</div>Green teahttps://wiki.haskell.org/index.php?title=Monad_(sans_metaphors)&diff=15087Monad (sans metaphors)2007-08-16T09:12:15Z<p>Green tea: A more technical description of Haskell Monads, sans metaphors.</p>
<hr />
<div>[[Category:Glossary]]<br />
<br />
=== Introduction ===<br />
Many discussions of Haskell Monads seek to explain them through the use of a variety of metaphors. This page attempts to simply provide a more technical yet straightforward description of Monads in Haskell.<br />
<br />
This article originally appeared as a post to the Haskell-cafe mailing list by Claus Reinke on 2 August 2007.<br />
<br />
=== So what ''is'' a Monad? ===<br />
A Monad is a type constructor with two operations, implementing a standard interface and following a few simple rules.<br />
<br />
The Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. <br />
<br />
The Monadic interface gives you two operations: one to throw things into a Monad thing (<hask>return</hask>), and one to chain two Monad things together <hask>(>>=)</hask>. The chaining explicitly caters for information flowing from the first to the second parameter of <hask>(>>=)</hask>.<br />
<br />
The Monad laws tell you two useful facts about monad things thrown together in that way: whatever it is the Monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the <br />
structure of chaining is irrelevant - only the ordering of chained Monad things matters.<br />
<br />
There are usually other ways to create 'primitive' Monadic things, which can be combined into complex Monadic structures using the operations from the Monad interface.<br />
<br />
There is usually a way to interpret Monadic structures built in this way - a 'run' operation of some kind. Examples include:<br />
<br />
* I/O: The 'primitive Monadic things' are basic I/O operations. The 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO Monad structures sequentially, starting with the leftmost innermost I/O operation in the structure and applying the second argument of <hask>(>>=)</hask> to the result of executing the first.<br />
<br />
* []: The 'primitive Monadic things' are lists. The 'run' operation is the identity, i.e the lists are directly exposed as data structures. <hask>return</hask> creates a singleton list. <hask>(>>=)</hask> applies its second argument to each element of its first argument and concatenates the results (<hask>concatMap</hask>).<br />
<br />
* State: The 'primitive Monadic things' are operations on a state type, returning a result and a state. 'run' is <hask>runState</hask> and applies a (possibly) complex Monadic thing to an input state, returning a result and a (modified) state. <hask>return</hask> returns its parameter, passing its input state unchanged. <hask>(>>=)</hask> applies its first parameter to the input state, applies its second parameter to the result value and result state of the first.</div>Green teahttps://wiki.haskell.org/index.php?title=File:Metaphorless_Monads&diff=15086File:Metaphorless Monads2007-08-16T09:05:29Z<p>Green tea: A more technical description of Haskell Monads, sans metaphors.</p>
<hr />
<div>A more technical description of Haskell Monads, sans metaphors.</div>Green tea