March 2011 - Haskell-Cafe

Regarding two platforms build error.
by Serguey Zefirov 30 Mar '11

30 Mar '11

Haskell Platform 2010.1 with ghc 6.12.1 worked quite well. Problem solved. ;)

1 0

Dynamically linked executables
by Anakim Border 30 Mar '11

30 Mar '11

Hi, I'm trying to understand if it's possible to build dynamically linked executables under Mac OS X (10.6) with GHC 7. Looking here: http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/PlatformSupport it seems like the support is already present. Inside ghc-7.1.20110325 sources (the latest development snapshots as I write), I find the following: # Do we support shared libs? PlatformSupportsSharedLibs = $(if $(filter $(TARGETPLATFORM),\ i386-unknown-linux x86_64-unknown-linux \ i386-unknown-freebsd x86_64-unknown-freebsd \ i386-unknown-openbsd x86_64-unknown-openbsd \ i386-unknown-mingw32 \ i386-unknown-solaris2 \ i386-apple-darwin powerpc-apple-darwin),YES,NO) which seems to indicate the contrary. GHC bug tracker, finally, doesn't show any open ticket on the matter. Anyone has more details about this? Thanks, AB

2 1

Two Haskell Platforms on single machine.
by Serguey Zefirov 30 Mar '11

30 Mar '11

I had to use two Haskell Platforms at once in the Windows environment. We use Haskell Platform 2011.1 as our main build platform. It provide real benefits for code with GADTs so we ported most of our code there. Right now we cannot switch back or it would be quite a regress. We also have some heavy type level computation code in one of our programs so we have to use Haskell Platform 2010.2 with ghc 6.12.3 as 7.0.2 is quite slow at that. And now I have some strange error (it didn't appear when I used only one of Haskell platforms): ---------------------------------- ghc-6.12.3 -O2 -odir objs -hidir objs -stubdir objs -o CGen.exe -fcontext-stack=100 --make CGen.hs Linking CGen.exe ... realgcc.exe: USERNA: Invalid argument C:\PROGRA~1\HASKEL~1\201020~1.0\lib\..\mingw\bin\windres: "C:\PROGRA~1\HASKEL~1\ 201020~1.0\lib\..\mingw\bin\gcc exited with status 1 ---------------------------------- When I looked at the dump in hex, I encountered that "USERNA" string contains "USERNAM^H" byte sequence, actually. I cannot look at ghc -v5 as I get another error: ---------------------------------- Glasgow Haskell Compiler, Version 6.12.3, for Haskell 98, stage 2 booted by GHC version 6.10.4 Using binary package database: C:\PROGRA~1\HASKEL~1\201020~1.0\lib\package.conf.d\package.cache ... ... (I deleted much of the lines) ... Deleting: *** Deleting temp dirs: Deleting: <stderr>: hPutChar: invalid argument (character is not in the code page) ---------------------------------- I use localized version of Windows XP so it appears that ghc cannot print some name with russian characters in it. And here I stuck. I cannot find source of one error because of another error. Could anyone help me?

1 0

Re: [Haskell-cafe] object oriented technique
by Tad Doxsee 30 Mar '11

30 Mar '11

Greg, Thanks for your help. Is there any significant difference between using existential quantification data ShapeD = forall s. ShapeC => ShapeD s versus a GADT data ShapeD where ShapeD :: ShapeC s => s -> ShapeD I'm not sure I understood what you meant by "You don't need to write more typeclass instances this way." Thanks for pointing out the Control.Exception library. It was very helpful. Earlier, I was trying to figure out how to use Data.Dynamic for down-casting and couldn't get what I wanted. The Data.Typeable usage in Control.Exception is what I was looking for. Tad On Tue, Mar 29, 2011 at 12:57 AM, Gregory Collins <greg(a)gregorycollins.net> wrote: > On Tue, Mar 29, 2011 at 7:49 AM, Tad Doxsee <tad.doxsee(a)gmail.com> wrote: >> class ShapeC s where >> draw :: s -> String >> copyTo :: s -> Double -> Double -> s >> >> -- needs {-# LANGUAGE GADTs #-} >> data ShapeD where >> ShapeD :: ShapeC s => s -> ShapeD >> >> Is the above the standard method in Haskell for creating an extensible >> heterogeneous list of "objects" that share a common interface? Are there better >> approaches? (I ran into a possible limitation to this approach that I plan >> to ask about later if I can't figure it out myself.) > > The usual way to do this is: > > {-# LANGUAGE ExistentialQuantification #-} > data SomeShape = forall s . ShapeClass s => SomeShape s > > You don't need to write more typeclass instances this way. If you give > "SomeShape" a "ShapeClass" instance also, you can treat them > uniformly. The downside to these approaches is that any additional > information about the original concrete type is obliterated -- to get > OO-style downcasting you need "Typeable" support, and it isn't free. > > For an example of code which uses this idiom, see the exceptions > support from the base library: > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exceptio… > > G > -- > Gregory Collins <greg(a)gregorycollins.net> >

3 2

Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
by oleg＠okmij.org 29 Mar '11

29 Mar '11

Wren Thornton wrote: > This is often conflated with the iteratee throwing an error/exception, > which is wrong because we should distinguish between bad program > states and argument passing. I guess this is a matter of different points of view on exceptions. I am a fan of the model of (effectful) computation proposed by Cartwright and Felleisen a while ago: http://okmij.org/ftp/Computation/monads.html#ExtensibleDS In their model, all the computation is done by throwing resumable exceptions -- including the pure computation such as arithmetic and CBV/CBN applications. The similarity of ExtensibleDS.hs with Iteratee should be quite noticeable, especially regarding the part about throwing `errors.' The relation with co-routines is hard to miss: in fact, Iteratees are built upon co-routines, which are being resumed by the enumerator. The error message is the additional piece of data that is being associated with `yield', telling the enumerator to do something extra rather than mere getting the next piece of data and resuming the co-routine. The co-routine is the simplest part of the iteratee; it is the plumbing that takes a long time to engineer. John A. De Goes: > 2. Error recovery is ill-defined because errors do not describe > what portion of the input they have already consumed; I'm confused about this complaint: if an iteratee encounters an unusual condition or just has a special request, it sends a message that eventually propagates to the responsible enumerator. That enumerator knows how much data it has sent down to iteratees. The RandomIO module http://okmij.org/ftp/Haskell/Iteratee/RandomIO.hs is a good illustration: when the enumerator receives the seek request, it checks if the desired stream offset corresponds to the data already in the current IO buffer. If so, no IO is performed and the iteratee is resumed with the existing buffer data. The tests in the file check for that. Iteratee knows nothing about the buffer or if there is a buffer. Wren Thornton wrote: > In an ideal framework the producers, transformers, and consumers of > stream data would have a type parameter indicating the up-stream > communication they support or require (in addition to the type > parameters for stream type, result type, and side-effect type). Very true. Currently the design of Iteratees quite resembles that of Control.Exception: everything can throw SomeException. Ideally one would like to be more precise, and specify what exceptions or sorts of exceptions could be thrown -- by Iteratees, and by ordinary Haskell functions. The design of a good effect system is still the topic of active research, although there are some encouraging results. John A. De Goes: > 3. Iteratees sometimes need to manage resources, but they're not > designed to do so which leads to hideous workarounds; Gregory Collins: > The thing which I find is missing the most from enumerator as it > stands is not this -- it's the fact that Iteratees sometimes need to > allocate resources which need explicit manual deallocation (i.e. > sockets, file descriptors, mmaps, etc), but because Enumerators are > running the show, there is no "local" way to ensure that the > cleanup/bracket routines get run on error. I used to think that processing several inputs at different paces was indeed a stumbling block. It seemed that an iteratee needed to open a separate file, which it is indeed ill-equipped to do. Fortunately, that difficulty has been overcome, surprisingly in a natural way with no changes to the library: http://okmij.org/ftp/Streams.html#2enum1iter The pleasant surprise is that we can iterate (no pun intended) Iteratee monad transformers, just as we did with (IORT s) monad transformer in the Lightweight Monadic Regions. Thus we maintain the region-like discipline of managing resources. I'm keen to hear of the example that seem to require Iteratee's allocating additional resources. I'd really like to see if any of such cases can be cast it terms of regions, implemented via iterated Iteratee transformers. John A. De Goes: > 1. It does not make sense in general to bind with an iteratee that > has already consumed input, but there's no type-level difference > between a "virgin" iteratee and one that has already consumed input; I'm not sure I follow. Why should it make a difference between a virgin iteratee and the one that consumed some input. One should think of the Iteratee as two arguments of fold (f and z) bundled together. Why the function being folded over should care how many times it has been applied to input data? It is a pure function, transforming state plus input to a new state. The useful laws of fold hold precisely because the function f is pure and doesn't care. A detailed example showing why you think you need this distinction would be appreciated. > 4. Iteratees cannot incrementally produce output, it's all or > nothing, which makes them terrible for many real world problems > that require both incremental input and incremental output. Again, a detailed example, a use case if you will, describing the desired behavior is appreciated. By detailed I mean the example that describes the desired input-output behavior, preferably including sample input or output data. For instance, the question posed by Evgeniy Permjacov last December was precise and helpful: (incrementally) merge two sorted streams. I can't promise a prompt reply this month or in April, I'm afraid.

2 1

ANNOUNCE: enumerator 0.4.8
by John Millikin 29 Mar '11

29 Mar '11

----------------------------------------------------------------------------------------------------------------------------------------------------- Enumerators are an efficient, predictable, and safe alternative to lazy I/O. Discovered by Oleg Kiselyov, they allow large datasets to be processed in near–constant space by pure code. Although somewhat more complex to write, using enumerators instead of lazy I/O produces more correct programs. http://hackage.haskell.org/package/enumerator http://john-millikin.com/software/enumerator/ ----------------------------------------------------------------------------------------------------------------------------------------------------- Hello -cafe, It's been a while since the last point release of enumerator. This one is sufficiently large that I think folks might want to know about it, and since I try not to spam too many announcements, I'll give a quick rundown on major changes in other 0.4.x versions as well. First, most of what I call "list analogues" -- enumerator-based versions of 'head', 'take', 'map', etc -- have been separated into three modules (Data.Enumerator.List, .Binary, and .Text) depending on what sorts of data they operate on. This separation has been an ongoing process throughout 0.4.x releases, and I think it's now complete. The old names in Data.Enumerator will continue to exist in 0.4.x versions, but will be removed in 0.5. Second, Gregory Collins and Ertugrul Soeylemez found a space leak in Iteratee's (>>=), which could cause eventual space exhaustion in some circumstances. If you use enumerators to process very large or infinite streams, you probably want to upgrade to version 0.4.7 or higher. Third, the source code PDF has seen some substantial improvement -- if you're interested in how the library is implemented, or have insomnia, read it at < http://john-millikin.com/software/enumerator/enumerator_0.4.8.pdf > Finally, there is a known issue in the current encoding of iteratees -- if an iteratee yields extra data but never consumed anything, that iteratee will violate the monad law of associativity. Oleg has updated his implementations to fix this problem, but since it would break a *lot* of dependent libraries, I'm holding off until the vague future of version 0.5. Since iteratees that yield extra data they didn't consume are invalid anyway, I hope this problem will not cause too much inconvenience. New features ----------------- * Range-limited binary file enumeration (requested + initial patch by Bardur Arantsson). * splitWhen , based on the "split" package < http://hackage.haskell.org/package/split > * 0.4.6: Typeable instances for most types (requested by Michael Snoyman) * 0.4.5: joinE , which simplifies enumerator/enumeratee composition (requested by Michael Snoyman)

11 30

SoC / Cabal project proposal: specify Setup.hs dependencies
by Rogan Creswick 29 Mar '11

29 Mar '11

I've been wanting to share code between cabal projects for some time, and I finally had a chance to write up the rough idea as a simple proposal. Here's the description, with links to the SoC trac and reddit haskell_proposals pages. SoC ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 Reddit: http://www.reddit.com/r/haskell_proposals/comments/ge1zp/cabal_dependency_s… Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult. A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal. Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools. I'm interested in thoughts / feedback about the idea, as well as hearing from anyone interested in pursuing this as a summer of code project :) Thanks! --Rogan

3 2

Summer of Code Mentors for Language.C
by Andrew Hirsch 29 Mar '11

29 Mar '11

Would anybody be interested in mentoring me for a summer of code project working on language.c? I want to write an internal pre-processor that saves information such as comments and potentially some specially defined annotations, so that code can be analyzed better.

3 2

hdbc-odbc adds a space to the value
by vagif.verdi＠gmail.com 29 Mar '11

29 Mar '11

I have a weird problem ? When preparing sql statements with ? placeholders, hdbc-odbc adds a space to a string value at the end. run conn "update sometable set somefield = ? where id = ?" [SqlString "bla", toSql 10] Database: Ms Sql Server 2005. Driver: FreeTds on linux Please help! Regards, Vagif Verdi

3 5

Please allow variation in the Yackage page title
by Yitzchak Gale 29 Mar '11

29 Mar '11

Could you please add a way of varying the title of the Yackage web page? That would make it much easier to work with multiple Yackages at once. For my particular setup, including its port number in the web page title would do the trick. But perhaps the easiest and most general thing would be to add a command-line option for setting the title. Using multiple Yackages is a very simple yet powerful technique to keep cabal versions straight. You can use it to group package versions in various ways - versions that you are currently hacking on, versions that have stabilized but you are not releasing yet while you work on other related packages, versions shared by various teams and subteams of developers, etc. Multiple Yackages are especially useful in combination with cabal-dev, but currently you have to fiddle a little bit to get cabal-dev to use a modified cabal config file. See: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090492.html Thanks, Yitz

2 1