- Haskell-Cafe - Haskell.org

Software engineer job situated in a PL research group
by Ryan Newton 01 Mar '18

01 Mar '18

Hi all, This posting is for a potentially long term position with the department. In the short term the work will be largely about sandboxing, containerization, and other low level systems stuff, but *all* the high-level software in the group is written in Haskell: https://iujobs.peopleadmin.com/postings/44056 The OOPSLA17 paper, "Monadic Composition for Deterministic, Parallel Batch Processing <https://2017.splashcon.org/event/splash-2017-oopsla-detflow-a-monad-for-det…>", should give an idea of what this initial project is about. The engineer would be co-located with a large Programming Languages group (6 faculty and a couple dozen Ph.D. students). University benefits are good and our college town combines culture and beautiful surroundings with convenience and affordability. Best regards, -Ryan

1 0

[ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 28 Feb '18

28 Feb '18

The GHC development team is pleased to announce the first (and likely final) release candidate of GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-rc1 This release will likely be the last release before the final 8.4.1 release, which, if things go well, will be released one week from today. Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release candidate is still affected by #14705, although this will certainly be resolved before the final release is made. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

3 5

Optimization demonstration
by Dušan Kolář 28 Feb '18

28 Feb '18

Dear Café, I'm trying to do very small, but impressive example about optimizations possible during Haskell compilation. So far, I can demonstrate that the following two programs (if compiled) perform computation in the same time: 1) main = putStrLn $ show $ sum $ map (*(2::Int)) [(1::Int)..(100000000::Int)] 2) main = putStrLn $! show $! sumup 1 0 sumup :: Int -> Int -> Int sumup n total = if n<=(100000000::Int) then sumup (n+1) $! total+(2*n) else total Nevertheless, I expect a question on comparison with C: 3) #include <stdio.h> int main(void) { long sum, i; sum = 0; for (i=1; i <= 100000000L; ++i) { sum += 2*i; } printf("%ld\n",sum); return 0; } Unfortunately, in this case the C is much more faster (it prints the result immediately), at least on my machine. Is it due to a fact that C compiler does a brutal optimization leading to compile-time evaluation, while ghc is not able to do that? I'm using -O2 -dynamic --make ghc compiler flags. For gcc for C compilation just -O2, running Arch Linux. Is there any option, how to force compile time evaluation? The reason, why I think it works this way is the fact, that when running out of long type values in C a code is generated that computes the values regularly (providing misleading value as a result) taking its time. Best regards, Dušan

6 8

Re: [Haskell-cafe] Optimization demonstration
by Dušan Kolář 28 Feb '18

28 Feb '18

Many thanks all for replies, yes, that's what I assumed/wrote. C compiler does compile- time evaluation, while ghc does another transformation. And, well, yes, declaring upper bound in loop in extra file breaks the optimization for C compiler and, thus, both evaluation times for C and Haskell binaries are the same thus. Thank you once, again, Dušan P.S. If anyone can point me to resource, where examples on demonstration of Haskell optimization are, I'll be very glad. D. On úterý 27. února 2018 23:06:38 CET Richard O'Keefe wrote: > In order to optimise array indexing and to automatically vectorise > your code, high performance compilers for imperative languages > like C and Fortran analyse counted loops like you wouldn't believe. > You can find out what the C compiler does with your code by using > the -S command line option. gcc 7.2 optimised the whole loop away. > > Split your C program into two files. > One contains > long bound = 100000000L, incr = 1L; > The other is a version of your existing code with > extern long bound, incr; > ... > for (i = 1L; i <= bound; i += incr) { ... } > ... > gcc 7.2 isn't quite smart enough to optimise this away. Yet. > > The polyhedral optimisations going on are described in the > open literature and are valuable for imperative array- > crunching code. You are not likely to see them in GHC any > time soon, just as you're not likely to see deforestation > in gcc any time soon. > > On 28 February 2018 at 04:06, Dušan Kolář <kolar(a)fit.vut.cz> wrote: > > Dear Café, > > > > > > > > I'm trying to do very small, but impressive example about optimizations > > possible during Haskell compilation. So far, I can demonstrate that the > > following two programs (if compiled) perform computation in the same time: > > > > > > > > 1) > > > > > > > > main = > > > > putStrLn $ show $ sum $ map (*(2::Int)) [(1::Int)..(100000000::Int)] > > > > > > > > > > > > 2) > > > > > > > > main = > > > > putStrLn $! show $! sumup 1 0 > > > > > > > > sumup :: Int -> Int -> Int > > > > sumup n total = > > > > if n<=(100000000::Int) then sumup (n+1) $! total+(2*n) > > > > else total > > > > > > > > > > > > Nevertheless, I expect a question on comparison with C: > > > > > > > > 3) > > > > > > > > #include <stdio.h> > > > > > > > > int main(void) { > > > > long sum, i; > > > > sum = 0; > > > > for (i=1; i <= 100000000L; ++i) { > > > > sum += 2*i; > > > > } > > > > printf("%ld\n",sum); > > > > return 0; > > > > } > >

1 0

Type level variants
by Brian Hurt 28 Feb '18

28 Feb '18

I'm looking for pointers on how to do something. What I'm trying to do: I want to define a newtype wrapper for database connections with a phantom type to control whether the connection is read-only or read-write. So I have: newtype Conn a = Conn { unConn :: Connection } data ReadOnly = ReadOnly data ReadWrite = ReadWrite -- Simplifying here openConn :: MonadIO m => a -> Conn a query :: (MonadIO m, ToRow r, FromRow s) => Conn a -> Query -> r -> m [s] execute :: (MonadIO m, ToRow r) => Conn a -> Query -> r -> m Int64 But I want to be able to restrict the type a to be either ReadOnly or ReadWrite. Solutions I've come up with so far are: - Don't bother. Later function calls put enough of constraint on the types that it isn't really necessary. Or rather, ReadWrite is necessary, but ReadOnly isn't. - Define some type class that ReadWrite and ReadOnly implement, but don't export the body of the typeclass from the module, preventing other people from implementing it for other types. - Some sort of trickiness with closed type families that I haven't worked out yet. Are their alternatives I haven't considered yet? Thanks. Brian

3 3

Partial instance of a class
by Jeroen Bransen 28 Feb '18

28 Feb '18

Hi Haskell cafe, Is there any standard or guideline for making a "partial" instance of a class, by which I mean implementing some methods of a class, but not all of them? In my concrete case I've got some type X which is almost an Arrow, except that I cannot lift any function a -> b to my type (of course I can for some a and b), so I cannot give a sensible implementation for arr. I can however give sensible implementations for the other methods in the Arrow class, and I'd like to use them (and possibly derived combinators) in other places. I see three possible solutions for this situation, I think I've seen at least the first two being used in well-known packages, but I couldn't find them anymore: 1. Make a class instance, and for the methods you don't implement put an 'error' call 2. Create functions with names from the class and with types specialised to your type, so that you can use it as if the instance was there. I.e. provide a function first :: X a b -> X (a, c) (b, c), which should be imported qualified to avoid name conflicts with the real Arrow class. The drawback of this is of course the conflicting names, but also the fact that derived combinators cannot be used. 3. Create functions with different names, to also avoid name clashes, i.e. firstX :: X a b -> X (a, c) (b, c). My preference would be to pick 1., but it feels quite bad in the same time. Any suggestions? Jeroen

9 20

Haskell at Work screencasts
by Oskar Wickström 27 Feb '18

27 Feb '18

Hi fellow Haskellers! I just wanted to announce a project of mine that might be of interest. Since the beginning of this year I've been producing freely available Haskell screencasts, named "Haskell at Work". They focus on practical industry use of Haskell, and are primarily geared towards rookie and intermediate Haskellers. You'll find the videos, including show notes, here: https://haskell-at-work.com/ If you like my videos and think more people should see them, please help me spread the word! There's also a Patreon page where you or others can help out by donating: https://www.patreon.com/haskellatwork So far I've had a great time making screencasts, even if it's a lot of work. The warm feedback and many viewers is highly motivating! Best, Oskar

1 0

Re: [Haskell-cafe] runGet exits prematurely
by Quentin Liu 26 Feb '18

26 Feb '18

Thank you for the suggestion! I am still not sure about the correct way to communicate on mailing-list. But I have figured out the problem which is caused by arithmetic overflow. I was using Word8 to parse the packet length and presumed the packet length would be larger than 46. The subtraction of 47 from the Word8 packet length gave the largest number Word8 could represent, which definitely exceeds the length of the whole file. Regards, Qingbo Liu On Feb 26, 2018, 02:41 -0500, Robin Palotai <palotai.robin(a)gmail.com>, wrote: > [-list] > > FYI Given the lack of responses, I think more context would help. For example github / gist link to code, minimal case to reproduce. > > > 2018-02-23 16:59 GMT+01:00 Quentin Liu <quentin.liu.0415(a)gmail.com>: > > > Hi, > > > > > > I am using Data.Binary to decode binary files and found that the `runGet` function would throw an exception “not enough bytes” even though it has not consumed all the input. > > > > > > Specifically, in the loop I am repeatedly trying to parse the binary file until it has consumed all the input > > > > > > parsePPackets xs = do > > > empty <- isEmpty > > > if empty > > > then return xs > > > else do p <- parseB6034 > > > parsePPackets (p:xs) > > > > > > When I try to run this function with `runGet`, the exception “Data.Binary.Get.runGet at position 3293603: not enough bytes” would be thrown, while the total length of input is 5864230, a number significantly larger. The function `parseB6034` consumes no more than 250 bytes in each round. In addition, the `parsePPackets` works well when fed with a small amount of data. > > > > > > Is it the problem of my code or an error with the package binary? The ByteString fed into `runGet` is lazy ByteString, as required by `runGet` function. > > > > > > Best Regards, > > > Qingbo Liu > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > To (un)subscribe, modify options or view archives go to: > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > Only members subscribed via the mailman list are allowed to post. >

1 0

[ANN] show-combinators: a minimal pretty-printing library for Show instances
by Li-yao Xia 26 Feb '18

26 Feb '18

Hello, Sometimes it is necessary to handwrite instances for Show, Show1, Show2, or some other simple pretty-printer for ADT-like structures (because they might not be easily derived via existing means). base has a few combinators in Prelude, Text.Show, and Data.Functor.Classes. But they require explicit handling of spacing and precedence levels, which is generally error-prone and repetitive, since ADTs all look the same. This new library, show-combinators, contains just a dozen of functions to encapsulate all of those details, so the code left to write can more closely match the structure of the type to show. http://hackage.haskell.org/package/show-combinators I hope you will also find it useful. Cheers, Li-yao

1 0

Re: [Haskell-cafe] Proposal: Add Eq1 and Ord1 instances in GHC.Generics, and synchronize with Data.Functor.* types
by Zemyla 26 Feb '18

26 Feb '18

I definitely agree with adding Eq1 and Ord1 instances. We probably should have Show1 and Read1 as well, since we have normal Show and Read instances, but it should say they can't be used for deriving like Eq1 and Ord1 can. On Sun, Feb 25, 2018 at 9:10 AM, Li-yao Xia <lysxia(a)gmail.com> wrote: > Eq1 and Ord1 are two more useful classes to implement in GHC.Generics, and > would be useful to derive Eq1 and Ord1 generically. Note that we can > currently use transformers-compat to derive these. > > Moreover, most of the GHC.Generics types are equivalent to types in the > Data.Functor.* modules. Would it be a good idea for them to have the same > instances? Concretely, the current differences are: > > - GHC.Generics is missing Eq1, Ord1, Show1, Read1 instances > - Data.Functor.* is missing Semigroup and Monoid instances (that my previous > proposal would add to GHC.Generics) > > Li-yao > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0