May 2014 - Haskell-Cafe

Imports at bottom, why not?
by Thiago Negri 20 May '14

20 May '14

When reading code, I find it quite distracting to have to get past the import list to reach the actual module code, as the import list can be (and often is) quite big. So, why not issue import statements at the bottom of a module file? Likewise, we can use "where" statements to define names used in a function after using them, so they don't distract the reader. I'm against imports at the middle of the file. But I guess being able to issue them at the end of the module could make sense if you want to get the reader straight to the code. A language pragma could be used to select between top imports or bottom imports (can't use both). What do you think? Example: """ {-# LANGUAGE LateImports #-} module Foo where bar :: String bar = "quux" baz :: Fiz baz = mkFiz import Fiz (Fiz, mkFiz) """

13 16

ML Family workshop - Extended deadline
by oleg＠okmij.org 20 May '14

20 May '14

Extended submission deadline: May 23 (Friday), any time zone Four more days to write a 2-page abstract Submissions of demos, case studies and informed opinions are particularly encouraged! Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop Thursday September 4, 2014, Gothenburg, Sweden (immediately following ICFP and preceding OCaml Users and Developers Workshop) Call For Papers http://okmij.org/ftp/ML/ML14.html ML is a very large family of programming languages that includes Standard ML, OCaml, F#, SML#, Manticore, MetaOCaml, JoCaml, Alice ML, Dependent ML, Flow Caml, and many others. All ML languages, beside the great deal of syntax, share several fundamental traits. They are all higher-order, strict, mostly pure, and typed, with algebraic and other data types. Their type systems inherit from Hindley-Milner. The development of these languages has inspired a significant amount of computer science research and influenced a number of programming languages, including Haskell, Scala and Clojure, as well as Rust, ATS and many others. ML workshops have been held in affiliation with ICFP continuously since 2005. This workshop specifically aims to recognize the entire extended ML family and to provide the forum to present and discuss common issues, both practical (compilation techniques, implementations of concurrency and parallelism, programming for the Web) and theoretical (fancy types, module systems, metaprogramming). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Scala, Rust, Nemerle, ATS, etc.), to exchange experience of further developing ML ideas. The ML family workshop will be held in close coordination with the OCaml Users and Developers Workshop. Format Since 2010, the ML workshop has adopted an informal model. Presentations are selected from submitted abstracts. There are no published proceedings, so any contributions may be submitted for publication elsewhere. We hope that this format encourages the presentation of exciting (if unpolished) research and deliver a lively workshop atmosphere. Each presentation should take 20-25 minutes, except demos, which should take 10-15 minutes. The exact time will be decided based on the number of accepted submissions. The presentations will likely be recorded. Post-conference proceedings The post-proceedings of selected papers from the ML Family and the OCaml Users and Developers workshops will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). The Program Committee shall invite interested authors of selected presentations to expand their abstract for inclusion in the proceedings. The submissions are to be reviewed according to the EPTCS standards. Coordination with the OCaml Users and Developers Workshop The OCaml workshop is seen as more practical and is dedicated in significant part to the OCaml community building and the evolution of the OCaml system. In contrast, the ML family workshop is not focused on any language in particular, is more research oriented, and deals with general issues of the ML-style programming and type systems. Yet there is an overlap, which we are keen to explore in various ways. The authors who feel their submission fits both workshops are encouraged to mention it at submission time or contact the Program Chairs. Scope We acknowledge the whole breadth of the ML family and aim to include languages that are closely related (although not by blood), such as Rust, ATS, Scala, Typed Clojure. Those languages have implemented and investigated run-time and type system choices that may be worth considering for OCaml, F# and other ML languages. We also hope that the exposure to the state of the art ML might favorably influence those related languages. Specifically, we seek research presentations on topics including but not limited to * Design: concurrency, distribution and mobility, programming for the web and embedded systems, handling semi-structured data, facilitating interactive programming, higher forms of polymorphism, generic programming, objects * Implementation: compilation techniques, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, etc. * Type systems: fancy types, inference, effects, overloading, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc. * Applications: case studies, experience reports, pearls, etc. * Environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc. * Education: ML and ML-like languages in college or high-school, in general or computer science curriculum. Four kinds of submissions will be accepted: Informed Positions, Research Presentations, Experience Reports and Demos. * Informed Positions: A justified argument for or against a language feature. The argument must be substantiated, either theoretically (e.g., by a demonstration of (un)soundness, an inference algorithm, a complexity analysis), empirically or by a substantial experience. Personal experience is accepted as justification so long as it is extensive and illustrated with concrete examples. * Research Presentations: Research presentations should describe new ideas, experimental results, or significant advances in ML-related projects. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. These presentations should be structured in a way which can be, at least in part, of interest to (advanced) users. * Experience Reports: Users are invited to submit Experience Reports about their use of ML and related languages. These presentations do not need to contain original research but they should tell an interesting story to researchers or other advanced users, such as an innovative or unexpected use of advanced features or a description of the challenges they are facing or attempting to solve. * Demos: Live demonstrations or short tutorials should show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or applications built on or related to ML. (You will need to provide all the hardware and software required for your demo; the workshop organizers are only able to provide a projector.) Important dates Friday May 23 (any time zone): Abstract submission Monday June 30: Author notification Thursday September 4, 2014: ML Family Workshop Submission Submissions should be at most two pages, in PDF format, and printable on US Letter or A4 sized paper. A submission should have a synopsis (2-3 lines) and a body between 1 and 2 pages, in one- or two-column layout. The synopsis should be suitable for inclusion in the workshop program. Submissions must be uploaded to the workshop submission website before the submission deadline (Monday May 19, 2014). For any question concerning the scope of the workshop or the submission process, please contact the program chair. Program Committee Kenichi Asai Ochanomizu University, Japan Matthew Fluet Rochester Institute of Technology, USA Jacques Garrigue Nagoya University, Japan Dave Herman Mozilla, USA Stefan Holdermans Vector Fabrics, Netherlands Oleg Kiselyov (Chair) Monterey, CA, USA Keiko Nakata Tallinn University of Technology, Estonia Didier Remy INRIA Paris-Rocquencourt, France Zhong Shao Yale University, USA Hongwei Xi Boston University, USA

1 0

Making the encoding Haskell package compile with ghc-7.8.2
by José Romildo Malaquias 20 May '14

20 May '14

Hello. I use encodign in a Haskell application and I would like to have it working with ghc-7.8.2. So I am kindly asking to, if possible, update the encoding package[1] to be compilable with ghc-7.8.2. Currently it fails with the messages: [...] * Prepending /usr/lib64/ghc-7.8.2 to LD_LIBRARY_PATH /usr/bin/ghc -package Cabal-1.20.0.0 --make /tmp/portage/dev-haskell/encoding-0.7/work/encoding-0.7/Setup.hs -dynamic -o setup [1 of 8] Compiling Data.Static ( Data/Static.hs, Data/Static.o ) Data/Static.hs:39:28: Couldn't match expected type ‘Bool’ with actual type ‘Int#’ In the expression: eqWord# v (int2Word# 4294967295#) In the expression: if eqWord# v (int2Word# 4294967295#) then Nothing else (if (I# (word2Int# v)) > 1114111 then error (show (I# (word2Int# v)) ++ " is not a valid char (" ++ show (I# i) ++ ")") else Just (chr (I# (word2Int# v)))) /usr/bin/ghc -package Cabal-1.20.0.0 --make /tmp/portage/dev-haskell/encoding-0.7/work/encoding-0.7/Setup.hs -o setup [1 of 8] Compiling Data.Static ( Data/Static.hs, Data/Static.o ) Data/Static.hs:39:28: Couldn't match expected type ‘Bool’ with actual type ‘Int#’ In the expression: eqWord# v (int2Word# 4294967295#) In the expression: if eqWord# v (int2Word# 4294967295#) then Nothing else (if (I# (word2Int# v)) > 1114111 then error (show (I# (word2Int# v)) ++ " is not a valid char (" ++ show (I# i) ++ ")") else Just (chr (I# (word2Int# v)))) Regards, Romildo

1 1

ANNOUNCE: New OpenGL packages
by Sven Panne 19 May '14

19 May '14

New versions of the OpenGL packages are available on Hackage: * OpenGLRaw 1.5.0.0 * GLURaw 1.4.0.1 * OpenGL 2.9.2.0 * GLUT 2.5.1.1 Cheers, S. ====================================================================== Changes in the OpenGLRaw package ====================================================================== * Don't rely on K&R features in CPP, making things easier for Mac/clang users. * Added support for OpenGL 3.2's glGetInteger64i_v and the following extensions, so now all parts of OpenGL 4.1 are supported (plus a few more): APPLE_flush_buffer_range APPLE_vertex_array_object ARB_blend_func_extended ARB_gpu_shader_fp64 ARB_sampler_objects ARB_shader_subroutine ARB_shading_language_include ARB_texture_compression_bptc ARB_texture_rgb10_a2ui ARB_texture_swizzle ARB_transform_feedback2 ARB_vertex_attrib_64bit ARB_vertex_type_2_10_10_10_rev EXT_draw_buffers2 EXT_framebuffer_blit EXT_framebuffer_multisample EXT_gpu_shader4 EXT_packed_stencil_depth EXT_texture_array EXT_texture_compression_rgtc EXT_texture_shared_exponent EXT_transform_feedback * Made naming more consistent: Abgr => ABGR Bgra => BGRA Cmyka => CMYKA Dxt1 => DXT1 Fp => FP Gpu => GPU Latc => LATC Lod => LOD S3tc => S3TC Vtc => VTC ====================================================================== Changes in the GLURaw package ====================================================================== * Don't rely on K&R features in CPP, making things easier for Mac/clang users. ====================================================================== OpenGL 2.9.2.0 ====================================================================== * Added generateMipmap’, a modern version of the deprecated generateMipmap. * Added a few missing IndexedBufferTargets. * indexedBufferSize and indexedBufferStart correctly use 64bit queries now. * Setting bindBufferRange handles Nothing correctly now. * Added missing Eq/Ord/Show instances for a few data types. ====================================================================== Changes in the GLUT package ====================================================================== * Don't rely on K&R features in CPP, making things easier for Mac/clang users. * Added ColorTriange example.

1 0

Haskell Developer - Job Opening - New York, NY
by Ryan Trinkle 19 May '14

19 May '14

skedge.me is seeking a Haskell developer to improve and maintain our Snap-based web application stack. skedge.me is committed to using the best tool for the job throughout our software stack. That includes a mixture of cutting-edge tools like Haskell and the Nix package manager as well as tried-and-true products like PostgreSQL and Linux. Your role will be to find, use, and create tools like these to build a robust and powerful software platform to serve our clients' needs. This job requires that you be able to hit the ground running with Haskell. As part of your application, please submit a small to medium sized code sample (approximately 100 to 1000 lines) demonstrating your ability to write clear, concise, and efficient Haskell code, together with a brief English explanation of what the code does, how it works, and how to build and run it. Your Haskell code is our primary consideration in reviewing your application. However, experience with PostgreSQL, Linux, NixOS, web server programming, Varnish, AWS or other similar technologies is a plus. It is also a plus if you are local to the NYC area, as our offices are located in Midtown. To apply, please email me your resume and code sample at ryan(a)skedge.me. Ryan

1 0

Constants in Class definitions - could not deduce
by martin 18 May '14

18 May '14

Hello all, in my attempt to solve a Calendar related problem, I wanted to define Months and Weekdays such that I can increment a value. Unlike the "succ" Funktion in Enum my "inc" function shall circle endlessly. I came up with the following class (Ix a, Enum a) => Incrementable a where from :: a to :: a inc :: a -> a inc x = [from .. to] !! ((1 + index (from, to) x) `mod` rangeSize (from,to)) but GHC complains: /home/martin/projects/haskell/euler/p19.hs:39:65: Could not deduce (Ix a0) arising from a use of `rangeSize' from the context (Incrementable a) I suppose this is because GHC does not know that I want "to" and "from" to be taken from the same instance as x. If I replace the signature of "from" by "a -> a" and implement it by using a function which throws aways its argument, the types become clear and GHC no longer complains. Alternatively I can omit the implementation of "inc" in the class and leave that to the instances. I can easily fix the types in the instances, but this leads to some code duplication. I tried (from::a) to fix the type, but this had no effect. How is this done correctly?

3 3

Conduits vs. lazy byte strings
by Mike Meyer 18 May '14

18 May '14

I'm working on a web app that loads a file, tweaks it a bit, then downloads the results. I'd like for it to use the minimal amount of memory possible, just as good practice. Especially since the tweaking all happens in the first K or so of the file, and the rest of it is passed through untouched. The current version uses a conduit that just reads the data to a sinkLbs to get a lazy bytestring, which is then processed. I think this will have the desired behavior (after all, the bytestring is lazy), but have this itch that says I should be doing the processing in the conduit. Someone want to tell me if I correctly understand things and the itch is just leftover imperative thinking, or the itch is right and I need to fix the code? If you're intersted, you can find the code at https://www.fpcomplete.com/user/mwm/xyzifiy

2 1

Packaging Haskell Environment for Mac App
by Andrew Gibiansky 18 May '14

18 May '14

Hey all, [This is an xpost from Reddit, where the post<http://www.reddit.com/r/haskell/comments/24hct1/packaging_haskell_platform_…>seems not to be showing up for some reason...] I'd like to package the Haskell Platform and GHC (for GHC API) together in one bundle in order to distribute it with a Mac app. (Specifically, I am working on a Mac app for IHaskell <https://github.com/gibiansky/IHaskell>, so beginners can download that to immediately get started playing with Haskell). Does anyone have any experience with this? What's the easiest way to do this? My list of dependencies is fairly long: - Haskell Platform (well, all packages in it) - A few other packages installed via cabal - A native library (libzmq); cabal packages depend on it - Functioning Python > 2.6ish - GHC API My current best idea is to package this all in a Virtualbox VM. I need to run a server that my Mac app client can use, so mount shared folders in the VM so that the VM can read/write to disk and expose some ports from the VM. If this is the best solution, what Linux distro would you suggest to use in the VM? I'd want something very lightweight. I've also considered using Docker somehow, as IHaskell is already packaged with a Dockerfile. However, I'm not sure how I'd package docker so that its all doable via a single Mac app install. Ideas? Suggestions? Thanks! I know this isn't *directly* related to Haskell, but I'm hoping someone here has experience packaging Haskell applications. -- Andrew Gibiansky

4 5

System.Process and -threaded
by Karsten Gebbert 18 May '14

18 May '14

Hello, I'm writing a little networking wrapper around a sub-process (mplayer -idle -slave) and I'm running into some issues with the System.Process API. This is the program: > module Main where > > import System.IO > import System.Process > import Network.Socket hiding (recv) > import Network.Socket.ByteString > import Control.Concurrent > import qualified Data.ByteString.Char8 as C > > -- WARNING: when compiled with -threaded, this program is likely not going > -- to work. As soon as one writes to the stdin of the forked process, it > -- zombifies and any other command with crash this program. > > main = withSocketsDo $ do > -- network stuff > addrinfos <- getAddrInfo Nothing (Just "localhost") (Just "4000") > let serveraddr = head addrinfos > sock <- socket (addrFamily serveraddr) Stream defaultProtocol > bindSocket sock (addrAddress serveraddr) > listen sock 1 > > -- mplayer > (hand,o,e,pid) <- runInteractiveProcess "mplayer" ["-fs", "-idle", "-slave"] Nothing Nothing > hSetBinaryMode hand False > hSetBuffering hand LineBuffering > > putStrLn "listening for commands" > loop sock hand > > -- closing everything down > sClose sock > terminateProcess pid > waitForProcess pid > return () > > loop sock hand = do > (conn, _) <- accept sock > str <- recv conn 2048 > > putStr $ "received: " ++ C.unpack str > > -- write command to handler > hPutStr hand $ C.unpack str > > sClose conn > loop sock hand When compile with -threaded, the mplayer process gets zombified and hangs until I shut down the program. When compiled with non-threaded RTS (thats whats its called, correct?) I can successfully send a few commands, but then mplayer freezes. When I strace mplayer, this error is what it gets stuck on. ioctl(0, TIOCGWINSZ, 0x7fff2897a070) = -1 ENOTTY (Inappropriate ioctl for device) Apparently that means I'm trying to communicate with it as though it were a type writer. How fitting :) The commands are all simple strings as docs here: http://www.mplayerhq.hu/DOCS/tech/slave.txt My questions are these: is there anything I need to take care of when handling sub-processes like this, specifically while writing to stdin of the process, and with particular regard to -threaded? Does anybody spot a problem or something I'm overlooking when handling processes like this? I have been reading the API docs, but found no mention of potential caveats pertaining to -threaded. Thanks! k ✉ k(a)ioctl.it ☎ +49(0)176 / 61995110

3 4

Status of efl-haskell?
by José Romildo Malaquias 18 May '14

18 May '14

Hello. I am interested in the project efl-haskell[1] a Haskell library that provides an interface to EFL (Enlightenment Foundation Libraries) and elementary (widget toolkit)[2]. The git repository[3] has seen almost no activity. It has been created and populated on Dec 2012 and has just a workaround update on Jan 2013. Is the project still being developed? [1] https://bitbucket.org/arrowdodger/efl-haskell [2] http://enlightenment.org/ [3] https://bitbucket.org/arrowdodger/efl-haskell Romildo

2 1