- Glasgow-haskell-users

"instrumenting" functions
by Ranjit Jhala 01 Dec '16

01 Dec '16

Hi all, Given a module with top-level (functions) f1 ... fn, I would like to generate/compile an "instrumented" version where, say, each function prints the string "hello", every time it is called. Can anyone suggest some ways of doing this? One option is a core-to-core transform with an unsafePerformIO (print "hello") stuck into the appropriate places. But perhaps there are better ways? Ideally I'd like to instrument each "App" to log every function application. Are other libraries or tools that use the GHC API to do this sort of thing? Thanks in advance! Ranjit.

1 0

[ANNOUNCE] GHC 8.0.2 release candidate 1
by Ben Gamari 29 Nov '16

29 Nov '16

Hello everyone, The GHC team is happy to (finally!) announce the first candiate of the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2-rc1/ This is the first of what will hopefully be only two release candidates leading up the final 8.0.2 release. This release will fix a number bugs found in 8.0.1 including, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * Compatability with systems which use the gold linker * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. Unfortunately there is one known bug (#12757) which can result in runtime crashes which is still lurking in -rc1. This will be fixed in -rc2, which will be released in about a week. As always, let us know if you encounter trouble. Thanks to everyone who has contributed so far! Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id…

3 5

RE: Getting rid of -XImpredicativeTypes
by Simon Peyton Jones 26 Sep '16

26 Sep '16

1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) Yes, they’d disappear. 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? It’s just a swamp. I have tried multiple times to fix ImpredicativeTypes, and failed every time. Which is not to say that someone shouldn’t try again, with new thinking. Simon From: Dan Doel [mailto:dan.doel@gmail.com] Sent: 26 September 2016 00:54 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: ghc-users(a)haskell.org; ghc-devs(a)haskell.org Subject: Re: Getting rid of -XImpredicativeTypes I don't use the extension, because it's more pleasant to use newtypes with polymorphic contents. But here are some questions: 1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? Anyhow, if it can't be fixed, I think not having the extension is superior to its current state. And really, I think even if fixing it were on the roadmap, it'd be better to get rid of it until it were actually fixed. -- Dan On Sun, Sep 25, 2016 at 2:05 PM, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter… if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I’m on a plane, so I’m going to at least start with an email. Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…>

1 0

FW: Getting rid of -XImpredicativeTypes
by Simon Peyton Jones 26 Sep '16

26 Sep '16

Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter… if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I’m on a plane, so I’m going to at least start with an email. Simon

1 0

Type families in kind signatures with TypeInType
by David Menendez 23 Sep '16

23 Sep '16

Should the code below work in GHC 8.0.1? {-# LANGUAGE TypeInType, TypeFamilies #-} import Data.Kind (Type) type family K t :: Type type family T t :: K t -> Type data List type instance K List = Type type instance T List = [] Right now, I get an error like this one: min.hs:12:24: error: • Expected kind ‘K List -> Type’, but ‘[]’ has kind ‘* -> *’ • In the type ‘[]’ In the type instance declaration for ‘T’ which is puzzling, since K List -> Type and * -> * should be the same. Obviously, TypeInType is experimental and incomplete. I’m just wondering if this sort of thing is expected to work, or if I’m doing something not yet supported or never to be supported In particular, the kind signature for T is forall t -> K t -> Type, which looks like DependentHaskell. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 4

RE: File Type of source code
by Clive Lee 12 Sep '16

12 Sep '16

I am a beginner in a mess over file type I wrote a little Haskell source code 6 months ago and returning I find the source files have type Haskell Source File" When I try to store new source code it fails to load either "not found" or "does not contain module or source code" The files all have type Text Document even when I try extension ".hs" The "Save as" in Word or NotePad does not give me the option of Haskell Source File. I've even tried to start with my original files (OK load) but they save as Text Documents and then won't load I'm embarrassed I can't get over first step - I find the user guide a little complicated for a raw beginner and I must miss something in tutorials. Any help appreciated Best regards Clive

2 1

Call for Nominations: GHC Steering Committee
by Ben Gamari 05 Sep '16

05 Sep '16

Hello everyone, As you likely know, over the last few months we have been discussing options for reforming the process for proposing language and compiler changes to GHC. After much discussion, we have a process [1] which, while not perfect, is acceptable to a majority of our contributor base and will be an improvement over the status quo. While we invite suggestions for future improvements, we are at a point where we can move ahead with implementation. Consequently, we are seeking nominations for the initial GHC steering committee. This body is responsible for overseeing the progression of proposals through the process, working with authors on refining their ideas, and evaluating proposals for acceptance. The committee will consist of five to eight members of diverse backgrounds. We would like to offer the following as a criteria for membership. Note that a candidate is not expected to satisfy all or even most of these criteria, but a good candidate should satisfy at least one: * A history of contributions to the design of new language features * Experience developing Haskell libraries and applications * A demonstrated track record of contributing code to GHC * A pedagogical background, with experience in either teaching or authoring educational materials * Experience in compiler development * Knowledge of functional programming language theory I'd like to emphasize that committee membership is as much a duty as it is a privilege. Membership is not intended to be a platform to be used by members to drive their own ideas; rather it is a way of serving the Haskell community by helping other community members refine and advance their proposals. This, of course, requires an investment of time and effort, which you should be willing and able to consistently put forth. If you'd like to be considered for committee membership then please write a statement describing why you feel you are well-qualified to serve, in terms of the criteria above and any others that you would like to offer. Please send your statements to ben(a)well-typed.com by September 30th. The initial committee selection will be made by the Simons soon thereafter. Thanks to everyone for their feedback and cooperation so far! Cheers, - Ben [1] http://github.com/ghc-proposals/ghc-proposals

1 0

GHC proposal for OverloadedRecordFields (plus some amendments to OverloadedLabels)
by Adam Gundry 05 Sep '16

05 Sep '16

Hi GHC users, I've recently posted a slightly revised proposal for the next step in the epic OverloadedRecordFields saga. If you're interested, please read it and give your feedback at: https://github.com/ghc-proposals/ghc-proposals/pull/6 Many thanks, Adam P.S. Apologies for jumping the gun on the GHC proposals process being formally sanctioned. ;-) -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

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