May 2013 - Haskell-Cafe

[ANN] Hac Phi 2013
by Daniel Wagner 23 May '13

23 May '13

Hac Phi 2013, a Haskell hackathon/get-together, will be held June 7-9 at the University of Pennsylvania in Philadelphia. The hackathon will officially kick off at 2:30 Friday afternoon, and go until 5pm on Sunday (with breaks for sleep, of course). Last year's Hac Phi was a lot of fun, drawing more than 30 Haskellers, and many people have already expressed interest in coming back this year. Everyone is welcome - you do not have to be a Haskell guru. Helping hack on someone else's project could be a great way to increase your Haskell-fu. If you plan on coming, please officially register [1]. Registration, travel, lodging and many other details can be found on the Hac Phi wiki [2]. This year, we are making a public list of attendees' names and nicks - please let us know if you'd prefer not to be listed when you register. We're also looking for a few people interested in giving short (15-20 min.) talks, probably on Saturday afternoon. Anything of interest to the Haskell community is fair game - a project you've been working on, a paper, a quick tutorial. If you'd like to give a talk, add it on the wiki [3]. Hope to see you in Philadelphia! - The Hac Phi team Brent Yorgey (byorgey) Daniel Wagner (dmwit) Chris Casinghino (ccasin) [1] http://www.haskell.org/haskellwiki/Hac_%CF%86/Register [2] http://www.haskell.org/haskellwiki/Hac_%CF%86 [3] http://www.haskell.org/haskellwiki/Hac_%CF%86/Talks

1 1

Second Call for Papers: Workshop on Functional Art, Music, Modeling, and Design (colocated with ICFP)
by Brent Yorgey 22 May '13

22 May '13

Please submit something to FARM --- the deadline is fast approaching! ====================================================================== FARM 2013: Call for Papers ACM SIGPLAN Workshop on Functional Art, Music, Modeling and Design Boston, Massachusetts, USA 28th September, 2013 (directly after ICFP) http://www.cis.upenn.edu/~byorgey/farm13/ ====================================================================== Scope ----- The functional programming community is largely interested in writing beautiful programs. This workshop is intended to gather researchers and practitioners interested in writing beautiful programs that generate beautiful artifacts. Such artifacts may include visual art, music, 3D sculptures, animations, GUIs, video games, physical models, architectural models, choreographies for dance, poetry, and even physical objects such as VLSI layouts, GPU configurations, or mechanical engineering designs. The framework used need not be purely functional (“mostly functional” is fine); may be based on abstractions such as higher-order functions, monads, arrows, or streams; and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications are all within the scope of the workshop. Important dates --------------- - Submissions due: Friday, 14 June 2013, 23:59 UTC-11 (American Samoa time [1]) - Author notification: Thursday, 11 July 2013 - Final papers due: Thursday, 25 July 2013 - Workshop: Saturday, 28 September 2013 (the day after ICFP) [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=FARM+submissions+d… Proceedings ----------- There will be a formal proceedings published by ACM Press. Accepted papers will be included in the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are also encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. Submission details ------------------ We solicit submissions in two categories: - Full papers. A full paper is limited to 12 pages, and will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions, identify what has been accomplished, explain why it is significant, and compare it with previous work. - "Aesthetic applications". An aesthetic application paper is limited to 6 pages, and will be judged primarily on the effective and elegant use of FP to generate aesthetic artifacts (though the criteria for full papers are still relevant). Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. Submissions can be made via EasyChair at https://www.easychair.org/conferences/?conf=farm2013 Organizers ---------- Workshop Chair: Paul Hudak Program Chair: Conal Elliott Publicity Chair: Brent Yorgey Program Committee ----------------- Daniel Cukier (University of São Paulo) Conal Elliott (Tabula) (chair) Kathleen Fisher (Tufts University) Richard Gabriel (IBM Research) George Giorgidze (University of Tübingen) Paul Hudak (Yale University) José Pedro Magalhães (University of Oxford) Alex McLean (University of Leeds) John Peterson (Western State Colorado University) Michael Sperber (Active Group) Henning Thielemann Brent Yorgey (University of Pennsylvania)

1 0

"Haskell from N00b to Real World Programmer"
by Mihai Maruseac 22 May '13

22 May '13

Hello, As hinted in the previous HCAR, this year we will organize an workshop entitled like the subject of this mail[1]. It will be organized by ROSEdu (Romanian Open Source Education) [2] and the newly founded Haskell-Romania group (no link yet, working on that). It is one workshop in a series of summer workshops organized by ROSEdu (go one level up in the wiki, some of them are in Romanian and I don't want to blindly give links to Romanian pages). The entire schedule is given on the wiki page at [1] and detailed below: Day 1 (8th of July) Introduction. History and Syntax. -- basic introduction to the language. Including @lambdabot usage as an example Programming with Static Typing as An Ally. -- designing with types and using GHCI for rapid prototyping and testing type of expressions. Possible to include @djinn Programming with State and Style. -- gentle introduction to monads in the style of "You could have invented monads" [3] Day 2 (9th of July) Packaging and Distributing Code. -- hackage, cabal, cabal-dev and, maybe, stackage The Awesome xmonad Window Manager -- we'll let them tweak configuration files in xmonad and use them. In this way, they get to use real world apps and change them to suit their needs. Maybe attract some developers. Compare and Contrast. Blow Your Mind with Haskell and Compare with Python. -- Starting with a comparison between some Python code and the equivalent Haskell one we get to cover topics in [4] Day 3 (11th of July) Lenses for Updating Details. -- you've guessed it, lenses Creating Graphical Interfaces. -- GTK2hs or lGTK. I'd like to test the second one Static Site Generation. -- Hakyll, config tweaking, generating first site, etc. Day 4 (12th of July) Beautiful Diagrams -- diagrams package Pipes and Conduits for Faster I/O -- pipes Creating Real-World Web Applications. -- Yesod (because that's what we know) Day 5 (13th of July) Hackathon Day If you have some suggestions, please make them. Lastly, for the hackathon day we have considered making some bots for I.GameBot[5] and an IRC bot with features that we'd like on #rosedu and #haskell-ro (grab, karma, resource location, statistics). If you'd have some other suggestions which could be implemented in a single day after the previous courses, please, do share them with us. Thanks and sorry for the length of the mail. [1]: http://workshop.rosedu.org/2013/sesiuni/haskell [2]: http://rosedu.org/ [3]: http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html [4]: http://www.haskell.org/haskellwiki/Blow_your_mind [5]: https://github.com/rosedu/I.GameBot -- MM "All we have to decide is what we do with the time that is given to us"

2 1

Functional JavaScript Opportunity in NYC
by Ryan Trinkle 22 May '13

22 May '13

Hi everyone, Our company, skedge.me, is looking for a full-time front-end developer in the NYC area. Our front-end is written in JavaScript, but our back-end is written in Haskell, so we're looking for people with solid JavaScript experience but also a strong interest in functional programming. No work experience in Haskell is required, but we do require all applicants to submit a small code sample - something on the scale of a Project Euler problem - in a statically-typed functional language in addition to a more traditional JavaScript code sample. We write all of our JavaScript in a functional style, and we use the Google Closure compiler to provide some type checking for us, so we're looking for people who enjoy working in an environment with a bit more structure than the average JavaScript project. For more information or to apply, visit http://skedge.me/careers or contact me at ryan(a)skedge.me. Ryan Trinkle

1 0

accessing a type variable in instance declaration
by TP 22 May '13

22 May '13

Hi all, I wonder if there is some means to get a type variable value in the body of a class instance definition. It seems it is not possible (a workaround has already been given on this list), but I would like a confirmation. For example, imagine that I have a Tensor type constructor, that takes a type-level integer (representing the Tensor order) to make a concrete type: --------- instance Show (Tensor order) where show TensorVar str = show "tensor " ++ str ++ " of order " ++ (show (c2num order)) ---------- where c2num transforms a type-level integer to an integer, through typeclasses (see http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue5/Number_Param_Typ…) I obtain a compilation error: order is not known in the body of the instance. Putting ScopedTypeVariable as extension does not change anything (http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/other-type-exte…) I have tried also using forall, without more success: ------------ instance forall order. Show (Tensor order) where show TensorVar str = show ”tensor ” ++ str ++ ” of order ” ++ (show (c2num order)) ------------ Thanks in advance, TP

2 3

Infrastructure for testing the impact of a Functor/Applicative/Monad hierarchy
by Niklas Hambüchen 22 May '13

22 May '13

Reading the other thread (Adding Applicative/Functor instances to all Monads in GHC) I was wondering if there was infrastructure for testing what effect making the often-discussed Functor/Monad change would have: How many packages on hackage would break etc. I have read a few times that people have "compiled all of hackage" to see the impact of whatever. How do you do that? Do you just run a loop around cabal install or have you built some more advanced tools to visualize the results better or compile the packages "from ground up", in order of their dependencies? I'm interested in anything in this direction.

3 3

Teaching FP with Haskell
by Rustom Mody 21 May '13

21 May '13

We are offering a MOOC on haskell : https://moocfellowship.org/submissions/the-dance-of-functional-programming-… Full Announcement on beginners list : http://www.haskell.org/pipermail/beginners/2013-May/012013.html One question that I have been grappling with in this regard: How to run ghc in lightweight/beginner mode? 2 examples of what I mean: 1. gofer used to come with an alternative standard prelude -- 'simple.pre' Using this, gofer would show many of the type-class based errors as simple (non-type-class based) errors. This was very useful for us teachers to help noobs start off without intimidating them. 2. Racket comes with a couple of levels. The easier numbers were not completely consistent with scheme semantics, but was gentle to beginners Any thoughts/inputs on this will be welcomed Rusi

4 3

parsing a CSV file
by Roger Mason 21 May '13

21 May '13

Hello, I'm attempting to write a parser for files that look like this: Bruker Nano GmbH Berlin, Germany Esprit 1.9 Date: 02/05/2013 10:06:49 AM Real time: 15000 Energy Counts -0.474 0 ..... The line before the ellipsis is repeated many times (such lines represents a spectrum). I need to be able to extract numbers from lines containing <string: > and I want to extract the number pairs following "Energy Counts\n". The extracted data will then be written to a file in a different format. For now I'll be satisfied with reading the "header" info, i.e. down to "Energy Counts\n". Thus far, I have: -- derived from RWH -- file: ch16/csv2.hs import Text.ParserCombinators.Parsec headerLines = endBy csvFile endHeader csvFile = endBy line eol line = sepBy cell (char ',') cell = many (noneOf ",\n") eol = char '\n' parseCSV :: String -> Either ParseError [[String]] parseCSV input = parse csvFile "(unknown)" input parseHDR :: String -> Either ParseError [[String]] parseHDR input = parse headerLines "(unknown)" input endHeader = string "Energy Counts" This loads into GHCi (7.6.2) OK. However, when I test it: parseHDR "Bruker Nano GmbH Berlin, Germany\nEsprit 1.9\n\nDate: 02/05/2013 10:06:49 AM\nReal time: 15000\nEnergy Counts" Not in scope: `parseHDR' which makes sense because ghci> :t endHeader <interactive>:1:1: Not in scope: `endHeader' Clearly, my naiive implementation of endHeader is no good. I appreciate any pointers. Thanks, Roger This electronic communication is governed by the terms and conditions at http://www.mun.ca/cc/policies/electronic_communications_disclaimer_2012.php

2 4

Announce: vsim the VHDL-subset simulator (unmaintained)
by Sergey Mironov 21 May '13

21 May '13

Hi. I'd like to announce the vsim - the simulator for (small subset of) VHDL language. Currently the project contains pretty large Java part and is not maintained. That's why I don't want to publish it on Hackage. Still, as far as I now have a permission to share the code, I would like to do it. https://github.com/grrwlf/vsim VSim is a VHDL simulator project aimed develop a methods of compiling VHDL code into a high-level language (Haskell). Currently it is able to compile simple VHDL programs, containing plain integer types, 1-dimentional arrays, records. It supports processes, procedures, functions (partly). Breakpoints and wait statements should work. Simulator compile VHDL into Haskell in several steps. Firstly, VHDL is translated into VIR-file by a translator written in Java (see tr/ folder and runtr function in ./simenv shell script). VIR file is lisp-like file, describing vhdl entities in a less complex manner. For example, it contains all the port maps expanded. Secondly, VSim tool is used to translate VIR into Haskell (see src/ folder and runsim functino in ./simenv). VSim is a small program which translates VIR line-by-line into Haskell program. haskell-src-exts is used to build the AST and print it to stdout. Finaly, Haskell program should be compiled into binary with ghc having runtime library included (refer to src\_r/ folder and runsim function in ./simenv). The runtime is the heart of the simulator and it's largest part. Java part is a main headache, because it is big, unsupported and has bugs lurking here and there. Haskell part is smaller and cleaner, but VHDL-standard coverage is still poor. For example, signal assignments are working as if they are declared with transport delay mechanism. Another problem is missing enum support except of some pre-defined. Sergey

1 0

Re: [Haskell-cafe] rip in the class-abstraction continuum
by oleg＠okmij.org 21 May '13

21 May '13

Type classes are the approach to constrain type variables, to bound polymorphism and limit the set of types the variables can be instantiated with. If we have two type variables to constrain, multi-parameter type classes are the natural answer then. Let's take this solution and see where it leads to. Here is the original type class > class XyConv a where > toXy :: a b -> [Xy b] and the problematic instance > data CircAppr a b = CircAppr a b b -- number of points, rotation angle, radius > deriving (Show) > > instance Integral a => XyConv (CircAppr a) where > toXy (CircAppr divns ang rad) = > let dAng = 2 * pi / (fromIntegral divns) in > let angles = map ((+ ang) . (* dAng) . fromIntegral) [0..divns] in > map (\a -> am2xy a rad) angles To be more explicit, the type class declaration has the form > class XyConv a where > toXy :: forall b. a b -> [Xy b] with the type variable 'b' universally quantified without any constraints. That means the user of (toXy x) is free to choose any type for 'b' whatsoever. Obviously that can't be true for (toXy (CircAppr x y)) since we can't instantiate pi to any type. It has to be a Floating type. Hence we have to constrain b. As I said, the obvious solution is to make it a parameter of the type class. We get the first solution: > class XYConv1 a b where > toXy1 :: a b -> [Xy b] > > instance (Floating b, Integral a) => XYConv1 (CircAppr a) b where > toXy1 (CircAppr divns ang rad) = > let dAng = 2 * pi / (fromIntegral divns) in > let angles = map ((+ ang) . (* dAng) . fromIntegral) [0..divns] in > map (\a -> am2xy a rad) angles The type class declaration proclaims that only certain combinations of 'a' and 'b' are admitted to the class XYConv1. In particular, 'a' is (CircAppr a) and 'b' is Floating. This reminds us of collections (with Int keys, for simplicity) > class Coll c where > empty :: c b > insert :: Int -> b -> c b -> c b > > instance Coll M.IntMap where > empty = M.empty > insert = M.insert The Coll declaration assumes that a collection is suitable for elements of any type. Later on one notices that if elements are Bools, they can be stuffed quite efficiently into an Integer. If we wish to add ad hoc, efficient collections to the framework, we have to restrict the element type as well: > class Coll1 c b where > empty1 :: c > insert1 :: Int -> b -> c -> c Coll1 is deficient since there is no way to specify the type of elements for the empty collection. When the type checker sees 'empty1', how can it figure out which instance for Coll1 (with the same c but different element types) to choose? We can help the type-checker by declaring (by adding the functional dependency c -> b) that for each collection type c, there can be only one instance of Coll1. In other words, the collection type determines the element type. Exactly the same principle works for XYConv. > class XYConv2 a b | a -> b where > toXy2 :: a -> [Xy b] > > instance (Floating b, Integral a) => XYConv2 (CircAppr a b) b where > toXy2 (CircAppr divns ang rad) = > let dAng = 2 * pi / (fromIntegral divns) in > let angles = map ((+ ang) . (* dAng) . fromIntegral) [0..divns] in > map (\a -> am2xy a rad) angles The third step is to move to associated types. At this stage you can consider them just as a different syntax of writing functional dependencies: > class XYConv3 a where > type XYT a :: * > toXy3 :: a -> [Xy (XYT a)] > > instance (Floating b, Integral a) => XYConv3 (CircAppr a b) where > type XYT (CircAppr a b) = b > toXy3 (CircAppr divns ang rad) = > let dAng = 2 * pi / (fromIntegral divns) in > let angles = map ((+ ang) . (* dAng) . fromIntegral) [0..divns] in > map (\a -> am2xy a rad) angles The step from XYConv2 to XYConv3 is mechanical. The class XYConv3 assumes that for each convertible 'a' there is one and only Xy type 'b' to which it can be converted. This was the case for (CircAppr a b). It may not be the case in general. But we can say that for each convertible 'a' there is a _class_ of Xy types 'b' to which they may be converted. This final step brings Tillmann Rendel's solution.

1 0