January 2014 - Haskell-Cafe

Naming scheme for partial functions
by Michael Snoyman 15 Feb '14

15 Feb '14

Greg Weber and I have been discussing some changes to mono-traversable[1]. One of the modules we provide is Data.NonNull, which provides total versions of functions like `last`. A change we're looking at would require having a partial version of `last` defined in a separate typeclass (IsSequence), which would allowing for more optimized implementations of the total `last` function for datatypes which support it (e.g., strict ByteStrings). But what should we name it? I'm sure everyone's familiar with the `unsafe` naming convention, but that's not appropriate here: standard usage shows `unsafe` meaning a function which can cause a segfault. I initially named it `partialLast`, but partial can also imply partial function application. Greg brought up the idea of suffixing the function with something like `Throws` or `Errors`, which I think I'm a bit partial to myself[2]. So my questions are: * Is there some already used naming scheme out there for partial functions which I've missed? * Do people have any ideas to throw into the mix? Michael [1] https://github.com/snoyberg/mono-traversable/pull/21 [2] Pardon the pun.

4 8

Unmaintained packages and hackage upload rights
by Roman Cheplyaka 09 Feb '14

09 Feb '14

In the recent past I took over two unmaintained packages: bert and ansi-terminal. I don't mind spending a bit of time to keep our ecosystem from bitrotting. However, both times I had to go through an irritating procedure of contacting hackage admins, asking them to grant me upload rights, explaining why the maintainers can't do that themselves and why I think the packages are abandoned. Instead of a feeling that I'm doing something good and useful, I have a feeling that I'm bothering people with my own problems. It also adds unnecessary latency to my work. So from now on I'll simply fork the packages I need to fix. Others are of course welcome to use my forks. (This email was prompted by regex-tdfa which doesn't build on GHC 7.8, and whose maintainer hasn't responded. My fork is at http://hackage.haskell.org/package/regex-tdfa-rc .) Roman

21 56

Generalized null / zero
by Alvaro J. Genial 06 Feb '14

06 Feb '14

1. Is there a more general version of `null`? (e.g. for a Monad, Functor, Applicative, Traversable or the like.) The closest I can come up with is, in decreasing clunkiness: zero :: (MonadPlus m, Eq (m a)) => m a -> Bool zero = m == mzero zero :: (Alternative f, Eq (f a)) => f a -> Bool zero = m == empty zero :: (Monoid m, Eq m) => m -> Bool zero = m == mempty Though requiring Eq seems ugly and unnecessary, in theory. 2. In that vein, is there an existing function for "a value or a default if it's zero"? E.g.: orElse :: (Monoid m) => m -> m -> m a `orElse` b = if zero a then b else a Thank you, Alvaro http://alva.ro

7 8

Dispatch a type-function on the existence (or not) of instances?
by Hans Höglund 03 Feb '14

03 Feb '14

Dear all, I have been curious about the ability to detect the presence of a certain instance (ClassFoo TypeBar) in the type system. Specifically, is it possible to "dispatch" a type on the existence (or not) of such an instance. For example given two functions: withInstance :: (ClassFoo TypeBar) => TypeIfInstanceExists withoutInstance :: TypeIfInstanceDoesNotExists I would be able to consolidate them into something like this: withOrWithoutInstance :: (r ~ InstanceExists ClassFoo TypeBar, a ~ If r TypeIfInstanceExists TypeIfInstanceDoesNotExists) => a I guess what I need is: 1) A type-level "if". 2) The possibility of "converting" a constraint into a type-level bool. I am sure (1) is possible but have no idea about (2). Anyone? Best regards, Hans

2 2

What game libraries should I use?
by Alexander Berntsen 02 Feb '14

02 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I need: - -2D graphics (preferably with simple shapes available) - -menus (I can make menus myself with shapes though) - -simple audio - -fonts (better than Gloss at least) - -keyboard input - -networking (simple direct connections between two computers) I need to be able to express my game system as declaratively as possible[0]. If the library is based on SDL/OpenGL, that would be nice[1]. This is, however, not necessary. What game libraries are the most mature and adequate for this? The only library I have used previously with Haskell is Gloss. I am not experienced in FRP, though I have read about and somewhat groked the point. I am willing to learn an FRP library. [0] I am writing it as part of a thesis in which I will look at the modularity and expressiveness of purely functional programming compared to object-oriented programming. Writing code that is technically purely functional, but in practice looks like imperative code, is sub-optimal. [1] For the thesis I am writing, I am implementing a C++ version of the same game. This will probably use SDL 2.0 and OpenGL bindings. If the Haskell version could use libraries based on that, this would make it easier for me to write my thesis. I.e., I would not have to spend time justifying that the modularity and expressiveness I am investigating is due to the chosen languages and programming paradigms, and not the libraries I use. - -- Alexander alexander(a)plaimi.net http://plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLrlMoACgkQRtClrXBQc7VkiAEAnEbfjiSLovcXttmjpdD5OSFI uEMBVBJdWonY9ZMPIc8BAIAQn+YMRvGILgb8WmuB9oTWJDVZfqDMyB47qzjyfimO =YGLW -----END PGP SIGNATURE-----

5 5

Cabal version constraint seems to be ignored.
by Carlo Hamalainen 31 Jan '14

31 Jan '14

Hi, I have two versions of Cabal, both are visible: $ ghc-pkg expose Cabal-1.16.0 $ ghc-pkg expose Cabal-1.18.1.2 I clone and build my package. Since I have GHC 7.6.3 it uses Cabal-1.16.0 (as specified in ghc-imported-from.cabal): $ git clone https://github.com/carlohamalainen/ghc-imported-from $ cd ghc-imported-from $ cabal install It looks like Cabal-1.16.0 was chosen, as expected: $ grep Cabal dist/build/autogen/cabal_macros.h /* DO NOT EDIT: This file is automatically generated by Cabal */ /* package Cabal-1.16.0 */ #define VERSION_Cabal "1.16.0" #define MIN_VERSION_Cabal(major1,major2,minor) (\ But my program doesn't run: $ ghc-imported-from src/Main.hs Main getArgs 11 11 --ghc-options --ghc-pkg-options GhcOptions [] GhcPkgOptions [] Language/Haskell/GhcImportedFrom.hs:132:54: Couldn't match expected type `Distribution.PackageDescription.BuildInfo' with actual type `Cabal-1.16.0:Distribution.PackageDescription.BuildInfo' In the fourth argument of `getGHCOptions', namely `binfo' In a stmt of a 'do' block: getGHCOptions [] c (fromJust $ cradleCabalDir c) binfo In the expression: do { c <- findCradle; pkgDesc <- GhcMonad.liftIO $ parseCabalFile $ fromJust $ cradleCabalFile c; let binfo = head $ cabalAllBuildInfo pkgDesc; getGHCOptions [] c (fromJust $ cradleCabalDir c) binfo } I'm surprised that the error didn't appear at compile time. I guess the first reference to Distribution.PackageDescription.BuildInfo is from Cabal-1.18.1.2? If I hide Cabal-1.18.1.2 then things work ok: $ ghc-pkg hide Cabal-1.18.1.2 $ cabal install $ ghc-imported-from .... (runs as expected) But I can't expect a user to know that they have to hide Cabal-1.18.1.2. Is this actually a GHC bug or have I stuffed up my ghc-imported-from.cabal file? Thanks, -- Carlo Hamalainen http://carlo-hamalainen.net

3 4

TFP 2014 - 2nd call for papers
by Peter Achten 31 Jan '14

31 Jan '14

--------------------------------- 2ND C A L L F O R P A P E R S --------------------------------- ======== TFP 2014 =========== 15th Symposium on Trends in Functional Programming May 26-28, 2014 Utrecht University Soesterberg, The Netherlands http://www.cs.uu.nl/wiki/TFP2014/WebHome *** Submission for TFP 2014 is now open: please direct your browser to *** http://www.cs.uu.nl/wiki/TFP2014/PaperSubmission The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below), described in draft papers submitted prior to the symposium. A formal post-symposium refereeing process then selects a subset of the articles presented at the symposium and submitted for formal publication. Selected revised papers will be published as a Springer Lecture Notes in Computer Science (LNCS) volume. TFP 2014 will be the main event of a pair of functional programming events. The other is the International Workshop on Trends in Functional Programming in Education (TFPIE). TFPIE will take place on May 25th. Its website is located at http://www.cs.uwyo.edu/~jlc/tfpie14/ The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in Edinburgh (Scotland) in 2003, in Munich (Germany) in 2004, in Tallinn (Estonia) in 2005, in Nottingham (UK) in 2006, in New York (USA) in 2007, in Nijmegen (The Netherlands) in 2008, in Komarno (Slovakia) in 2009, in Oklahoma (USA) in 2010, in Madrid (Spain) in 2011, St. Andrews (UK) in 2012 and Provo (Utah, USA) in 2013. For further general information about TFP please see the TFP homepage. INVITED SPEAKERS TFP is pleased to announce talks by the following two invited speakers: John Hughes of Chalmers, Goteborg, Sweden, is well-known as author of Why Functional Programming Matters, and as one of the designers of QuickCheck (together with Koen Claessen); the paper on QuickCheck won the ICFP Most Influential Paper Award in 2010. Currently he divides his time between his professorship and Quviq, a company that performs property-based testing of software with a tool implemented in Erlang. Dr. Geoffrey Mainland received his PhD from Harvard University where he was advised by Greg Morrisett and Matt Welsh. After a two year postdoc with the Programming Principles and Tools group at Microsoft Research Cambridge, he is now an assistant professor at Drexel University. His research focuses on high-level programming language and runtime support for non-general purpose computation. SCOPE The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Using functional techniques to reason about imperative/object-oriented programs Debugging for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2014 program chair, Jurriaan Hage at J.Hage(a)uu.nl. BEST PAPER AWARDS To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. SPONSORS TFP is financially supported by NWO (Netherlands Organisation for Scientific Research), Well-Typed and Erlang Solutions. PAPER SUBMISSIONS Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (16 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate whether the main author or authors are research students. In the case of a FULL STUDENT paper, the draft paper will receive additional feedback by one of the PC members shortly after the symposium has taken place. We use EasyChair for the refereeing process. IMPORTANT DATES Submission of draft papers: March 17, 2014 Notification: March 24, 2014 Registration: April 7, 2014 TFP Symposium: May 26-28, 2014 Student papers feedback: June 9th, 2014 Submission for formal review: July 1st, 2014 Notification of acceptance: September 8th, 2014 Camera ready paper: October 8th, 2014 PROGRAM COMMITTEE Peter Achten Radboud University Nijmegen Emil Axelsson Chalmers Lucilia Camarao de Figueiredo Universidade Federal de Ouro Preto Laura Castro University of A Coruna Frank Huch Christian-Albrechts-University of Kiel Matthew Fluet Rochester Institute of Technology Jurriaan Hage (chair) University of Utrecht Yukiyoshi Kameyama University of Tsukuba Andrew Kennedy Microsoft Research Tamas Kozsik Eotvos Lorand University Ben Lippmeier University of New South Wales Luc Maranget INRIA Jay McCarthy (co-chair) Brigham Young University Marco T. Morazan Seton Hall University Ricardo Pena Universidad Complutense de Madrid Alexey Rodriguez LiquidM Sven-Bodo Scholz Heriot-Watt University Manuel Serrano INRIA Sophia Antipolis Simon Thompson University of Kent Tarmo Uustalu Inst of Cybernetics David Van Horn University of Maryland Janis Voigtlaender University of Bonn

1 0

Re: [Haskell-cafe] manage effects in a DSL
by oleg＠okmij.org 31 Jan '14

31 Jan '14

> - What do you mean by "The type Cont Int a describes an impure computation, > which may abort with an Int value, for example". > Aborting with an Int value is akin to exceptions? I see that using Cont monad wasn't a good idea. The point can be made simply, with an Error monad or applicative. Here is a simple function to multiply a list of integers: > muls :: [Integer] -> Either e Integer > muls [] = pure 1 > muls (h:t) = (h*) <$> muls t We give the signature (which the compiler accepts) with the polymorphic return type Either e Integer, fully polymorphic over e. Therefore, muls throws no exceptions. Here is a bit more optimized function, which stops all multiplications once zero is encountered. > mulse :: [Integer] -> Either Integer Integer > mulse [] = pure 1 > mulse (0:t) = Left 0 > mulse (h:t) = (h*) <$> mulse t We cannot make the return type (Either e Integer), it must be (Either Integer Integer). The function can indeed throw an exception. If we handle the exception > muls' :: [Integer] -> Either e Integer > muls' l = either pure pure $ mulse l the effect is encapsulated and the type is polymorphic again. > - for me it's not clear when to choose an "applicative" or a "monadic" DSL? > Betsides, what's the rational behind the name "let_" (never seen it before)? The first rule of thumb is to use the simplest structure that does the job. Another good rule is to distinguish the DSL from its implementation. For example, the DSL below http://okmij.org/ftp/tagless-final/index.html#call-by-any has no monads. It is a simple lambda-calculus with constants. Its implementation in Haskell, the embedding, does use monads, sometimes quite specific monads (e.g., IO, to print the trace of evaluation). But these monads are not exposed to the DSL programmer. That article also shows off let_. > data Eff = Effect | NoEffect > -- first type parameter is used to track effects > data Exp :: Eff -> * -> * where > ReadAccount :: Exp r Int --ReadAccount can be used in whatever > monad (with or without effect) > WriteAccount :: Exp NoEffect Int -> Exp Effect () --WriteAccount > takes an effect-less expression, and returns an effectfull expression This is exactly what I had in mind (and probably Jacques as well). > Other pointers where this idiom is realised?? Lots of places; ST monad comes to mind, and the Region monad. This trick is often used to track, for example, information flow security (the label then reflects the sensitivity level of data processed by the computation, Low or High). See, for example, http://www.cse.chalmers.se/~russo/seclib.htm http://www.scs.stanford.edu/~deian/pubs/stefan:2011:flexible-slides.pdf or just search for information flow control or information flow security in Haskell. Edward Yang has a lot to say on this topic.

1 0

liboleg
by Suhail Shergill 30 Jan '14

30 Jan '14

hi, i would like to take over as maintainer of the liboleg package on hackage <http://hackage.haskell.org/package/liboleg>. i have gotten permission from the author (oleg) and the current maintainer (don) regarding the same via email. my hackage username is shergill. if there are no objections, could i be added to the maintainer group for liboleg and be granted upload rights? -- Suhail

3 4

Deprecating bytestring version 0.10.2.0
by Christian Laustsen 30 Jan '14

30 Jan '14

Hi everyone, Following some problems I experienced with Network.HTTP.Client.TLS, I found out the problem was specific to bytestring library version 0.10.2.0 and most likely fixed with this commit https://github.com/haskell/bytestring/commit/86df1f17b2332940df69f484182c5c… . The default version shipped with GHC 7.6.3 (0.10.0.2) works fine, and the version after 0.10.2.0 (that is, version 0.10.4.0) also works. It was suggested that I mention on here that I think we should deprecate the 0.10.2.0 version of bytestring specifically, since that is the one that introduces the problem, and there can be problems with having to specify specific versions of bytestring as a dependency when compiling across GHC versions. -- Christian // Tehnix

2 1