August 2016 - Glasgow-haskell-users

Allow extra commas in module declarations or lists?
by Michael Burge 17 Dec '16

17 Dec '16

Some languages like Perl allow you to include additional commas in your lists, so that you can freely reorder them without worrying about adding or removing commas from the last or first item: my @array = ( 1, 2, 3, ); Perl even allows multiple redundant commas everywhere after the first element, which is less useful but has come up on occasion: my @array = (1,,,2,,,,,,,,,3,,,,,); I propose allowing an optional single extra comma at the end in module declarations, record declarations, record constructors, and list constructors: module Example ( module Example, SomeConstructor(..), ) where data SomeConstructor = SomeConstructor { foo :: Int, bar :: Int, } baz :: SomeConstructor -> SomeConstructor baz x = x { foo = 5, bar = 10, } qux :: [ Int ] qux = [ 1, 2, 3, ] What do you think?

4 3

Exposing target language in Haskell with GHC API
by Matthew Farkas-Dyck 02 Sep '16

02 Sep '16

A colleague and i are writing, as an unofficial side project, a Haskell→Bluespec compiler, using GHC as our Haskell front-end. The source language of the part we are writing is GHC Core. We need to somehow expose some Bluespec terms and types to the Haskell source program. We had a few ideas: 1. Some "NO_MANGLE" pragma which would tell GHC to not mangle the emitted name, e.g. `x = {-# NO_MANGLE #-} x` to expose `x` 2. `foreign import prim`, not quite sure how yet 3. "CORE" pragmas, e.g. `x = {-# CORE "foo" #-} x` to expose `x` 4. "ANN" pragmas, e.g. `{-# ANN x "no_mangle" #-} x = x` to expose `x` 1 and 2 would mean modifying GHC which we'd rather not do. For 3, we're not sure how to find the "CORE"-pragmatic annotations in a `Core` AST. 4 seems it would work but be a little cumbersome, as the annotation is not on the `Core` AST. Anyone know a good way to do this?

2 2

GHC Performance / Replacement for R?
by Dominic Steinitz 31 Aug '16

31 Aug '16

I am trying to use Haskell as a replacement for R but running into two problems which I describe below. Are there any plans to address the performance issues I have encountered? 1. I seem to have to jump through a lot of hoops just to be able to select the data I am interested in. {-# LANGUAGE ScopedTypeVariables #-} {-# OPTIONS_GHC -Wall #-} import Data.Csv hiding ( decodeByName ) import qualified Data.Vector as V import Data.ByteString ( ByteString ) import qualified Data.ByteString.Char8 as B import qualified Pipes.Prelude as P import qualified Pipes.ByteString as Bytes import Pipes import qualified Pipes.Csv as Csv import System.IO import qualified Control.Foldl as L main :: IO () main = withFile "examples/787338586_T_ONTIME.csv" ReadMode $ \h -> do let csvs :: Producer (V.Vector ByteString) IO () csvs = Csv.decode HasHeader (Bytes.fromHandle h) >-> P.concat uvectors :: Producer (V.Vector ByteString) IO () uvectors = csvs >-> P.map (V.foldr V.cons V.empty) vec_vec <- L.impurely P.foldM L.vector uvectors print $ (vec_vec :: V.Vector (V.Vector ByteString)) V.! 17 print $ V.length vec_vec let rockspring = V.filter (\x -> x V.! 8 == B.pack "RKS") vec_vec print $ V.length rockspring Here's the equivalent R: df <- read.csv("787338586_T_ONTIME.csv") rockspring <- df[df$ORIGIN == "RKS",] 2. Now I think I could improve the above to make an environment that is more similar to the one my colleagues are used to in R but more problematical is the memory usage. * 112.5M file * Just loading the source into ghci takes 142.7M * > foo <- readFile "examples/787338586_T_ONTIME.csv" > length foo takes me up to 4.75G. But we probably don't want to do this! * Let's try again. * > :set -XScopedTypeVariables * > h <- openFile "examples/787338586_T_ONTIME.csv" ReadMode * > let csvs :: Producer (V.Vector ByteString) IO () = Csv.decode HasHeader (Bytes.fromHandle h) >-> P.concat * > let uvectors :: Producer (V.Vector ByteString) IO () = csvs >-> P.map (V.map id) >-> P.map (V.foldr V.cons V.empty) * > vec_vec :: V.Vector (V.Vector ByteString) <- L.impurely P.foldM L.vector uvectors * Now I am up at 3.17G. In R I am under 221.3M. * > V.length rockspring takes a long time to return 155 and now I am at 3.5G!!! In R > rockspring <- df[df$ORIGIN == "RKS",] seems instantaneous and now uses only 379.5M. * > length(rockspring) 37 > length(df$ORIGIN) 471949 i.e. there are 37 columns and 471,949 rows. Running this as an executable gives ~/Dropbox/Private/labels $ ./examples/BugReport +RTS -s ["2014-01-01","EV","20366","N904EV","2512","10747","1074702","30747", "BRO","Brownsville, TX","Texas","11298","1129803","30194", "DFW","Dallas/Fort Worth, TX","Texas","0720","0718", "-2.00","8.00","0726","0837","7.00","0855","0844","-11.00","0.00", "","0.00","482.00","","","","","",""] 471949 155 14,179,764,240 bytes allocated in the heap 3,378,342,072 bytes copied during GC 786,333,512 bytes maximum residency (13 sample(s)) 36,933,976 bytes maximum slop 1434 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 26989 colls, 0 par 1.423s 1.483s 0.0001s 0.0039s Gen 1 13 colls, 0 par 1.005s 1.499s 0.1153s 0.6730s INIT time 0.000s ( 0.003s elapsed) MUT time 3.195s ( 3.193s elapsed) GC time 2.428s ( 2.982s elapsed) EXIT time 0.016s ( 0.138s elapsed) Total time 5.642s ( 6.315s elapsed) %GC time 43.0% (47.2% elapsed) Alloc rate 4,437,740,019 bytes per MUT second Productivity 57.0% of total user, 50.9% of total elapsed

3 3

Using stringize and string concatenation in ghc preprocessing
by Harendra Kumar 22 Aug '16

22 Aug '16

Hi, To reduce boilerplate code in an FFI implementation file I am trying to use the stringizing and string concatenation features of the C preprocessor. Since ghc passes '-traditional' to the preprocessor which disables these features I thought I can pass my own flags to the preprocessor like this: {-# OPTIONS_GHC -optP -E -optP -undef #-} But "-optP" seems to only append to the flags that GHC already passes and gcc has no "-no-traditional" option to undo the effect of the "-traditional" that GHC has already passed. I think "-optP" should override the flags passed by ghc rather than appending to them. Is there a reason not to do that? Is there any other better way to achieve this? What is the standard way of doing this if any? -harendra

3 4

Behavior of GHC_PACKAGE_PATH
by Harendra Kumar 20 Aug '16

20 Aug '16

Hi, As per the GHC manual (https://downloads.haskell. org/~ghc/master/users-guide/packages.html#the-ghc-package- path-environment-variable), packages which come earlier in the GHC_PACKAGE_PATH supersede the ones which come later. But that does not seem to be the case always. I am dealing with a case where I have multiple versions of a package in different databases. I am passing the list of package dbs via GHC_PACKAGE_PATH and ghc is picking the one which comes later. I expect it to pick the one which comes earlier in the path. In one case the package being picked from a package db which comes later is a newer version which makes me wonder if GHC always prefers a newer version. In another case both the versions are same but still GHC is using the one which come later in the package path. Are there any undocumented factors into play here? None of the packages is broken (as reported by ghc-pkg check). See https://github.com/commercialhaskell/stack/issues/1957#issuecomment- 239655912 for more details on where it is coming from. Thanks, Harendra

2 2

ghci on pi zero
by Alex McLean 15 Aug '16

15 Aug '16

Hi all, I'm trying to get a working ghc on the pi zero, with its armv6l processor. I'm in need of ghci and/or the hint package, and raspbian only comes with a ghc without ghci and that is unable to compile hint. What's the current status of ghc (and in particular ghci) on the original pi and pi zero? Any tips on getting it running? Best wishes, alex

2 2

FINAL CALL FOR TALKS (Aug 8 deadline): Haskell Implementors Workshop 2016, Sep 24, Nara
by Edward Z. Yang 01 Aug '16

01 Aug '16

Deadline is in a week! Submit your talks! Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers --- End forwarded message ---

1 0