September 2013 - Haskell-Cafe

Proposal: New syntax for Haskell
by Niklas Hambüchen 16 Sep '13

16 Sep '13

Impressed by the productivity of my Ruby-writing friends, I have recently come across Cucumber: http://cukes.info It is a great tool for specifying tests and programs in natural language, and especially easy to learn for beginners. I propose that we add a Cucumber syntax for Haskell, with the extension ".chs", next to .hs and .lhs. Code written in cucumber syntax is concise and easy to read: You can find some example code in https://gist.github.com/nh2/6505995. Quoting from that: Feature: The Data.List module In order to be able to use lists As a programmer I want a module that defines list functions Scenario: Defining the function foldl Given I want do define foldl Which has the type (in brackets) a to b to a (end of brackets), to a, to list of b, to a And my arguments are called f, acc, and l When l is empty Then the result better be acc Otherwise l is x cons xs Then the result should be foldl f (in brackets) f acc x (end of brackets) xs PS: People even already started a testing framework for Haskell in it: https://github.com/sol/cucumber-haskell#cucumber-for-haskell

21 23

An APL library for Haskell
by Simon Peyton-Jones 16 Sep '13

16 Sep '13

Friends Many of you will know the array language APL<http://en.wikipedia.org/wiki/APL_%28programming_language%29>. It focuses on arrays and in particular has a rich, carefully-thought-out array algebra. An obvious idea is: what would a Haskell library that embodies APL's array algebra look like? In conversation with John Scholes and some of his colleagues in the APL community a group of us developed some ideas for a possible API, which you can find on the Haskell wiki here: http://www.haskell.org/haskellwiki/APL However, we have all gone our separate ways, and I think it's entirely possible that that the idea will go no further. So this message is to ask: * Is anyone interested in an APL-style array library in Haskell? * If so, would you like to lead the process of developing the API? I think there are quite a few people who would be willing to contribute, including some core gurus from the APL community: John Scholes, Arthur Whitney, and Roger Hui. Simon

5 5

Re: [Haskell-cafe] OS X ghci problem
by Jan-Philip Loos 16 Sep '13

16 Sep '13

> What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish linker. > The only wrinkle is figuring out where you want the dylib. > I think homebrew will put one in /usr/local/lib, which works out nicely, but they don't have GLFW 3 yet. > Another option is to build the dylib yourself from the GLFW source bundled with the GLFW-b package, then tell cabal where to find it. Hi, for me the problem relocates now to the "bindings-glfw" package, since the native bindings moved to this package and are wrapped up with "glfw-b". My way to the same exception already mentioned by Brian Lewis: 1) > cabal install bindings-glfw 2) > ghci 3) ghci> :m Bindings.GLFW 4) ghci> Bindings.GLFW.c'glfwInit 5) ghci terminates with exception: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool init]: unrecognized selector sent to instance 0x7fc443c01b30' Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no clue how to do this. I built the according glfw version on my own as a dylib and loaded ghci with it explicitly, this didn't help. I guess the compiled bindings-glfw is already statically packed up. How can I get ghci to use the native glfw dylib in combination with bindings-glfw? If I have to compile bindings-glfw with different settings, which settings? I have some oversight over haskell but no really deep knowledge according to bindings and lib-loading of ghci, but I'm willing to learn it ;) My Platform: - OSX 10.8.5 - ghc(i) 7.6.3 - cabal 1.18.0.1 - xcode dev tools 4.6.3 Thanks and Greetings Jan

3 3

ANN: Cabal v1.18.0 released
by Johan Tibell 16 Sep '13

16 Sep '13

Hi all, On behalf of the cabal maintainers and contributors I'm proud to announce the Cabal (and cabal-install) 1.18.0 release. To install run cabal update && cabal install Cabal-1.18.0 cabal-install-1.18.0 With 854 commits since the last release there are two many improvements and bug fixes to list them here, but two highlights are: * Hermetic builds using sandboxes. This should reduce the number of "dependency hell" and broken package DB problems. * GHCi support. It's now much easier to use ghci when developing your packages, especially if those packages require preprocessors (e.g. hsc2hs). Here's how working on a package might look like using the new features: # Only once: cabal sandbox init cabal install --only-dependencies --enable-tests # Configure, build, and run tests: cabal test # now implies configure and build # Play around with the code in GHCi: cabal repl Mikhail wrote a bit more about the user visible changes on his blog: http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html For a complete list of changes run git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 in the cabal repo or look at the GitHub compare page: https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-in… (only shows the last 250 commits). 57 people contributed to this release! 503 Mikhail Glushenkov 99 Johan Tibell 41 Duncan Coutts 39 Ian Lynagh 19 Brent Yorgey 19 Thomas Tuegel 18 Ben Millwood 16 Eyal Lotem 10 Thomas Dziedzic 7 Andres Loeh 6 John Wiegley 6 Benno Fünfstück 5 Gregory Collins 4 Herbert Valerio Riedel 4 Simon Hengel 3 Joachim Breitner 3 Luke Iannini 3 Bryan Richter 3 Richard Eisenberg 3 Tuncer Ayaz 3 Jens Petersen 2 Arun Tejasvi Chaganty 2 Bryan O'Sullivan 2 Eric Kow 2 Jookia 2 Paolo G. Giarrusso 2 Paolo Capriotti 1 Sönke Hahn 1 Yitzchak Gale 1 Albert Krewinkel 1 stepcut 1 Alexander Kjeldaas 1 Austin Seipp 1 Bardur Arantsson 1 Ben Doyle 1 Ben Gamari 1 Bram 1 Carter Tazio Schonwald 1 Clint Adams 1 Daniel Wagner 1 David Lazar 1 Erik Hesselink 1 Eugene Sukhodolin 1 Gabor Greif 1 Jack Henahan 1 Jason Dagit 1 Ken Bateman 1 Mark Lentczner 1 Masahiro Yamauchi 1 Merijn Verstraaten 1 Michael Thompson 1 Niklas Hambüchen 1 Oleksandr Manzyuk 1 Patrick Premont 1 Roman Cheplyaka 1 Sergei Trofimovich 1 Stephen Blackheath -- Johan, on behalf of the cabal maintainers and contributors.

7 9

Recent problems with -cafe -- Fixed (I hope)
by Gershom Bazerman 15 Sep '13

15 Sep '13

There were problems with the -cafe mailinglist today. Best I can tell, we had an unplanned system reboot last night. In the course of it going down and back up, the configuration for -cafe got corrupted and the auto-fixed configuration had roughly 3/4 of the membership deleted. I've gone in and replaced it with a recent backup config, which should have fixed the problem. If this email goes through, then we're in good shape -- sorry about the mess. --Gershom

1 0

reifying typeclasses (resend)
by Evan Laforge 15 Sep '13

15 Sep '13

[ This is the second time I sent this, the first time it said it was awaiting moderation because I'm not subscribed to haskell-cafe, which is weird because I thought I was. Did a bunch of people get unsubscribed? ] I'm sure this is old-hat to typeclass wizards, but I've managed to get pretty far without understanding them too well, so here's a basic question. I haven't seen it phrased this way before though: I have a typeclass which is instantiated across a closed set of 3 types. It has an ad-hoc set of methods, and I'm not too happy with them because being a typeclass forces them to all be defined in one place, breaking modularity. A sum type, of course, wouldn't have that problem. But in other places I want the type-safety that separate types provide, and packing everything into a sum type would destroy that. So, expression problem-like, I guess. It seems to me like I should be able to replace a typeclass with arbitrary methods with just two, to reify the type and back. This seems to work when the typeclass dispatches on an argument, but not on a return value. E.g.: {-# LANGUAGE ScopedTypeVariables #-} class Taggable a where toTagged :: a -> Tagged toTaggedType :: a -> TaggedType fromTagged :: Tagged -> Maybe a m_argument :: a -> Int m_result :: Int -> a data Tagged = TInt Int | TChar Char deriving (Show) data TaggedType = TypeInt | TypeChar deriving (Show) instance Taggable Int where toTagged = TInt toTaggedType _ = TypeInt fromTagged (TInt x) = Just x fromTagged _ = Nothing m_argument = id m_result = id instance Taggable Char where toTagged = TChar toTaggedType _ = TypeChar fromTagged (TChar x) = Just x fromTagged _ = Nothing m_argument = fromEnum m_result = toEnum argument :: (Taggable a) => a -> Int argument a = case toTagged a of TInt x -> x TChar c -> fromEnum c result :: forall a. (Taggable a) => Int -> a result val = case toTaggedType (undefined :: a) of TypeInt -> val TypeChar -> toEnum val Say m_argument and m_result are the ad-hoc methods I'd like to get out of the typeclass. I can do that well enough for 'argument', but 'result' runs into trouble. One is the ugly undefined trick with toTaggedType, but the bigger one is that ghc says 'Could not deduce (a ~ Int) from the context (Taggable a)'. I wasn't really expecting it to work, because it would entail a case with multiple types. As far as I know, the only way for that to happen is with GADTs. But I don't see how they could help me here. So, perhaps my intuition was wrong. toTagged and fromTagged methods give you the power to go between value and type level, but apparently that's not enough power to express what typeclasses give you. Also it seems like there's a fundamental difference between dispatching on argument vs dispatching on result. Is there a way to more formally understand the extents of what typeclasses provide, and what a toTagged fromTagged scheme gives me, so I can have a better intuition for how to go between value and type levels? Also, the toTaggedType thing is pretty ugly. Not just passing it undefined, but how it has to repeat the types. I don't really see a way to get around that though.

3 2

Re: [Haskell-cafe] reifying typeclasses
by oleg＠okmij.org 15 Sep '13

15 Sep '13

[I too had the problem sending this e-mail to Haskell list. I got a reply saying the message awaits moderator approval] Evan Laforge wrote: > I have a typeclass which is instantiated across a closed set of 3 > types. It has an ad-hoc set of methods, and I'm not too happy with > them because being a typeclass forces them to all be defined in one > place, breaking modularity. A sum type, of course, wouldn't have that > problem. But in other places I want the type-safety that separate > types provide, and packing everything into a sum type would destroy > that. So, expression problem-like, I guess. > > It seems to me like I should be able to replace a typeclass with > arbitrary methods with just two, to reify the type and back. This > seems to work when the typeclass dispatches on an argument, but not on > a return value. E.g.: If the universe (the set of types of interest to instantiate the type class to) is closed, GADTs spring to mind immediately. See, for example, the enclosed code. It is totally unproblematic (one should remember to always write type signatures when programming with GADTs. Weird error messages otherwise ensue.) One of the most notable differences between GADT and type-class--based programming is that GADTs are closed and type classes are open (that is, new instances can be added at will). In fact, a less popular technique of implementing type classes (which has been used in some Haskell systems -- but not GHC)) is intensional type analysis, or typecase. It is quite similar to the GADT solution. The main drawback of the intensional type analysis as shown in the enclosed code is that it breaks parametricity. The constraint Eq a does not let one find out what the type 'a' is and so what other operations it may support. (Eq a) says that the type a supports (==), and does not say any more than that. OTH, Representable a tells quite a lot about type a, essentially, everything. > types. It has an ad-hoc set of methods, and I'm not too happy with > them because being a typeclass forces them to all be defined in one > place, breaking modularity. A sum type, of course, wouldn't have that Why not to introduce several type classes, even a type class for each method if necessary. Grouping methods under one type class is appropriate when such a grouping makes sense. Otherwise, Haskell won't lose in expressiveness if a type class could have only one method. {-# LANGUAGE GADTs #-} module G where data TRep a where TInt :: TRep Int TChar :: TRep Char class Representable a where repr :: TRep a instance Representable Int where repr = TInt instance Representable Char where repr = TChar argument :: Representable a => a -> Int argument x = go repr x where -- For GADTs, signatures are important! go :: TRep a -> a -> Int go TInt x = x go TChar x = fromEnum x -- just the `mirror inverse' result :: Representable a => Int -> a result x = go repr x where -- For GADTs, signatures are important! go :: TRep a -> Int -> a go TInt x = x go TChar x = toEnum x t1 = argument 'a' t2 = show (result 98 :: Char)

1 0

LATA 2014: 3rd call for papers
by GRLMC 15 Sep '13

15 Sep '13

*To be removed from our mailing list, please respond to this message with UNSUBSCRIBE in the subject line* ************************************************************************* 8th INTERNATIONAL CONFERENCE ON LANGUAGE AND AUTOMATA THEORY AND APPLICATIONS LATA 2014 Madrid, Spain March 10-14, 2014 Organized by: Research Group on Implementation of Language-Driven Software and Applications (ILSA) Complutense University of Madrid Research Group on Mathematical Linguistics (GRLMC) Rovira i Virgili University http://grammars.grlmc.com/lata2014/ ********************************************************************* AIMS: LATA is a yearly conference on theoretical computer science and its applications. Following the tradition of the diverse PhD training events in the field developed at Rovira i Virgili University in Tarragona since 2002, LATA 2014 will reserve significant room for young scholars at the beginning of their career. It will aim at attracting contributions from both classical theory fields and application areas (bioinformatics, language technology, artificial intelligence, etc.). VENUE: LATA 2014 will take place in Madrid, the capital of Spain. The venue will be the School of Informatics of Complutense University. SCOPE: Topics of either theoretical or applied interest include, but are not limited to: algebraic language theory algorithms for semi-structured data mining algorithms on automata and words automata and logic automata for system analysis and programme verification automata, concurrency and Petri nets automatic structures cellular automata codes combinatorics on words compilers computability computational complexity data and image compression decidability issues on words and languages descriptional complexity DNA and other models of bio-inspired computing digital libraries and document engineering foundations of finite state technology foundations of XML fuzzy and rough languages grammars (Chomsky hierarchy, contextual, unification, categorial, etc.) grammatical inference and algorithmic learning graphs and graph transformation language varieties and semigroups language-based cryptography language-theoretic foundations of artificial intelligence and artificial life natural language and speech automatic processing parallel and regulated rewriting parsing patterns power series quantum, chemical and optical computing semantics string and combinatorial issues in computational biology and bioinformatics string processing algorithms symbolic dynamics symbolic neural networks term rewriting transducers trees, tree languages and tree automata weighted automata STRUCTURE: LATA 2014 will consist of: invited talks invited tutorials peer-reviewed contributions INVITED SPEAKERS: Javier Esparza (Munich Tech, DE), On Trees and Fixed Point Equations (tutorial) Leslie A. Goldberg (Oxford, UK), The Complexity of Approximate Counting Oscar H. Ibarra (Santa Barbara, US), tba Sanjeev Khanna (Philadelphia, US), tba Helmut Seidl (Munich Tech, DE), tba PROGRAMME COMMITTEE: Dana Angluin (Yale, US) Eugene Asarin (Paris Diderot, FR) Jos Baeten (Amsterdam, NL) Christel Baier (Dresden, DE) Jan Bergstra (Amsterdam, NL) Jin-Yi Cai (Madison, US) Marek Chrobak (Riverside, US) Andrea Corradini (Pisa, IT) Mariangiola Dezani (Turin, IT) Ding-Zhu Du (Dallas, US) Michael R. Fellows (Darwin, AU) Jörg Flum (Freiburg, DE) Nissim Francez (Technion, IL) Jürgen Giesl (Aachen, DE) Annegret Habel (Oldenburg, DE) Kazuo Iwama (Kyoto, JP) Sampath Kannan (Philadelphia, US) Ming-Yang Kao (Northwestern, US) Deepak Kapur (Albuquerque, US) Joost-Pieter Katoen (Aachen, DE) S. Rao Kosaraju (Johns Hopkins, US) Evangelos Kranakis (Carleton, CA) Gad M. Landau (Haifa, IL) Andrzej Lingas (Lund, SE) Jack Lutz (Iowa State, US) Ian Mackie (École Polytechnique, FR) Carlos Martín-Vide (Tarragona, ES, chair) Giancarlo Mauri (Milan, IT) Faron G. Moller (Swansea, UK) Paliath Narendran (Albany, US) Enno Ohlebusch (Ulm, DE) Helmut Prodinger (Stellenbosch, ZA) Jean-François Raskin (Brussels, BE) Wolfgang Reisig (Humboldt Berlin, DE) Marco Roveri (Bruno Kessler, Trento, IT) Michaël Rusinowitch (LORIA, Nancy, FR) Yasubumi Sakakibara (Keio, JP) Davide Sangiorgi (Bologna, IT) Colin Stirling (Edinburgh, UK) Jianwen Su (Santa Barbara, US) Jean-Pierre Talpin (IRISA, Rennes, FR) Andrzej Tarlecki (Warsaw, PL) Rick Thomas (Leicester, UK) Sophie Tison (Lille, FR) Rob van Glabbeek (NICTA, Sydney, AU) Helmut Veith (Vienna Tech, AT) ORGANIZING COMMITTEE: Adrian Horia Dediu (Tarragona) Ana Fernández-Pampillón (Madrid) Carlos Martín-Vide (Tarragona, co-chair) Antonio Sarasa (Madrid) José-Luis Sierra (Madrid, co-chair) Bianca Truthe (Magdeburg) Florentina Lilica Voicu (Tarragona) SUBMISSIONS: Authors are invited to submit non-anonymized papers in English presenting original and unpublished research. Papers should not exceed 12 single-spaced pages (including eventual appendices) and should be formatted according to the standard format for Springer Verlag's LNCS series (see http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0) Submissions have to be uploaded to: https://www.easychair.org/conferences/?conf=lata2014 PUBLICATIONS: A volume of proceedings published by Springer in the LNCS series will be available by the time of the conference. A special issue of a major journal will be later published containing peer-reviewed extended versions of some of the papers contributed to the conference. Submissions to it will be by invitation. REGISTRATION: The period for registration is open from July 15, 2013 to March 10, 2014. The registration form can be found at: http://grammars.grlmc.com/lata2014/Registration.php DEADLINES: Paper submission: October 14, 2013 (23:59 CET) Notification of paper acceptance or rejection: November 25, 2013 Final version of the paper for the LNCS proceedings: December 2, 2013 Early registration: December 9, 2013 Late registration: February 24, 2014 Starting of the conference: March 10, 2014 End of the conference: March 14, 2014 Submission to the post-conference journal special issue: June 14, 2014 QUESTIONS AND FURTHER INFORMATION: florentinalilica.voicu(a)urv.cat POSTAL ADDRESS: LATA 2014 Research Group on Mathematical Linguistics (GRLMC) Rovira i Virgili University Av. Catalunya, 35 43002 Tarragona, Spain Phone: +34-977-559543 Fax: +34-977-558386 ACKNOWLEDGEMENTS: Departament dEconomia i Coneixement, Generalitat de Catalunya Universidad Complutense de Madrid Universitat Rovira i Virgili

1 0

Quick Angel User's Survey
by Michael Xavier 14 Sep '13

14 Sep '13

Hey Cafe, I am the maintainer of Angel, the process monitoring daemon. Angel's job is to start a configured set of processes and restart them when they go away. I was responding to a ticket and realized that the correct functionality is not obvious in one case, so I figured I'd ask the stakeholders: people who use Angel. From what I know, most people who use Angel are Haskellers so this seemed like the place. When Angel is terminated, it tries to cleanly shut down any processes it is monitoring. It also shuts down processes that it spawned when they are removed from the config and the config is reloaded via the HUP signal. It uses terminateProcess from System.Process which sends a SIGTERM to the program on *nix systems. The trouble is that SIGTERM can be intercepted and a process can still fail to shut down. Currently Angel issues the SIGTERM and hopes for the best. It also cleans pidfiles if there were any, which may send a misleading message. There are a couple of routes I could take: 1. Leave it how it is. Leave it to the user to make sure stubborn processes go away. I don't like this solution so much as it makes Angel harder to reason about from a user's perspective. 2. Send a TERM signal then wait for a certain number of seconds, then send an uninterruptable signal like SIGKILL. There are some caveats with #2. I think I'd prefer the timeout to be configurable per-process. I think I'd also prefer that if no timeout is specified, we assume the user does not want us to use a SIGKILL. SIGKILL can be very dangerous for some processes like databases. I want explicit user permission to do something like this. If Angel generated a pidfile for the process, if it should only be cleaned if Angel can confirm the process is dead. Otherwise they should be left so the user can handle it. So the real question: is the extra burden of an optional configuration flag per process worth this feature? Are my assumptions about path #2 reasonable. Thanks for your feedback! -- Michael Xavier http://www.michaelxavier.net

3 2

Do you want to maintain bindings-DSL?
by Maurício Antunes 13 Sep '13

13 Sep '13

Hi, bindings-DSL[1] is a stable and reliable macro package for FFI. It just got a new tutorial and its repository is now in git. If no one else wants to maintain it, I'll still be looking at issue reports and fixing possible problems, but I've not been actively using Haskell for some time, and won't add anything new or make plans for future changes. The original idea behind bindings-DSL was to build a wide set of community maintained raw bindings to interesting C libraries, on which Haskell programmers could safely depend when creating their own higher level packages. Although that idea never really took off, bindings-DSL itself got some popularity, probably because it makes instancing Storable easy. If you want to take maintenance, you have some options. You could just kill the bindings-* idea and add some flexibility to new macros, which I always avoided to enforce consistency. Or you could keep the original goal, and maybe add a mailing list and a web page where users could request new libraries and discuss solutions to trick issues. A possible plan for version 2 is to be independent of hsc2hs, and use a new syntax instead of C macros. Thanks. Best, Maurício [1]: http://bitbucket.org/mauricio/bindings-dsl

1 0