- Haskell-Cafe - Haskell.org

A prototype concept for teaching type-class polymorphic functions
by Christopher Done 01 Oct '14

01 Oct '14

Hey there, For those teaching Haskell and making teaching tools, you might be interested in this mode of presentation of a function: http://chrisdone.com/fmap It's a little slow because the implementation is naive (it abuses my tryhaskell.org server), however the concept is: see what fmap really does by showing what you get when applying it to a variety of different types, including “strange” ones like Const and the function type. A given function has visually evident ways of applying to different data structures. The value changes and so does the type. Challenge: take this ball and run with it to illustrate return and >>= for a number of monads. Maybe, [], LogicT, Either, etc. Given that I've been using Haskell for 6 years and haven't yet written a monad tutorial, I don't want to break that clean sheet now. If that's too hard, there're plenty of simpler classes to experiment with. Some types require special handling to display in an intuitive way, like the ((->) r) example. But ignoring that, if you were sufficiently shrewd, you could automatically generate such an interactive page by taking a given typeclass, asking GHCi or the GHC API for all known instances of that type, which are Showable (or somehow representable) and then enumerating them in this kind of display. Others have suggested a "before and after" side-by-side look. So that's an option to consider. Technically you can get before/after with ‘id’ (a lesson in itself, the identity law!), but a two-column layout is an option. Ciao!

1 0

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 01 Oct '14

01 Oct '14

============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st October 2014 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year, but there is currently no common location in which to promote and advertise the resulting work. The Journal of Functional Programming would like to change that! As a service to the community, JFP recently launched a new feature, in the form of a regular publication of abstracts from PhD dissertations that were completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall, and do not require any transfer for copyright, merely a license from the author. The first round of published abstracts can be downloaded from http://journals.cambridge.org/jfp/phd_abstracts. Please submit dissertation abstracts according to the instructions below. A dissertation is eligible if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. JFP will not have these abstracts reviewed. We welcome submissions from both the PhD student and PhD advisor/ supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 31st October 2014. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 1000 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting in the abstract, but do get in touch if this causes significant problems) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: [Haskell-cafe] Increasing Haskell modularity
by Gershom B 01 Oct '14

01 Oct '14

It seems to me the far easier choice, in ditching the feature “not worth the problem” is simply to eliminate orphan instances as in “Extension 1” described in Edward Yang’s blog post (http://blog.ezyang.com/2014/09/open-type-families-are-not-modular/) I’d like to open up a further discussion on this at some future point, as I’m convinced that there is no “legitimate” use of orphans in the Haskell ecosystem that cannot be substituted for with other safer and more straightforward techniques. -g On October 1, 2014 at 9:26:45 AM, Gesh (gesh(a)gesh.uni.cx) wrote: > Dear Café, > Edward Yang recently wrote about the non-modularity of the current semantics > for typeclasses[0] and open type families[1]. > Given these problems, we can either try to work around the problem, or > decide > whether these features are worth the problems. > The specific pair of proposals I am making are the following: > * Give up on global uniqueness of typeclass instances. > Oleg discusses adding local typclass instances without losing > coherence in his > reflection paper[2]. If we adopt his proposal, and weaken global > uniqueness of > instances to local uniqueness, we can then say that typeclass > instances in a > module are considered more local than imported instances, and therefore > override them. > Since instances will be locally unique, we don't have to pass around > dictionaries. Data types that expect globally unique instances, such > as Set, > will have to store dictionaries, however. > * Give up on non-associated open type families. > This I have researched less well, but it seems to me that these have > no use > case. Since one can make whatever instances one wishes for these type > families, one can't do anything useful with values of their instances. > In other words, values of type F a are morally of type (forall a. a). > Thus, the only way I can see these being useful is if anyone creating an > instance of the family must also provide functions that can work with > these > instances, which brings us back to the case of associated types. > > As far as I can see, these two features are useless and impeding the > drive to > make Haskell more modular. Therefore, my questions for you are twofold: > * Is there a reason to keep these features? > * If not, why don't we drop them? > > Awaiting your criticism and ire, > Gesh > > [0] - > http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uni… > [1] - http://blog.ezyang.com/2014/09/open-type-families-are-not-modular/ > [2] - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.112.7819 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

3 2

Increasing Haskell modularity
by Gesh 01 Oct '14

01 Oct '14

Dear Café, Edward Yang recently wrote about the non-modularity of the current semantics for typeclasses[0] and open type families[1]. Given these problems, we can either try to work around the problem, or decide whether these features are worth the problems. The specific pair of proposals I am making are the following: * Give up on global uniqueness of typeclass instances. Oleg discusses adding local typclass instances without losing coherence in his reflection paper[2]. If we adopt his proposal, and weaken global uniqueness of instances to local uniqueness, we can then say that typeclass instances in a module are considered more local than imported instances, and therefore override them. Since instances will be locally unique, we don't have to pass around dictionaries. Data types that expect globally unique instances, such as Set, will have to store dictionaries, however. * Give up on non-associated open type families. This I have researched less well, but it seems to me that these have no use case. Since one can make whatever instances one wishes for these type families, one can't do anything useful with values of their instances. In other words, values of type F a are morally of type (forall a. a). Thus, the only way I can see these being useful is if anyone creating an instance of the family must also provide functions that can work with these instances, which brings us back to the case of associated types. As far as I can see, these two features are useless and impeding the drive to make Haskell more modular. Therefore, my questions for you are twofold: * Is there a reason to keep these features? * If not, why don't we drop them? Awaiting your criticism and ire, Gesh [0] - http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uni… [1] - http://blog.ezyang.com/2014/09/open-type-families-are-not-modular/ [2] - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.112.7819

2 1

Re: [Haskell-cafe] ANN: Nomyx 0.7 beta, the only game where you can change the rules
by Corentin Dupont 01 Oct '14

01 Oct '14

Hi again, we started the game, please join, don't be shy :) Some interresting rules have already been proposed by players: - we now have a list of friends. - we have bank accounts in a currency called the "Bling". - we'll soon have planets, and maybe spaceships. A lot of things can happen now (what friends allow to do? How to win money? how to trade with planets? etc.). www.nomyx.net Cheers! C On Tue, Sep 30, 2014 at 12:31 PM, Corentin Dupont <corentin.dupont(a)gmail.com > wrote: > > Hello everybody! > I released Nomyx <http://www.nomyx.net> V0.7, the only game where You can > change the rules! > Here is the website: www.nomyx.net > Here is a video introduction of the game: http://vimeo.com/58265498 > I created a tutorial to learn how to play: > http://www.corentindupont.info/blog/posts/2014-09-23-first-Nomyx-tutorial.h… > > Let's start a new game! I propose to call it "The Space Merchants". Dear > rulers, this part of the Galaxy is yours... > Please login to the game here: www.nomyx.net:8000/Nomyx. > The corresponding forum thread is here: > http://www.nomyx.net/forum/viewtopic.php?f=4&t=1525&p=1739 > Please also register on the mailing list to follow the game: > nomyx-game(a)googlegroups.com > > Some background: this is an implementation of a Nomic [1] game in Haskell > (I believe the first complete implementation of a Nomic game on a > computer). In a Nomyx game you can change the rules of the game itself > while playing it. The players can submit new rules or modify existing ones, > thus completely changing the behaviour of the game through time. The rules > are managed and interpreted by the computer. They must be written in the > Nomyx language <http://hackage.haskell.org/package/Nomyx-Language>, which > is a subset of Haskell. > > At the beginning, the initial rules are describing: > - how to add new rules and change existing ones. For example a unanimity > vote is necessary to have a new rule accepted. > - how to win the game. For example you win the game if you have 5 rules > accepted. > But of course even that can be changed! > > New in this beta release: > - the Nomyx language is now based on functional reactive programming > - the language also embeds a mechanism to separate effectful instructions > from effectless ones > - ability to fork an existing game into a new one > - ability to type-check rules before submitting them > - ability to create new games > > If you wanna help developing Nomyx, join us on the dev mailing-list: > dev-game(a)googlegroups.com <nomyx-game(a)googlegroups.com> > > > Cheers, > Corentin > > [1] www.nomic.net > >

1 0

context deduction in GHC
by Doug McIlroy 30 Sep '14

30 Sep '14

Why does ghci 7.6.3 not like this example, which section 4.3.2 of the language definition says is valid Haskell? class Foo a class Foo a => Bar a instance (Eq a, Show a) => Foo [a] instance Num a => Bar [a] Ghci complains, "Could not deduce (Show a) arising from the superclasses of an instance declaration from the context (Num a)". Yet Show is a superclass of Num. Hugs accepts the code. Doug McIlroy

3 2

ANN: Nomyx 0.7 beta, the only game where you can change the rules
by Corentin Dupont 30 Sep '14

30 Sep '14

Hello everybody! I released Nomyx <http://www.nomyx.net> V0.7, the only game where You can change the rules! Here is the website: www.nomyx.net Here is a video introduction of the game: http://vimeo.com/58265498 I created a tutorial to learn how to play: http://www.corentindupont.info/blog/posts/2014-09-23-first-Nomyx-tutorial.h… Let's start a new game! I propose to call it "The Space Merchants". Dear rulers, this part of the Galaxy is yours... Please login to the game here: www.nomyx.net:8000/Nomyx. The corresponding forum thread is here: http://www.nomyx.net/forum/viewtopic.php?f=4&t=1525&p=1739 Please also register on the mailing list to follow the game: nomyx-game(a)googlegroups.com Some background: this is an implementation of a Nomic [1] game in Haskell (I believe the first complete implementation of a Nomic game on a computer). In a Nomyx game you can change the rules of the game itself while playing it. The players can submit new rules or modify existing ones, thus completely changing the behaviour of the game through time. The rules are managed and interpreted by the computer. They must be written in the Nomyx language <http://hackage.haskell.org/package/Nomyx-Language>, which is a subset of Haskell. At the beginning, the initial rules are describing: - how to add new rules and change existing ones. For example a unanimity vote is necessary to have a new rule accepted. - how to win the game. For example you win the game if you have 5 rules accepted. But of course even that can be changed! New in this beta release: - the Nomyx language is now based on functional reactive programming - the language also embeds a mechanism to separate effectful instructions from effectless ones - ability to fork an existing game into a new one - ability to type-check rules before submitting them - ability to create new games If you wanna help developing Nomyx, join us on the dev mailing-list: dev-game(a)googlegroups.com <nomyx-game(a)googlegroups.com> Cheers, Corentin [1] www.nomic.net

2 1

Cabal Testing Pain
by Mike Craig 30 Sep '14

30 Sep '14

Hey all, I'm trying to setup an executable cabal project, the options for cabal-based testing seem poor. I poked around for discussions of this but didn't find much. My apologies if I'm beating a dead horse. The current options, as I understand them, are 1. Split code into library, executable, and test-suite. This gets you single compilation but you have to list every source file in the library's exposed/other-modules sections. 2. Split code into executable and test-suite. You don't have to list the source files, but you get double compilation and you have to declare every dependency (and version!) twice. Am I missing a third (better) option, or is this the state of things? -- Mike Craig

5 4

the complex package is hidden
by briand＠aracnet.com 28 Sep '14

28 Sep '14

Hi, surprisingly i can't seem to google an answer to this: Could not find module `Complex' It is a member of the hidden package `haskell98-2.0.0.2'. Use -v to see a list of the files searched for. it's been quite a while since I've used ghci, and I'm just about positive I've solved this problem before, but can't seem to figure it out. Thanks for any help.

2 8

Deploying bash completion with cabal?
by Jacob Stanley 28 Sep '14

28 Sep '14

Hi All I'm looking for a good way to deploy a bash completion script somewhere appropriate for the given operating system. Has anyone tackled this before? I was considering packaging the script in to the install using cabal data files, then having an 'install--bash-completion' option that tries to detect the right place to install it depending on the OS. Cheers Jacob

2 1