- Haskell-Cafe - Haskell.org

PhD studentship in Nottingham
by Graham Hutton 09 Jan '12

09 Jan '12

Dear all, I am currently advertising a PhD Studentship in Functional Programming at the University of Nottingham in the UK: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1088 If you are interested in applying yourself, please drop me a note by email. If you know of any good candidates who may be interested in applying, or there is a local mailing list for advertising such things, I'd be much obliged if you could pass on the above link. Many thanks, Graham Hutton -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: [Haskell-cafe] Experiments in Haskell Packaging
by Chris Dornan 09 Jan '12

09 Jan '12

> > I don’t have any problem with installing the tools into user-land – > > this will be true of all of the components in the justhub distro – > > provided you start with the source code. > > Long ago the Fedora Haskell project's rpm packages were relocatable for this reason. So it may still be possible and not that hard to do. I have looked into it -- unless we can unpack a bindist as part of the post-install step, it doesn't look practical. I have yet to be convinced that the RPM route make sense for the restrictive situation that Sanket outlines and I am trying to keep an open mind. I don't want to distribute sources either -- I think the solution will involve bindists. What a piece of work is a GHC bindist! Chris -----Original Message----- From: juhpetersen(a)gmail.com [mailto:juhpetersen@gmail.com] On Behalf Of Jens Petersen Sent: 08 January 2012 08:03 To: Chris Dornan Subject: Re: [Haskell-cafe] Experiments in Haskell Packaging > I don’t have any problem with installing the tools into user-land – > this will be true of all of the components in the justhub distro – > provided you start with the source code. Long ago the Fedora Haskell project's rpm packages were relocatable for this reason. So it may still be possible and not that hard to do. Jens

1 0

PhD studentship in Nottingham
by Graham Hutton 09 Jan '12

09 Jan '12

Dear all, I am currently advertising a PhD Studentship in Functional Programming at the University of Nottingham in the UK: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1088 If you are interested in applying yourself, please drop me a note by email. If you know of any good candidates who may be interested in applying, or there is a local mailing list for advertising such things, I'd be much obliged if you could pass on the above link. Many thanks, Graham Hutton -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Are all monads functions?
by Yves Parès 09 Jan '12

09 Jan '12

Hello Café, One thought occur to me recently when explaining the concept of Monad to non-haskellers: internally, all standard Monads are newtypes wrapping functions: StateT is, WriterT is, ContT is. Even IO and ST are, both conceptually and in their implementation by GHC. ParsecT (not part of mtl, but still) is. And so on... So I'm saying that most of the time, we define a new monad: - either by building a monad stack of existing transformers (thus "melting" their internal functions), - or by creating a newtype containing a custom function. Thinking thusly, >>= would then just be a special function composition operator: in the spirit of '.' but for a specific type of functions. So my questions are: - Is it reasonable to think like that, or are there too many monads that cannot be defined like that, and then contradict me? - Is it reasonable to present monads to newcomers by saying : monads are basically always functions. 'return x' will then be a function that always return 'x' regardless of its input and >>= is a special composition for this occasion. -- The ⊥ is a lie.

10 10

On stream processing, and a new release of timeplot coming
by Eugene Kirpichov 09 Jan '12

09 Jan '12

Hi Cafe, In the last couple of days I completed my quest of making my graphing utility timeplot ( http://jkff.info/software/timeplotters ) not load the whole input dataset into memory and consequently be able to deal with datasets of any size, provided however that the amount of data to *draw* is not so large. On the go it also got a huge speedup - previously visualizing a cluster activity dataset with a million events took around 15 minutes and a gig of memory, now it takes 20 seconds and 6 Mb max residence. (I haven't yet uploaded to hackage as I have to give it a bit more testing) The refactoring involved a number of interesting programming patterns that I'd like to share with you and ask for feedback - perhaps something can be simplified. The source is at http://github.com/jkff/timeplot The datatype of incremental computations is at https://github.com/jkff/timeplot/blob/master/Tools/TimePlot/Incremental.hs . Strictness is extremely important here - the last memory leak I eliminated was lack of bang patterns in teeSummary. There's an interesting function statefulSummary that shows how closures allow you to achieve encapsulation over an unknown piece of state - curiously enough, you can't define StreamSummary a r as StreamSummary { init :: s, insert :: a->s->s, finalize :: s->r } (existentially qualified over s), as then you can't define summaryByKey - you don't know what type to store in the states map. It is used to incrementally build all plots simultaneously, shown by the main loop in makeChart at https://github.com/jkff/timeplot/blob/master/Tools/TimePlot.hs Incremental building of plots of different types is at https://github.com/jkff/timeplot/blob/master/Tools/TimePlot/Plots.hs There are also a few interesting functions in that file - e.g. edges2eventsSummary, which applies a summary over a stream of "long" events to a stream of rise/fall edges. This means that you can define a "stream transformer" (Stream a -> Stream b) as a function (StreamSummary b -> StreamSummary a), which can be much easier. I have to think more about this idea. -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/

6 13

"too many open files" using snap
by Eric Wong 09 Jan '12

09 Jan '12

Hi haskellers, I wrote a web server using snap framework. Basically, it's an API server using hdbc-mysql to connect to a mysql server. But it also serves some static web pages and images, using the serveDirectory function in snap-core. The program eats more and more memory slowly, but I couldn't spot the leak. It uses less than 10MB memory when starting. Sometimes, it can grow to 60-70MB and stop working correctly. Then I find that the log file is full of "too many open files" error. As I don't have any code open any files, I suspect it's the serveDirectory leaking. But I don't have any expertise on the core of snap, so, could some one give me some advice on this problem? Thanks. Eric

6 11

How to use IndentParser. Any example/tutorial?
by Sukit Tretriluxana 09 Jan '12

09 Jan '12

Hi, I need to construct a parser that parse a language that use indentation to define blocks as Python does. I ran into Text.ParserCombinators.Parsec.IndentParser module but have no idea how to use it. Can anyone point me out to how to use this module? Any short example, tutorial, or whatever would be highly appreciated. Thanks, Ed

1 0

numeric coercion in ghci vs hugs
by Doug McIlroy 09 Jan '12

09 Jan '12

After loading the one-line file default (Integer,Rational,Double) the input 1::Fractional t => t in ghci yields the output 1.0 and in hugs 1%1 The ghci answer appears not to respect the default declaration. What's going on? Doug McIlroy

1 0

ANN: wxHaskell 0.13.2
by Jeremy O'Donoghue 09 Jan '12

09 Jan '12

Hi Lists, I am please to announce that wxHaskell 0.13.2 has just been uploaded to Hackage. This is mainly a bugfix release, although it brings a few useful changes: - Changes to support build under Haskell Platform 2011.4.0.0 - OpenGL support if your wxWidgets build is configured with it (reinstated functionality) - StyledTextControl support if your wxWidgets build is configured with it (reinstated functionality) This is intended to be the final wxHaskell release supporting wxWidgets 2.8.x. Provided that you have a suitable Unicode wxWidgets 2.8 install configured on your machine, you should be able to install with. cabal install wx In the near future, we will be committing an updated wxHaskell release supporting wxWidgets 2.9, but this implies a number of breaking API changes, and the size of team supporting wxHaskell is not large enough to cover both. As such, this release is recommended to those who will not be able to move to wxWidgets 2.9 and later. The next release has more significant improvements planned, including wrapping several additional wxWIdgets libraries and restoring correct operation in GHCi. We do not have a formal timeline as yet, but the code is working in test repositories, and mainly needs work to make it cross-platform clean. This release has been tested on the following platforms: - Windows 7 / Haskell Platform 2011.4.0.0 / wxPack 2.8.12 (Unicode, Release) - OpenGL is not enabled on the test platform, so OpenGL samples do not work. - StyledTextControl is not enabled on the test platform, so STC samples do not work. - All other sample code compiles, links and runs, but has only been tested for Unicode wxWidgets builds. - Ubuntu 10.0.4 LTS (32 bit) / GHC 6.12 / wxWidgets 2.8.10 - Repo packages: wx2.8-headers, libwxgtk2.8-0, libwxgtk2.8-dev, libglitz1, libglitz-gl1, libgl1-mesa-dri, libglu1-mesa, libglu1-mesa-dev, mesa-common-dev, libgl1-mesa-dev, libgl1-mesa-glx, ghc6 - Cabal packages: strict, stm, OpenGL, cabal-install - OpenGL is enabled on the test platform, and the samples compile and run. - StyledTextControl is not enabled on the test platform, so STC samples do not work. - All other sample code compiles, links and runs, but has only been tested for Unicode wxWidgets. I do not have access to an OS X platform for test, so would appreciate feedback on any issues found by OS X users. There are known to be issues on 64 bit OS X builds, which will be addressed in the next release. The source repository at code.haskell.org has not yet been updated with the patches. This will happen in the next day or so. Best regards Jeremy

2 2

cabal and conditional build-depends
by Tristan Ravitch 08 Jan '12

08 Jan '12

Hi Cafe, I have a package that depends on several other Haskell libraries. One of these libraries depends on some native libraries (and associated headers) to build. I would like to make this dependency optional in my package if the libraries don't exist. To do this, I tried to switch my build-type from Simple to Configure in my .cabal file. Then I made a configure script that generates a <pkg>.buildinfo file as suggested in the cabal guide. The buildinfo file is generated and looks as I would expect. If the library is found on the system, it has a "build-info: ..." line. Unfortunately, when Cabal processes it, it says: Warning: archive-inspection.buildinfo: Unknown fields: build-depends (line 2) Fields allowed in this section: buildable, build-tools, cpp-options, cc-options, ld-options, pkgconfig-depends, frameworks, c-sources, default-language, other-languages, default-extensions, other-extensions, extensions, extra-libraries, extra-lib-dirs, includes, install-includes, include-dirs, hs-source-dirs, other-modules, ghc-prof-options, ghc-shared-options, ghc-options, hugs-options, nhc98-options, jhc-options It really doesn't seem to like conditional build-depends entries. Is this expected behavior? And is there a better way to go about having conditional build-time dependencies on Haskell libraries using Cabal? I guess I could start playing with a custom Setup.hs, but I always hate doing that unless absolutely necessary. Thanks

1 0

Questions on the Haskell 2010 report
by Silvio Frischknecht 08 Jan '12

08 Jan '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to write a haskell compiler and i have stumbled upon 2 issues that i don't understand in the Haskell report 2010. Btw. these issues are also present in the 98 report. 1) first is this in section 5.1 Module Structure [1]. A module is defined like this. module → module modid [exports] where body | body body → { impdecls ; topdecls } | { impdecls } | { topdecls } You can't see it in this mail because there is no font but the curly braces { } are meant to match the tokens { } and are not meant as repetition. However, as I understand it, the layout parser would modify this code: module Foo where import Bar baz=baz to this code (which doesn't match): module Foo where { import Bar ; baz=baz } and not to this code (which would be required to match): module Foo where { { import Bar } ; { baz=baz } } So as i see the definition should state this instead: module → module modid [exports] where body | body body → { impdecls ; topdecls } | impdecls | topdecls 2) In the same section what is it supposed to mean if "module" consists of only a "body" and not "module modid [exports] where body". 3) In section 10.3 Layout [2] it is written. If a let, where, do, or of keyword is not followed by the lexeme {, the token {n} is inserted after the keyword, where n is the indentation of the next lexeme if there is one, or 0 if the end of file has been reached. Together with this rule L [] (m : ms) = } : L [] ms if m≠0 (Note 6) This results in an error if the program ends in a "where", ... Wouldn't it make more sense to put a {1} in case of EOF or just insert the tokens '{' and '}'. On the other hand if you really won't accept that why not simply say that it is an error. btw. GHC doesn't give an error. [1] http://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-990005.1 [2] http://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-178000… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPCdgeAAoJEDLsP+zrbatWIjgP/RLISOIz6xZRDso/mVn+xbwh eMPdeqmzJJYpVm+sDdjmoEIAsrwXtYKc9r8LrlUOugbtXFhYYPcSox7Te4DO+Cm+ X+b8b80UQu1nKNoUofDqAXSQb/n7f5zgmaIoF2uvFieuJTE709oZCmBdTgupVdyJ D16VqmKmqpskNepnQuh9rV7vwSPs4PjnsUQDpxjXDvh0tSdp9byBZPcMwEgQb172 FJAAryCuKFBE8FRG+ANlSw2h8fH7rkMLmkjabje5NKtLa2UMKvBlXYa2p0EZwcd2 /bj/2GTksWdsDmqFp3lQJgPk2uxp5reosTiTk5JQz56GcPOTK3wmL62qDeH3+tdS pX5ZD8HeX8RdkLjuFi0fjiJq3L4HEy+OqHbLWoStPPqfY9clueSUJ0g0Dfc4OukU 0naJlASxKr4ovHBiTinrLI6bTTeeMj9QCDGh5hU0x1hJ5f80iQQaKYpI8cq1DxQv CICBFibFnbJ0Zfzfuk0ZJZ8Db1dJUdEGSYZo/QCtpxXwTyKr4zEU6FYHprScRRX8 H6ZDnVE6ZbzDbaUqeQVBXvUGHF+2vTmDo1EZ80BFhDVHjifvV9eHslbF0XD+NjYY iRPsgDzACYsMxvYaBsRlXWwmwWD+EfNerdHZL6h9dBZICwSr0pu4SCp616BR2BpK IuO4MG/B5vAoCs9cb0lG =O6Wd -----END PGP SIGNATURE-----

2 2

Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
by Aristid Breitkreuz 08 Jan '12

08 Jan '12

Yeah and that's annoying IMHO. :) It's not really important though. Aristid Am 07.01.2012 15:39 schrieb "Felipe Almeida Lessa" <felipe.lessa(a)gmail.com>:

4 9

RoseTree + Data.Typeable.Zipper
by Sergey Mironov 08 Jan '12

08 Jan '12

Hi list! Could you please give me a quick example of navigating throw Data.Typeable.Zipper built on top of a Rose Tree? eg. (See ??? in the last line - is my question) {-#LANGUAGE TemplateHaskell, DeriveDataTypeable, TypeOperators #-} import Data.Typeable.Zipper data Tree k a = Tree { _rules :: [(k,Tree k a)] } deriving(Show, Typeable) $(mkLabelsNoTypes [''Tree]) atree = Tree [(1, Tree []), (2, Tree []), (3, Tree [(11, Tree [])])] moveToLeftmostChild :: (Typeable k, Typeable a) => Zipper1 (Tree k a) -> Zipper1 (Tree k a) moveToLeftmostChild z = moveTo ??? z Thanks, Sergey

1 1

All the random packages
by Eugene Kirpichov 08 Jan '12

08 Jan '12

Hi, I came across the beautiful algorithm for O(1) generation of rational discrete distributions http://www.keithschwarz.com/darts-dice-coins/ and though it'd be fun to implement it in Haskell and put on Hackage, but then it turned out that there's about a dozen random number packages, so I'm not sure to which one to contribute, or better to roll out my own package and encourage authors of the other packages to reference it and fit under their interface. What do you think? Which random number packages are considered to be most mature or perhaps promising - i.e., contributing to which ones will bring the community the most benefit? Is there any effort on unifying them going on? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/

2 1

OpenAL bindings?
by Jason Dagit 08 Jan '12

08 Jan '12

Hello, Looks like the repo [1] for the OpenAL bindings that Sven Panne created [2] is no longer available. I assume this is a result of The Great Server Outage of 2011 [3]. Do other bindings exist (I didn't see any on hackage, google, or the wiki [4])? I can import the source that is available on hackage into a github repo and hack from there, but I wanted to ask first: Is the source of this repo gone for good? As a side note, I have plenty of other repos and things on my plate so I'm not really interested in becoming the maintainer of this binding. Any OpenAL experts interested in taking it over? I know from experience that Sven appears to be MIA in the Haskell community these days. Thanks, Jason -- [1] http://darcs.haskell.org/packages/OpenAL/ [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenAL [3] http://www.haskell.org/pipermail/haskell-cafe/2011-February/088829.html [4] http://www.haskell.org/haskellwiki/OpenAL

3 3

ANN: leapseconds-announced-2012
by Bjorn Buckwalter 08 Jan '12

08 Jan '12

Dear all, The International Earth Rotation and Reference Systems Service (IERS) recently announced[1] that a positive leap second will be introduced at the end of June 2012. Consequently I have updated the leapseconds-announced library[2]. The original announcement of leapseconds-announced can be found below. Best regards, Bjorn Buckwalter [1] http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat [2] http://hackage.haskell.org/package/leapseconds-announced ---------- Forwarded message ---------- From: Bjorn Buckwalter <bjorn.buckwalter(a)gmail.com> Date: Sat, Jan 17, 2009 at 13:23 Subject: ANN: leapseconds-announced-2009 To: Haskell(a)haskell.org, haskell-cafe(a)haskell.org Dear all, I'm pleased to announce the upload of the leapseconds-announced package[1] to Hackage. leapseconds-announced contains a single module and a single function implementing the Data.Time.Clock.TAI.LeapSecondTable interface (type). The documentation[2] for Data.Time.Clock.TAI.LeapSecondTable says "No table is provided, as any program compiled with it would become out of date in six months" and with that I have no objections. However, I frequently find myself needing a LeapSecondTable for a quick-and-dirty one-off analysis or simulation of the present or past. In these cases I've lazily used "(const 33)" (or more recently: "(const 34)") as my LeapSecondTable. leapseconds-announced is a pragmatic, if imperfect, improvement over my past practices. It provides a LeapSecondTable with all leap seconds announced to date (hence the name). Once the IERS announces[3] another leap second the package will need an update and all code using it a recompile. While this precludes its use in long-running production applications it is eminently adequate for my one-off uses or for applications that can afford to recompile infrequently. While, in the words of the Data.Time.Clock.TAI documentation, "most people won't need this module" I hope it can be of utility to someone. Thanks, Bjorn Buckwalter [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/leapseconds-anno… [2] http://www.haskell.org/ghc/docs/latest/html/libraries/time/Data-Time-Clock-… [3] http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat

1 0

Re: [Haskell-cafe] Problems with libgmp on Amazon Linux
by Nicu Ionita 07 Jan '12

07 Jan '12

Am 07.01.2012 20:01, schrieb Nabil Alsharif: > Ahh your main issue is that --prefix should be /usr not /usr/lib.... > It would be best to reinstall libgmp with the correct prefix. Oh, thanks, I will try this.

1 0

[ANNOUNCE] First release of crypto-conduit
by Felipe Almeida Lessa 07 Jan '12

07 Jan '12

Hello! I'm pleased to announce the first release of crypto-conduit [1]! The crypto-api [2] package provides APIs for many cryptographic operations, such as cryptographic hashes and block ciphers. This new crypto-conduit package allows you to use many of these operations with conduits [3], giving you safe I/O using constant memory and no leaks. As an example, here's how you could get the SHA1 hash a file: import Crypto.Conduit -- from crypto-conduit import Crypto.Hash.SHA1 (SHA1) -- from cryptohash import Data.Conduit -- from conduit import Data.Conduit.Binary (sourceFile) -- from conduit main = do hash <- runResourceT $ sourceFile "my-file" $$ sinkHash print (hash :: SHA1) The code snippet above, despite having only "sourceFile ... $$ sinkHash" on its core, guarantees that the file handle is not kept open and uses a constant amount of memory. Sweet! Please break this package! Although it comes with a test suite, it has just seen the light of the day. Cheers, =) [1] http://hackage.haskell.org/package/crypto-conduit [2] http://hackage.haskell.org/package/crypto-api [3] http://hackage.haskell.org/package/conduit -- Felipe.

3 6

ANNOUNCE: DHD >>= UHac, April 20 - 22, Utrecht
by Sean Leather 07 Jan '12

07 Jan '12

Calling all Haskellers! To open 2012 and in celebration of the group's 3rd year of existence, the Dutch Haskell Users Group is happy to announce a new event that combines an informal conference and a hackathon. >>= >> >> >> >> >> >> >>= >>= >>= >>= *DHD >>= UHac* >>= >>= >>= >>= *April 20 - 22* >>= >>= >>= >>= *Utrecht* >>= >>= >>= >>= >> >> >> >> >> >> >>= >>= DHD >>= The Dutch HUG Day, or DHD, will be a half day of talks on anything Haskell-y or FP-ish. It will be held on Friday, April 20. >>= UHac >>= The Utrecht Hackathon, or UHac, will be a gathering of the community of enthusiastic Haskell hackers from around the world. It will start immediately following the DHD and continue to Sunday, April 22. >>= Call for Speakers >>= We are looking for speakers for the Dutch HUG Day. If you have something interesting to share, please email Sean Leather (leather(a)cs.uu.nl) See the website for more. >>= Website >>= For more information that will be continuously updated, see the event wiki page: *http://www.haskell.org/haskellwiki/DHD_UHac* Join us for a Haskell-y time in the Netherlands. We look forward to seeing you there! Sean Leather and Jurriën Stutterheim Organizers

1 0

Motivation for having indexed access in Data.Map?
by Christoph Breitkopf 07 Jan '12

07 Jan '12

Hello, I wonder why Data.Map provides the indexed access functions: http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data… These functions seem rather out-of-place to me in the map api. The only use case I could think of so far would be to find the median, or in general n-th smallest key, but that does not seem sufficient reason (also, I think there are faster methods for that). Anything else? Regards, Chris

2 1

Problems with libgmp on Amazon Linux
by Nicu Ionita 07 Jan '12

07 Jan '12

Hello, I saw [1] there is a lot of activity in the Haskell community regarding Amazon Web Services (AWS). As they allow an easy start [2], I decided to giv it a try and followed the procedure published by JP Moresmau [3] to install the Haskell Plattform on Amazon Linux (a minimal linux distribution maintained by Amazon), but with the new Haskell Platform, 2011.4.0.0 (and ghc 7.0.4). It seemed to work pretty well, with some problems when configuring HP, because although libgmp was already installed, it was not recognized. I installed the newer version 5.0.2 (from sources) [4], did some tricks (cp /usr/lib/lib/libgmp* /usr/lib), then configure worked and HP was built and installed. But then later I wanted to install the aws package (cabal install aws) and then the vector package could not be installed - again because of libgmp! Here are the last messages, followed by a ls of /usr/lib, where it's clear that the libraries are there: [ 4 of 30] Compiling Data.Vector.Internal.Check ( Data/Vector/Internal/Check.hs, dist/build/Data/Vector/Internal/Check.o ) [ 5 of 30] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... <command line>: can't load .so/.DLL for: gmp (libgmp.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: vector-0.9.1 failed during the building phase. The exception was: ExitFailure 1 [ec2-user@ip-10-234-49-92 ~]$ ls -l /usr/lib/libgmp* -rw-r--r-- 1 root root 1175336 Jan 4 22:21 /usr/lib/libgmp.a -rwxr-xr-x 1 root root 915 Jan 4 22:21 /usr/lib/libgmp.la -rwxr-xr-x 1 root root 484673 Jan 4 22:21 /usr/lib/libgmp.so -rwxr-xr-x 1 root root 484673 Jan 4 22:21 /usr/lib/libgmp.so.10 -rwxr-xr-x 1 root root 484673 Jan 4 22:21 /usr/lib/libgmp.so.10.0.2 [ec2-user@ip-10-234-49-92 ~]$ I'm just asking here hoping that someone had already solved this problem. Or perhaps someone can explain how cabal ensures that a library is there. The error message - as it is - is meaningless, as the file exists and has read permissions for everybody. Thank you, Nicu [1] http://www.reddit.com/r/haskell/comments/o1u2g/deploying_a_haskell_app_to_a… [2] https://aws.amazon.com/free/ [3] http://jpmoresmau.blogspot.com/2011/04/install-ghc7-and-yesod-on-amazon-lin… [4] ftp://ftp.gnu.org/gnu/gmp/

2 3

Package for QuickCheck instances
by Antoine Latter 06 Jan '12

06 Jan '12

Hi Haskell, I was writing some tests that involved a large number of quickcheck properties which don't ship with the library itself, so I thought I would package them all together and put the orphan instances on Hackage. Here's what I have so far: https://github.com/aslatter/qc-instances/tree/93a87fa06b5575ddcc12c2f9eb0f4… The policy would be to allow anything into to package which is a part of the Haskell Platform or is a GHC build library. Has anyone already done this? I didn't find anything from grepping the Hackage package list. Has anyone already talked about doing this sort of thing? Are their any non-obvious pitfalls (aside from the package eventually becoming a cesspool of CPP conditions)? Thanks, Antoine

2 1

Re: [Haskell-cafe] Experiments in Haskell Packaging
by Chris Dornan 06 Jan '12

06 Jan '12

'Antoine Latter' <aslatter(a)gmail.com>: > All of this is in my head, but assuming I already had some sort of > Linux build-server set up, it would be nice to combine it with your > work to make it easier to have the build-server run tests against > multiple versions of GHC/HP. That's all I was getting at. Working within the Hub framework this is straightforward. If you are using public releases rather than special builds of the tools then it should be quite easy. Supposing you needed to test with Haskell Platform 2011.2.0.1 and hexpat-0.19.7: # install the platform (probably done already) sudo yum install haskell-platform-2011.2.0.1-hub # create new hub 'test-2011.2.0.1' based this HP hub init 2011.2.0.1 test-2011.2.0.1 # install hexpat-0.19.7 into it hub install-into test-2011.2.0.1 hexpat-2011.2.0.1 Repeat as necessary to create your array of test environments. Now you just have to arrange select the appropriate hub for each test. Suppose the environment variable $testhubs contains all of your test hubs ('test-2011.2.0.1', etc.), then the following shell command would prime the tools to successively use each of the test environments on each invocation of make. for h in $testhubs; do HUB=$h make; done Note that the justhub distribution isn't necessary for this -- you can do it manually. But it does make it easier. Chris

2 4

Re: [Haskell-cafe] Solved but strange error in type inference
by Yves Parès 06 Jan '12

06 Jan '12

2012/1/6 AUGER Cédric <sedrikov(a)gmail.com> > when you write "forall a. exists b. a -> b -> a", then you allow the > caller to have access to b to produce a (didn't you write "a->b->a"?) > Yes, sorry, I always assumed independence between the type variables. Like in: f :: forall a. a -> (forall b. b -> a) being the same than: f :: forall a b. a -> b -> a I should have specified: "*if* a doesn't depend on b in the latter." Of course the latter allows that, whereas the first does not (since its what prevents STRefs from escaping runST, by forbidding the return type of runST to depend on the phantom type 's' of the ST action).

2 1

Re: [Haskell-cafe] Simple type-class experiment turns out not so simple...
by "Philip K. F. Hölzenspies" 06 Jan '12

06 Jan '12

Dear Steve, et al., On 6 Jan 2012, at 11:00, <haskell-cafe-request(a)haskell.org> <haskell-cafe-request(a)haskell.org> wrote: > From: Steve Horne <sh006d3592(a)blueyonder.co.uk> > Date: 6 January 2012 10:51:58 GMT > To: Steffen Schuldenzucker <sschuldenzucker(a)uni-bonn.de> > Cc: Haskell Cafe Mailing List <haskell-cafe(a)haskell.org> > Subject: Re: [Haskell-cafe] Simple type-class experiment turns out not so simple... > > > On 06/01/2012 10:29, Steffen Schuldenzucker wrote: >> With 'd' not being mentioned anywhere, the signature of wbtData means "forall d. n -> Maybe d". In particular, wbtData == const Nothing. >> > I'm not sure what to make of that. Even if the result of wbtData is always Nothing, surely it still has a static type? I think what Steffen was saying here is that the only implementation of wbtData that satisfies the general type "forall d. n -> Maybe d" is "const Nothing" which has precisely that static type (the forall doesn't make it a dynamic type). > Precisely that. In that case, I get... > > C:\_SVN\dev_trunk\haskell\examples>ghci -XMultiParamTypeClasses > GHCi, version 7.0.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > Prelude> :load BinTree > [1 of 1] Compiling BinTree ( BinTree.hs, interpreted ) > > BinTree.hs:12:12: > Illegal instance declaration for `WalkableBinTree (BT x) x' > (All instance types must be of the form (T a1 ... an) > where a1 ... an are *distinct type variables*, > and each type variable appears at most once in the instance head. > Use -XFlexibleInstances if you want to disable this.) > In the instance declaration for `WalkableBinTree (BT x) x' > Failed, modules loaded: none. > Prelude> > > If I specify both extensions (-XMultiParamTypeClasses and -XFlexibleInstances) it seems to work, but needing two language extensions is a pretty strong hint that I'm doing it the wrong way. This isn't a general truth, but if you're still in early stages of learning about GHCs type-class implementation, you're probably right. > The goal is fairly obvious - to have type-classes for binary tree capabilities so that different implementations can support different subsets of those capabilities. Being able to walk a binary tree doesn't need ordering of keys, whereas searching does. A red-black tree needs somewhere to store it's colour in the node, yet the walking and searching functions don't need to know about that. The problem with the "forall d. n -> Maybe d" type is that it makes d too general (universal, in fact), while d is fixed by n. There is an alternative extension you may want to look into for your furtherance of the capabilities of GHC, being TypeFamilies. These would lead to the following alternative implementation: {-# LANGUAGE TypeFamilies #-} class WalkableBinTree n where type ElemTp n wbtChildren :: n -> Maybe (n, n) wbtData :: n -> Maybe (ElemTp n) instance WalkableBinTree (BT x) where type ElemTp (BT x) = x wbtChildren (Branch d l r) = Just (l, r) wbtChildren Empty = Nothing wbtData (Branch d l r) = Just d wbtData Empty = Nothing This says that the instance fixes the "element type" ElemTp to something specific. However, it seems perfectly reasonable for the goal you describe to demand that whatever tree-type this class is instantiated for must be parametric in its element type. This can be done without any language extension, i.e.: class WalkableBinTree n where wbtChildren :: n d -> Maybe (n d, n d) wbtData :: n d -> Maybe d instance WalkableBinTree BT where wbtChildren (Branch d l r) = Just (l, r) wbtChildren Empty = Nothing wbtData (Branch d l r) = Just d wbtData Empty = Nothing Notice that now, the class is instantiated for "BT" and *not* "(BT x)". > As far as I remember, none of the tutorials I've read have done this kind of thing - but it seemed an obvious thing to do. Obviously in the real world I should just use library containers, but this is about learning Haskell better in case a similar problem arises that isn't about binary trees. A good way to learn a lot about type classes is to study the default library. Admittedly, this can be a bit of a daunting task to just dive in. Luckily, Brent Yorgey wrote up a nice article that was transferred and updated by numerous people on the HaskellWiki. It's worth giving it a read: http://www.haskell.org/haskellwiki/Typeclassopedia Happy Haskelling! Regards, Philip

1 0

How to split this string.
by max 06 Jan '12

06 Jan '12

I want to write a function whose behavior is as follows: foo "string1\nstring2\r\nstring3\nstring4" = ["string1", "string2\r\nstring3", "string4"] Note the sequence "\r\n", which is ignored. How can I do this?

13 28

haxr standalone server?
by Johannes Waldmann 06 Jan '12

06 Jan '12

How could I use haxr (http://www.haskell.org/haskellwiki/HaXR) to build a stateful server? It should listen on some port, and fork threads (inside Haskell land) to handle incoming calls. Any of the Haskell web frameworks can do this? I guess this is the same question as: http://www.haskell.org/pipermail/haskell-cafe/2009-December/071185.html Thanks - J.W.

4 6

ghc default options
by Victor Miller 06 Jan '12

06 Jan '12

Is there a place where I can specify default options for ghc? I just installed ghc 7.0.4 on my Redhat system. Since gmp isn't available on our system libraries I installed gmp in the lib file in my home directory. I've set LIB_PATH and LD_LIBRARY_PATH to point to it. ghci works ok (it finds the dynamic link library in my directory), but unless I add -L$HOME/lib as an option to ghc --make it can't find it. So how can I tell ghc to look in that directory by default? Because of this I can't install the haskell platform. Victor PS. I spent a while looking at the ghc manual but couldn't find anything appropriate.

2 1

Monadic computation must now do IO, fails when type changed to IO.
by Matthew Farkas-Dyck 06 Jan '12

06 Jan '12

Dear fellow Haskellers, I have written an SMTP server (Main.hs at http://hpaste.org/56134, full git repo at http://strake.zanity.net:1104/ymail.git) which works, mostly – it responds to every message with that it was sent properly, whether it was or not. (Try it: send an e-mail by SMTP to this_is_not_a_user(a)strake.zanity.net or somesuch.) The reason is, that it simply tells the message (envelope, data) in a Writer monad, which is later piped to the local delivery agent. As I said, this works, but of course is suboptimal. I tried to change the type of main_ to (MonadState MTPState m, MonadIO m) => [Char] -> m ([Char], [Char]), just calling LDA in main_ (when mode is MTPTextMode) rather than after, but then the program output nil. I'm not sure what the problem is – I thought IO might not be lazy enough so I tried a lazy wrapped-IO monad, in vain. How, then, can this program call the LDA, wait to know whether it worked or failed, and then respond? Thanks for any help. Cheers, M Farkas-Dyck

1 0

Type class for sequences with dependent types
by Robbert Krebbers 06 Jan '12

06 Jan '12

Hello, in a Haskell development I have to represent paths that have elements of alternating types. GADTs allow me to do this easily: data AltList :: * -> * -> * where Nil :: AltList a a ICons :: Int -> AltList Int b -> AltList () b UCons :: () -> AltList () b -> AltList Int b Since I have various kinds of these data structures I defined a type class for common operations on such data structures. class DepSequence l where nil :: l a a app :: l a b -> l b c -> l a c The instance for AltList is as follows: instance DepSequence AltList where nil = Nil Nil `app` k = k ICons i l `app` k = ICons i (l `app` k) UCons i l `app` k = UCons i (l `app` k) This all works nicely, however, I also want ordinary lists to be an instance of this class too. I tried the following: type IntListAlt a b = [Int] instance DepSequence IntListAlt where nil = [] app = (++) But GHC does not like this, it yields: Type synonym `IntListAlt' should have 2 arguments, but has been given none In the instance declaration for `DepList IntListAlt' The following alternative works, but it is quite ugly newtype IntList a b = IntList { getList :: [Int] } instance DepSequence IntList where nil = IntList [] app l k = IntList (getList l ++ getList k) and also does not give me a nil of type [Int] and an app of type [Int] -> [Int] -> [Int]. Does anyone know whether Haskell allows me to do this in a better way? Best, Robbert

3 3

Sudden monomorphism with -XTypeFamilies
by Rian Hunter 05 Jan '12

05 Jan '12

hello i'm getting inconsistent monomorphism behavior with the same code only depending on whether or not -XTypeFamilies is enabled: ---- {-# LANGUAGE TypeFamilies #-} snda :: a -> b -> b snda ba = id main = do let ma = (return () :: IO ()) mBox bb = snda ma bb mBox $ return (4 :: Int) mBox $ return "G" return () ---- in the preceding example, if -XTypeFamilies is enabled then "mBox" is monomorphic and the program will terminate early, otherwise, it's polymorphic and the program will complete successfully. i think i understand why this is the case but i couldn't find documentation on this inconsistency anywhere. is this expected behavior or is this a bug in GHC? thanks! rian

2 1

Re: [Haskell-cafe] Package Versioning Policy
by Christoph Breitkopf 05 Jan '12

05 Jan '12

Forgot the header, sorry. On Thu, Jan 5, 2012 at 5:54 PM, Christoph Breitkopf < chbreitkopf(a)googlemail.com> wrote: > Hello, > > I'm trying to figure out how to handle versioning of my IntervalMap > package. I've just read the package versioning policy: > http://www.haskell.org/haskellwiki/Package_versioning_policy > > I don't quite understand all the recommendations in the above document, > though: > > a) You are not allowed to remove or change the types of existing stuff. Ok. > > b) You are allowed to add new functions. But that can break compilation > because of name conflicts. Seems to be allowed on the grounds that this is > easy to fix in the client code. > > c) You are not allowed to add new instances. I don't get this - how is > this any worse than b)? > > I do understand that it is not generally possible to prevent breaking code > - for example if the client code depends on buggy behavior that gets fixed > in a minor version update. That seems unavoidable - after all, bugfixes are > _the_ reason for minor updates. > > Regards, > > Chris > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

3 6

Get a variable's type in quasiquote
by Jonathan Geddes 05 Jan '12

05 Jan '12

Cafe, I'm playing around with Template Haskell, specifically QuasiQuotes and I've run into something that I hope is not an inherent limitation in TH. Specifically I want to get the type of a variable whose name is used in a QuasiQuote. The code generated by the QQ should depend on the type of the variables that are to be antiquoted. For example let a = True in [qq | a |] should result in different code being generated by the qq than let a = 42 in [qq | a |] because the type of variable "a" is different. So far I've tried simple reification, but > quote = do >let varname = "someVariableKnownToExist" info <- reify $ mkName str

1 1

Versioning policy and dependencies
by Magnus Therning 05 Jan '12

05 Jan '12

Lately I've often thought that the versioning policy only addresses half of the problem: the API. While it completely neglects the "other side" of the package surface: the dependencies. I should probably mention that this springs from my work with packaging Haskell for ArchLinux and to be honest I'm not sure it's a worthwhile goal for the community to put much work into simplifying the work of distro packagers. Anyway, I think it is worthwhile thinking about and explicitly stating what the goals and non-goals of the versioning policy are. If the following statement would hold, then my work would become a bit easier: If I have a set of packages where all dependencies are satisfied, then it should be possible to update any of those packages to a new minor version (e.g. from X.Y.Z to X.Y.Z+1) without any further updates. I believe the following rules would help achieving that: - Use dependencies that are insensitive to changes in minor versions as far as possible. - Increase the major version if the lower bound of a dependency is adjusted up to a new major version. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

1 0

(no subject)
by Christoph Breitkopf 05 Jan '12

05 Jan '12

Hello, I'm trying to figure out how to handle versioning of my IntervalMap package. I've just read the package versioning policy: http://www.haskell.org/haskellwiki/Package_versioning_policy I don't quite understand all the recommendations in the above document, though: a) You are not allowed to remove or change the types of existing stuff. Ok. b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code. c) You are not allowed to add new instances. I don't get this - how is this any worse than b)? I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates. Regards, Chris

2 1

Re: [Haskell-cafe] [Haskell-beginners] WinRT and Haskell
by Antoine Latter 05 Jan '12

05 Jan '12

On Thu, Jan 5, 2012 at 9:55 AM, AbdulSattar Mohammed <codingtales(a)gmail.com> wrote: > WinRT has a concept of projections that expose its API. Microsoft has > implemented projections for Native (C and C++), HTML/Javascript and .NET > (from Miguel de Caza's WinRT demystified > post: http://tirania.org/blog/archive/2011/Sep-15.html) There's no mention > of creating your own projections (or I have seen none). I don't see any > reason why we can't create our own projections. If it's possible a Haskell > projection could really help. > Yep, that's what I was thinking of. I'm pretty sure the C/C++ projections rely on compiler extensions for the MS C/C++ compiler, so I don't think we could use those directly from Haskell. Antoine > > On Thu, Jan 5, 2012 at 8:11 PM, Antoine Latter <aslatter(a)gmail.com> wrote: >> >> On Thu, Jan 5, 2012 at 5:12 AM, AbdulSattar Mohammed >> <codingtales(a)gmail.com> wrote: >> > I suppose this should go into the GUI mailing list, but it is filled >> > with >> > spam. So, WinRT does not depend on the .NET Framework. C++ applications >> > can >> > directly compile to x86 and be able to use WinRT. Do we have a room for >> > Haskell development there? >> > >> >> From what I understand, WinRT is a set of COM libraries - C++ can >> directly compile to it because the MS C++ compiler has special >> extensions to handle the COM resources in the library. >> >> There is a COM library for Haskell: >> >> http://hackage.haskell.org/package/com >> >> But I've never used it. >> >> The API is encoded in a special meta-data format, which is then used >> by C++, .NET and Javascript to create the language-specific APIs - it >> might be possible to generate Haskell bindings to the COM components >> from this metadata. >> >> Antoine > > > > > -- > Warm Regards, > > AbdulSattar Mohammed

1 0

Solved but strange error in type inference
by AUGER Cédric 05 Jan '12

05 Jan '12

Hi all, I am an Haskell newbie; can someone explain me why there is no reported error in @legSome@ but there is one in @legSomeb@ (I used leksah as an IDE, and my compiler is: $ ghc -v Glasgow Haskell Compiler, Version 7.2.1, stage 2 booted by GHC version 6.12.3 ) What I do not understand is that the only difference was a typing anotation to help the type inference, but I believed that this annotation was already given by the signature I give, so I am quite lost. Thanks in advance! ====================================================================== {-# OPTIONS_GHC -XScopedTypeVariables #-} -- why isn't this option always enabled... {-# OPTIONS_GHC -XGADTs #-} import Data.Word import qualified Data.Map as M import qualified Data.Set as S data Symbols nt t = NT nt -- ^ non terminal | T t -- ^ terminal deriving (Eq, Ord) type Sem s = [s]->s data Rule nt t s = Rule { refined :: nt , expression :: [Symbols nt t] , emit :: Sem s } type RRule nt t s = ([Symbols nt t], Sem s) data LegGram nt t s = Ord nt => LegGram (M.Map nt [RRule nt t s]) legSome :: LegGram nt t s -> nt -> Either String ([t], s) -- ^^^^^^^^^^^^^^ -- isn't this redundant? -- vvvvvvvvvvvvvv legSome ((LegGram g)::LegGram nt t s) ntV = case M.lookup ntV g of Nothing -> Left "No word accepted!" Just l -> let sg = legSome (LegGram (M.delete ntV g)) subsome :: [RRule nt t s] -> Either String ([t], s) subsome [] = Left "No word accepted!" subsome ((r,sem):l) = let makeWord [] = Right ([],[]) makeWord ((NT nnt):ll) = do (m, ss) <- sg nnt (mm, sss) <- makeWord ll return (m++mm, ss:sss) makeWord ((T tt):ll) = do (mm, sss) <- makeWord ll return (tt:mm, sss) in case makeWord r of Right (ll, mm) -> Right (ll, sem mm) Left err -> subsome l in subsome l legSomeb :: LegGram nt t s -> nt -> Either String ([t], s) -- but without it I have an error reported legSomeb (LegGram g) ntV = case M.lookup ntV g of Nothing -> Left "No word accepted!" Just l -> let sg = legSomeb (LegGram (M.delete ntV g)) subsome :: [RRule nt t s] -> Either String ([t], s) subsome [] = Left "No word accepted!" subsome ((r,sem):l) = let makeWord [] = Right ([],[]) makeWord ((NT nnt):ll) = do (m, ss) <- sg nnt (mm, sss) <- makeWord ll return (m++mm, ss:sss) makeWord ((T tt):ll) = do (mm, sss) <- makeWord ll return (tt:mm, sss) in case makeWord r of Right (ll, mm) -> Right (ll, sem mm) Left err -> subsome l in subsome l

8 45

buildDepends syntax and checks
by Shakthi Kannan 05 Jan '12

05 Jan '12

Hi, #1 I would like to know if there is any context grammar or syntax for the package dependencies that are allowed in buildDepends in each .cabal file? AnyVersion and WildcardVersion are consistent. But, I see quite a bit of variations in what is included in UnionVersionRange and IntersectVersionRange. For example: * Two WildcardVersions in a UnionVersionRange (fixed-point 0.5.0.1) [1] * UnionVersionRange and WildcardVersion in a IntersectVersionRange (hlint 1.6.12) [2] #2 Is there a way to cross-check if the defined dependencies are in fact correct, or is it left to the package owner to write them? #3 Some dependencies have an 'or' for the same package (bytestring 0.9) [3], like "base (<3) or array, base (≥3)", and the cabal file says: library if flag(split-base) build-depends: base >= 3, array else build-depends: base < 3 I use the a script [4] to convert the .cabal files to .json, then the .json lists both the build-depends! Appreciate any inputs in this regard! Thanks! SK [1] fixed-point 0.5.0.1 (see base). http://hackage.haskell.org/packages/archive/fixed-point/0.5.0.1/fixed-point… [2] hlint 1.6.12 (see uniplate). http://hackage.haskell.org/packages/archive/hlint/1.6.12/hlint.cabal [3] bytestring 0.9. http://hackage.haskell.org/package/bytestring-0.9 [4] Cabal2json.hs. http://shakthimaan.fedorapeople.org/SOURCES/Cabal2json.hs -- Shakthi Kannan http://www.shakthimaan.com

2 1

Composing analyses.
by Serguey Zefirov 04 Jan '12

04 Jan '12

I am trying to create a stack of analyses. There are basic analyses then there are derived analyses that create a DAG of analyses. I thought I can express their relationship through type classes, but I failed. I've attached the source of my failure. Main points are below: getAnalysisResult :: EnabledAnalysis a as => a -> M as Int getAnalysisResult _ = error "getAnalysisResult!!!" setAnalysisResult :: EnabledAnalysis a as => a -> Int -> M as () setAnalysisResult _ _ = error "setAnalysisResult!!!" -- |Analysis interface. What to require and what to perform. class (Analyses (RequiresAnalyses a)) => Analysis a where -- |What has to be done before our pass. type RequiresAnalyses a -- |Perform an analysis. perform :: (EnabledAnalysis a as, EnabledAnalyses (RequiresAnalyses a) as) => a -> M as () data AnalysisNotEnabled a -- |Check if analysis is enabled. class EnabledAnalysis a as instance (FAIL (AnalysisNotEnabled a)) => EnabledAnalysis a Nil instance (Analysis a, Analyses as) => EnabledAnalysis a (a :. as) instance (Analysis a, Analysis a', EnabledAnalysis a as) => EnabledAnalysis a (a' :. as) -- |Check if a group of analyses is enabled. class EnabledAnalyses as eas instance EnabledAnalyses Nil eas instance (EnabledAnalyses as eas, EnabledAnalysis a eas) => EnabledAnalyses (a :. as) eas -- Base analysis. data Base = Base instance Analysis Base where type RequiresAnalyses Base = Nil perform a = do x <- getAnalysisResult a setAnalysisResult a (x+1) -- And analysis derived from Base. data Derived = Derived instance Analysis Derived where type RequiresAnalyses Derived = Base :. Nil -- !!! this is the source of problems -- the type here is -- (EnabledAnalysis Derived as, EnabledAnalyses (Base :. Nil) as) => -- Derived -> M as () -- Looks like ghc does not expand RequiresAnalyses Derived. perform a = do x <- getAnalysisResult a y <- getAnalysisResult Base setAnalysisResult a (x+y) -- here I expanded RequiresAnalysis Derived manually. -- ghc thinks that "EnabledAnalyses (Base :. Nil) as" does not imply "EnableAnalysis Base as". -- it is weird. performDerived :: (EnabledAnalysis Derived as, EnabledAnalyses (Base :. Nil) as) => Derived -> M as () performDerived a = do x <- getAnalysisResult a y <- getAnalysisResult Base setAnalysisResult a (x+y) This is behavior of ghc 6.12.1, 7.0.4 and 7.2.1. Is it right behavior? The main question is: is it possible to combine computations like this? How should one do this? I thinking about abandoning type classes altogether. I think I can do it some other way. But out of curiosity - why is that?

1 0

Re: [Haskell-cafe] Solved but strange error in type inference
by oleg＠okmij.org 04 Jan '12

04 Jan '12

One should keep in mind the distinction between schematic variables (which participate in unification) and universally quantified variables. Let's look at the forall-elimination rule G |- e : forall a. A -------------------- E G |- e : A[a := t] If the term e has the type forall a. A, we can use the term at some specific type t. Often the type checker doesn't know which specific type t to choose. Therefore, the type checker inserts a schematic type variable X (think of Prolog logic variable), to defer the decision. Further down the type-checking road, more information becomes available and it will become clear what concrete type t to use. Like in Prolog, a logic variable denotes a guess, or a promise, to be forced later (there is a deep connection between laziness and logic variables). So, the forall-elimination rule becomes G |- e : forall a. A -------------------- E G |- e : A[a := X] Let's look at the forall-introduction rule G |- e : A [a := aeigen] -------------------- I where aeigen \not\in G G |- e : forall a. A To type-check that a term e has a polymorphic type (which happens when the user gave a type signatures which contains type variables, implicitly quantified), the type-checker generates a fresh, unique _constant_ (called eigenvariable) and type-checks the term with the constant substituted for the type variable. If the term type-checks, it does have the polymorphic type. (One may ask why this fresh constant is called eigen_variable_ if it doesn't actually vary. That is a very good question, answered in http://okmij.org/ftp/formalizations/inductive-definitions.html#eigenvariabl… ). GHC calls these eigenvariable rigid variables. The upshot: eigenvariabes are constants and can't be changed by unification. Schematic variables are variables and can be substituted by unification. Quantified type variables are replaced by schematic variables when _using_ a polymorphic term. Quantified type variables are replaced by constants (or, rigid variables) when _type-checking_ a term. The earlier example: f :: a -> a f x = x :: a can be alpha-converted [recall, ScopedTypeVariable extension is off] as f :: a -> a f x = x :: b First the type-checker generates beigen. To check if 'f' can indeed be given the type signature a -> a, GHC generates the eigenvariable aeigen and type-checks (\x::aeigen -> x :: beigen) :: aeigen The problem becomes obvious. The error message is very precise, describing the precise location where type variables are bound. Couldn't match type `a' with `b' `a' is a rigid type variable bound by the type signature for f :: a -> a at /tmp/e.hs:2:1 `b' is a rigid type variable bound by an expression type signature: b at /tmp/e.hs:2:7 In the expression: x :: b In an equation for `f': f x = x :: b Again, read `rigid type variable' as eigen-variable. In OCaml, type variables are schematic variables (in many contexts). For example: # let f1 (x:'a) = (x:'b);; val f1 : 'a -> 'a = <fun> # let f2 (x:'a) = x + 1;; val f2 : int -> int = <fun> The function f2 is not polymorphic at all, although it may appear so from the use of the type variable 'a. But in other contexts OCaml does work like GHC: # module F : sig val f5 : 'a -> 'a end = struct let f5 x = x + 1 end;; Error: Signature mismatch: Modules do not match: sig val f5 : int -> int end is not included in sig val f5 : 'a -> 'a end Values do not match: val f5 : int -> int is not included in val f5 : 'a -> 'a Further, OCaml has now a specific construct to introduce rigid type variables (which appear as type constants). # let f4 (type a) (x:a) = (x:a) + 1;; Characters 25-26: let f4 (type a) (x:a) = (x:a) + 1;; ^ Error: This expression has type a but an expression was expected of type int

1 0

GHC compilation issue: Working around bug #4374?
by Sanket Agrawal 04 Jan '12

04 Jan '12

I am getting the compilation error below when building GHC 7.0.4 on RHEL5 (x86_64) – I configured make to point to ncurses and libgmp. I will appreciated pointers on how to work around the issue below. I don’t have root privileges. My apologies if this has already been discussed in this forum. I searched for the issue but could find only the GHC bug ticket below. GHC bug ticket: http://hackage.haskell.org/trac/ghc/ticket/4374 - it doesn’t have description on how to work around the bug. Compilation error: ----------------------- $ C_INCLUDE_PATH=/efs/dist/fsf/ncurses/5.6/common/include/ncurses:/home/saagrawa/scripts/misc/libgmp/include LIBRARY_PATH=/efs/dist/fsf/ncurses/5.6/exec/lib:/home/saagrawa/scripts/misc/libgmp/lib make ===--- updating makefiles phase 0 make -r --no-print-directory -f ghc.mk phase=0 just-makefiles ===--- updating makefiles phase 1 make -r --no-print-directory -f ghc.mk phase=1 just-makefiles ===--- updating makefiles phase 2 make -r --no-print-directory -f ghc.mk phase=2 just-makefiles ===--- updating makefiles phase 3 make -r --no-print-directory -f ghc.mk phase=3 just-makefiles ===--- finished updating makefiles make -r --no-print-directory -f ghc.mk all "inplace/bin/ghc-stage1" libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o `/usr/bin/find libraries/integer-gmp/dist-install/build -name "*_stub.dyn_o" -print` -shared -dynamic -dynload deploy -dylib-install-name /home/saagrawa/scripts/misc/ghc/7.0.4/lib/ghc-7.0.4/`basename "libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so" | sed 's/^libHS//;s/[-]ghc.*//'`/`basename "libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so"` -no-auto-link-packages -package ghc-prim-0.2.0.0 -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so /efs/dist/fsf/gcc/4.4.3-build004/.exec/x86-64.rhel.5/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so] Error 1 make: *** [all] Error 2 $ ll /home/saagrawa/scripts/misc/libgmp/lib|awk '{print $9,$10,$11}' ### the libgmp lib folder has dynamic libraries libgmp.so.3.5.2* libgmp.so.3 -> libgmp.so.3.5.2* libgmp.so -> libgmp.so.3.5.2* libgmp.la* libgmp.a

1 1

Re: [Haskell-cafe] Experiments in Haskell Packaging
by Chris Dornan 03 Jan '12

03 Jan '12

Hi Ryan, Ryan Grant [mailto:rgrant@rgrant.org] said: > Are packages cabal-installed using --global? The packages that come with a compiler or Haskell Platform are installed --global. Every other package is installed with cabal, by default into the user's space. > Is it mostly reliant on cabal or cabal-dev? It works with cabal. I have not tested interworking with cabal-dev yet. (There is a big overlap in the functionality of course.) > How easily can I upgrade cabal? > http://stackoverflow.com/questions/5380888/cabal-install-and-debian The stackoverflow discussion seems a little confused in that 'cabal update' just updates the local cache of package headers from the server, not any of the installed packages. But I am using the latest version of cabal-install (0.10.2), compiled with cabal-1.10.1.0 library (from March rather than June's cabal-1.10.2.0). Users should never have to build their own cabal-install, but just keep up to date with the distro. If users should need to use their own private Cabal builds for whatever reason we will provide a wiki page showing them how to do it. > Can the idea be extended to OSX, as well? I see no reason why not. The idea behind my post was really to say that we should be doing this with all distros. I will be making the hub sources available through hackage/github when beta testing is complete (but sooner if demand dictates). Folks can install it on their own systems and hook in their own GHC and HP builds. Best of all folks can make it available in other Haskell distros. The interesting question is whether anyone else decides to structure their distros in the same way as the justhub distro. That is the real challenge! > How does this strategy relate to the Nix package manager? > http://nixos.org/nix/ In a sense the philosophy is similar because I am arguing that we shouldn't be updating distributions, just adding to them. In that sense it is a functional philosophy. But after that 30,000 foot observation the comparison diverges as far as I can see. Great questions! Thanks, Chris

1 0

Is the haddock generator on Hackage down?
by Bardur Arantsson 03 Jan '12

03 Jan '12

Hi all, No Haddock documentation seems to have been generated on Hackage in the past few days. See e.g. http://hackage.haskell.org/package/copilot-2.0.3 or http://hackage.haskell.org/package/derive-2.5.5 Does anyone know if the cron job (or whatever) isn't running for some reason? Cheers,

2 1

space-efficient, composable list transformers [was: Re: Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]]
by Sebastian Fischer 03 Jan '12

03 Jan '12

Hello Heinrich, On Tue, Dec 27, 2011 at 1:09 PM, Heinrich Apfelmus < apfelmus(a)quantentunnel.de> wrote: > Sebastian Fischer wrote: > >> all functions defined in terms of `ListTo` and `interpret` >> are spine strict - they return a result only after consuming all input >> list >> constructors. > > Indeed, the trouble is that my original formulation cannot return a result > before it has evaluated all the case expressions. To include laziness, we > need a way to return results early. > > Sebastian's ListTransformer type does precisely that for the special > case of lists as results, Hmm, I think it does more than that.. (see below) but it turns out that there is also a completely generic way of returning > results early. In particular, we can leverage lazy evaluation for the > result type. > This is nice! It would be cool if we could get the benefits of ListConsumer and ListTransformer in a single data type. I know that you chose these names to avoid confusion, but I would like to > advertise again the idea of choosing the *same* names for the constructors > as the combinators they represent [...] This technique for designing data > structures has the huge advantage that it's immediately clear how to > interpret it and which laws are supposed to hold. I also like your names better, although they suggest that there is a single possible interpretation function. Even at the expense of blinding eyes to the possibility of other interpretation functions, I agree that it makes things clearer to use names from a *motivating* interpretation. In hindsight, my names for the constructors of ListTransformer seem to be inspired by operations on handles. So, `Cut` should have been named `Close` instead.. > Especially in the case of lists, I think that this approach clears up a > lot of confusion about seemingly new concepts like Iteratees and so on. A share the discomfort with seemingly alien concepts and agree that clarity of exposition is crucial, both for the meaning of defined combinators and their implementation. We should aim at combinators that people are already familiar with, either because they are commonplace (like id, (.), or fmap) or because they are used by many other libraries (like the Applicative combinators). A good way to explain the meaning of the combinators is via the meaning of the same combinators on a familiar type. Your interpretation function is a type-class morphism from `ListTo a b` to `[a] -> b`. For Functor we have: interpret (fmap f a) = fmap f (interpret a) On the left side, we use `fmap` for `ListTo a` on the right side for `((->) l)`. Similarly, we have the following properties for the coresponding Applicative instances: interpret (pure x) = pure x interpret (a <*> b) = interpret a <*> interpret b Such morphism properties simplify how to think about programs a lot, because one can think about programs as if they were written in the *meaning* type without knowing anything about the *implementation* type. The computed results are the same but they are computed more efficiently. Your `ListTo` type achieves space efficiency for Applicative composition of list functions by executing them in lock-step. Because of the additional laziness provided by the `Fmap` constructor, compositions like interpret a . interpret b can also be executed in constant space. However, we cannot use the space efficient Applicative combinators again to form parallel compositions of sequential ones because we are already in the meaning type. We could implement composition for the `ListTo` type as follows (<.) :: ListTo b c -> ListTo a [b] -> ListTo a c a <. b = interpret a <$> b But if we use a result of this function as argument of <*>, then the advantage of using `ListTo` is lost. While interpret ((,) <$> andL <*> andL) runs in constant space, interpret ((,) <$> (andL <. idL) <*> (andL <. idL)) does not. The ListTransformer type supports composition in lock-step via a category instance. The meaning of `ListTransformer a b` is `[a] -> [b]` with the additional restriction that all functions `f` in the image of the interpretation function are incremental: xs `isPrefixOf` ys ==> f xs `isPrefixOf` f ys Composition as implemented in the ListTransformer type satisfies morphism properties for the category instance: transformList id = id transformList (a . b) = transformList a . transformList b As it is implemented on the ListTransformer type directly (without using the interpretation function), it can be combined with the Applicative instance for parallel composition without losing space efficiency. The Applicative instance for `ListTransformer` is different from the Applicative instance for `ListTo` (or `ListConsumer`). While interpret ((,) <$> idL <*> idL) is of type `[a] -> ([a],[a])` transformList ((,) <$> idL <*> idL) is of type `[a] -> [(a,a)]`. We could achieve the latter behaviour with the former instance by using an additional fmap. But uncurry zip <$> ((,) <$> idL <*> idL) has the same disadvantages regarding space efficiency as referred to above because the computation of `zip` cannot occur in lock-step with another computation. The meaning of the Applicative instance of `ListTransformer` can again be described using morphism properties on Applicative structures. The corresponding structure on the meaning type `[a] -> [b]` is the following combination of the Applicative instances for functions and for ZipLists. fmap f a = liftA (fmap f) a pure x = pure (getZipList (pure x)) a <*> b = getZipList <$> liftA2 (<*>) (ZipList <$> a) (ZipList <$> b) I have a gut feeling that the laziness provided by the `Fmap` constructor is too implicit to be useful for the kind of lock-step composition provided by ListTransformer. So I don't have high hopes that we can unify `ListConsumer` and `ListTransformer` into a single type. Do you have an idea? Sebastian

3 3

Avoiding parametric function binding
by Kevin Quick 03 Jan '12

03 Jan '12

I'm having some difficulty avoiding a tight parametric binding of function parameters, which is limiting the (de)composability of my expressions. I'm curious as to whether there is an option or method I haven't tried to achieve this. Here's an example test case: > data Var = V1 (Maybe Int) > | V2 (Maybe String) > > test = V1 (Just 1) Given this structure, I can do something like this: > elemStr :: (Show a) => Maybe a -> String > elemStr = show > > varStr (V1 x) = elemStr $ id x > varStr (V2 x) = elemStr $ id x > > main = putStrLn . varStr $ test This operation extracted the internal value from the Var container, and then passes it to a parametric function (id) and that result to another parametric function with a class restriction on the input. This is fine so-far. However, what I'd like to do is decompose this to allow more flexibility (using id is pretty boring) without having to repeat the extraction boilerplate each time. My first attempt: > varElem :: forall x . (Show x) => Var -> x > varElem (V1 x) = x > varElem (V2 x) = x > > main = putStrLn . elemStr . varElem $ test This fails because even though I've specified the same class constraint for the output type of varElem that elemStr requires on its input element, the compiler binds the parametric type of x when it processes the first (V1) definition and fails with an error on the second definition because it asserts that x must be an Int and it found a String. I realized that the parametric output type was awkward, so I tried inverting the design (somewhat similar to fmap): > onVarElem :: forall a . (Show a) => (Maybe a -> String) -> Var -> String > onVarElem f (V1 x) = f x > onVarElem f (V2 x) = f x > > main = putStrLn . onVarElem elemStr $ test This is probably a better design, but still fails for the same reason: Couldn't match expected type `Int' with actual type `[Char]' Expected type: Maybe Int Actual type: Maybe String In the first argument of `f', namely `x' In the expression: f x Even changing onVarElem so the second parameter was a simple variable and performing the pattern match in an internal where or let binding failed because the first application of f bind its parametric values. Is there a way to delay this parametric binding to allow composable function specifications? Thanks, Kevin -- -KQ

4 5

More cabal install problems
by Victor Miller 03 Jan '12

03 Jan '12

I've been trying to install threadscope on my macbook pro runing OSX 10.7 (Lion). This hasn't been easy. Thanks to help here, I finally got glib installed, but now one of the hangups is in installing the package gio. The following happens: Building gio-0.12.2... Building library... creating dist/build /usr/bin/ghc --make -package-name gio-0.12.2 -hide-all-packages -fbuilding-cabal-package -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Idist/build/autogen -Idist/build -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id array-0.3.0.2-143060371bda4ff52c270d1067551fe8 -package-id base-4.3.1.0-239d76b73f466dc120129098b3472858 -package-id bytestring-0.9.1.10-5bb17614aed376ea31b721a9272770b1 -package-id containers-0.4.0.0-b4885363abca642443ccd842502a3b7e -package-id glib-0.12.2-185c12da89238d25c489c0b80fc015c5 -package-id mtl-2.0.1.0-5b7a9cce5565d8cc8721ba4f95becf1b -O -XHaskell98 -XForeignFunctionInterface System.GIO System.GIO.Enums System.GIO.Types System.GIO.Async.AsyncResult System.GIO.Signals System.GIO.Async.Cancellable System.GIO.File.AppInfo System.GIO.File.ContentType System.GIO.File.FileAttribute System.GIO.File.File System.GIO.File.FileEnumerator System.GIO.File.FileInfo System.GIO.File.FileMonitor System.GIO.File.IOError System.GIO.File.MountOperation System.GIO.Icons.Emblem System.GIO.Icons.EmblemedIcon System.GIO.Icons.FileIcon System.GIO.Icons.Icon System.GIO.Icons.ThemedIcon System.GIO.Volumes.Drive System.GIO.Volumes.Mount System.GIO.Volumes.Volume System.GIO.Volumes.VolumeMonitor <command line>: cannot satisfy -package-id mtl-2.0.1.0-5b7a9cce5565d8cc8721ba4f95becf1b (use -v for more information) World file is already up to date. cabal: Error: some packages failed to install: gio-0.12.2 failed during the building phase. The exception was: ExitFailure 1 ------- However, cabal list tells me: * mtl Synopsis: Monad classes, using functional dependencies Default available version: 2.0.1.0 Installed versions: 2.0.1.0 License: BSD3 which tells me that the version of mtl that's desired is already installed. Any suggestions? Victor

2 2

On the purity of Haskell
by Steve Horne 03 Jan '12

03 Jan '12

This is just my view on whether Haskell is pure, being offered up for criticism. I haven't seen this view explicitly articulated anywhere before, but it does seem to be implicit in a lot of explanations - in particular the description of Monads in SBCs "Tackling the Awkward Squad". I'm entirely focused on the IO monad here, but aware that it's just one concrete case of an abstraction. Warning - it may look like trolling at various points. Please keep going to the end before making a judgement. To make the context explicit, there are two apparently conflicting viewpoints on Haskell... 1. The whole point of the IO monad is to support programming with side-effecting actions - ie impurity. 2. The IO monad is just a monad - a generic type (IO actions), a couple of operators (primarily return and bind) and some rules - within a pure functional language. You can't create impurity by taking a subset of a pure language. My view is that both of these are correct, each from a particular point of view. Furthermore, by essentially the same arguments, C is also both an impure language and a pure one. See what I mean about the trolling thing? I'm actually quite serious about this, though - and by the end I think Haskell advocates will generally approve. First assertion... Haskell is a pure functional language, but only from the compile-time point of view. The compiler manipulates and composes IO actions (among other things). The final resulting IO actions are finally swallowed by unsafePerformIO or returned from main. However, Haskell is an impure side-effecting language from the run-time point of view - when the composed actions are executed. Impurity doesn't magically spring from the ether - it results from the translation by the compiler of IO actions to executable code and the execution of that code. In this sense, IO actions are directly equivalent to the AST nodes in a C compiler. A C compiler can be written in a purely functional way - in principle it's just a pure function that accepts a string (source code) and returns another string (executable code). I'm fudging issues like separate compilation and #include, but all of these can be resolved in principle in a pure functional way. Everything a C compiler does at compile time is therefore, in principle, purely functional. In fact, in the implementation of Haskell compilers, IO actions almost certainly *are* ASTs. Obviously there's some interesting aspects to that such as all the partially evaluated and unevaluated functions. But even a partially evaluated function has a representation within a compiler that can be considered an AST node, and even AST nodes within a C compiler may represent partially evaluated functions. Even the return and bind operators are there within the C compiler in a sense, similar to the do notation in Haskell. Values are converted into actions. Actions are sequenced. Though the more primitive form isn't directly available to the programmer, it could easily be explicitly present within the compiler. What about variables? What about referential transparency? Well, to a compiler writer (and equally for this argument) an identifier is not the same thing as the variable it references. One way to model the situation is that for every function in a C program, all explicit parameters are implicitly within the IO monad. There is one implicit parameter too - a kind of IORef to the whole system memory. Identifiers have values which identify where the variable is within the big implicit IORef. So all the manipulation of identifiers and their reference-like values is purely functional. Actual handling of variables stored within the big implicit IORef is deferred until run-time. So once you accept that there's an implicit big IORef parameter to every function, by the usual definition of referential transparency, C is as transparent as Haskell. The compile-time result of each function is completely determined by its (implicit and explicit) parameters - it's just that that result is typically a way to look up the run-time result within the big IORef later. What's different about Haskell relative to C therefore... 1. The style of the "AST" is different. It still amounts to the same thing in this argument, but the fact that most AST nodes are simply partially-evaluated functions has significant practical consequences, especially with laziness mixed in too. There's a deep connection between the compile-time and run-time models (contrast C++ templates). 2. The IO monad is explicit in Haskell - side-effects are only permitted (even at run-time) where the programmer has explicitly opted to allow them. 3. IORefs are explicit in Haskell - instead of always having one you can have none, one or many. This is relevant to an alternative definition of referential transparency. Politicians aren't considered transparent when they bury the relevant in a mass of the irrelevant, and even pure functions can be considered to lack transparency in that sense. Haskell allows (and encourages) you to focus in on the relevant - to reference an IORef Bool or an IORef Int rather than dealing with an IORef Everything. That last sentence of the third point is my most recent eureka - not so long ago I posted a "Haskell is just using misleading definitions - it's no more transparent than C" rant, possibly on Stack Overflow. Wrong again :-( So - what do you think?

25 119

Experiments in Haskell Packaging
by Chris Dornan 02 Jan '12

02 Jan '12

[I am sorry for if get two copies of this -- no sign of the first copy.] The justhub.org Haskell distribution for Enterprise Linux (RHEL/CentOS 5 & 6) is now live. The distribution deviates from current practice. When you upgrade to a new Haskell Platform you add the new platform to your Haskell infrastructure rather than replacing the old platform with a new one. Why? • Stability: Enterprise Linux places a strong emphasis on stability and updating packages should not break things. (This has provided some challenges for us as RHEL 5 is still using GCC 4.1.2 and Binutils 2.17.50.) • Flexibility: Different projects will in general need to work with different versions of the platform and toolkits and upgrade according to their own schedules. I believe Haskell’s strong-typing sharpens the need for this. Production projects will need to upgrade according to their own schedules while other projects will want to stay up-to-date. In general when you check out a source tree you want to build with the tools and libraries that it has been tested with and move on according to the project’s timetable. • Sandboxes: The same mechanism for managing the multiple toolkits and platforms can be adapted to provide an integrated sandbox utility. The logic that dictates that projects have different tool-chain requirements applies to the user packages too. (‘Handbox’ doesn’t really work so we use Hubs instead.) • Package Deletion: The infrastructure can also be expanded to complete the package management tools with package removal and garbage collection of library code. • The Catalogue: All of the GHC releases can be added as they become available. In general the distribution works just like any other – after an upgrade invoking ‘ghc’ without any other configuration will invoke the compiler for that latest platform, which should behave as it would on any other (working) distribution. But after an upgrade: • any projects configured to work with specific tool chains and libraries will continue undisturbed; • you can create a new hub based on the new platform and experiment with it on newly-checked-out source tree without disturbing an existing working tree (or just swap the hub into an existing work tree and back out again if things don’t work out); • even on release of a new version of a package (or if you want to experiment with your existing packages) you can easily duplicate an existing hub and delete, upgrade and add packages on a topic branch. Of course ‘serious developers’ have been doing this with home-brew infrastructure for ever. Nevertheless I have found doing it with well-integrated tools to be quite liberating. It might also help new users to make the transition to serious developers more quickly. Thoughts anyone? Chris

1 0

proxy settings with simpleHttp
by hanjoosten 02 Jan '12

02 Jan '12

Hi, I am fiddling around with the package http-enumerator to download web pages. I was used to `simpleHttp` do do that. However, I would like to infuence the proxy settings, because sometimes I am behind a firewall. Is there a simple way to do this? Thanks! Han. -- View this message in context: http://haskell.1045720.n5.nabble.com/proxy-settings-with-simpleHttp-tp51149… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 1

Experiments in Haskell Packaging
by Chris Dornan 02 Jan '12

02 Jan '12

Hi All, The http://justhub.org Haskell distribution for Enterprize Linux (RHEL/CentOS 5 & 6) is now live. The distribution deviates from current practice. When you upgrade to a new Platform from justhub.org you add the new platform to your Haskell infrastructure rather than replacing the old platform with a new one. Why? **Stability**: Enterprise Linux places a strong emphasis on stability and updating packages should not break things. (This has provided some challenges for us as RHEL 5 is still using GCC 4.1.2 and Binutils 2.17.50.) **Flexibility**: Different projects will in general need to work with different versions of the platform and toolkits and upgrade according to their own schedules. I believe Haskell’s strong-typing sharpens the need for this. Production projects will need to upgrade according to their own schedules while other projects will want to stay up-to-date. In general when you check out a source tree you want to build with the tools and libraries that it has been tested with and move on according to the project’s timetable. **Sandboxes**: The same mechanism for managing the multiple toolkits and platforms can be adapted to provide an integrated sandbox utility. The logic that dictates that projects have different tool-chain requirements applies to the user packages too. (‘Handbox’ doesn’t really work so we use **Hubs** instead.) **Package Deletion**: The infrastructure can also be expanded to complete the package management tools with package removal and garbage collection of library code. **The Catalogue**: All of the GHC releases can be added as they become available. In general the distribution works just like any other – after an upgrade invoking ‘ghc’ without any other configuration will invoke the compiler for that latest platform, which should behave as it would on any other (working) distribution. But after an upgrade: o any projects configured to work with specific tool chains and libraries will continue undisturbed; o you can create a new hub based on the new platform and experiment with it on newly-checked-out source tree without disturbing an existing working tree (or just swap the hub into an existing work tree and back out again if things don’t work out); o even on release of a new version of a package (or if you want to experiment with your existing packages) you can easily duplicate an existing hub and delete, upgrade and add packages on a topic branch. Of course ‘serious developers’ have been doing this with home-brew infrastructure for ever. Nevertheless I have found doing it with well-integrated tools to be quite liberating. It might also help new users to make the transition to serious developers more quickly. Thoughts anyone? Chris

1 0