- Haskell-Cafe - Haskell.org

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 30 Mar '11

30 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 30 Mar '11

30 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

WANTED: Compensated Haskell Hacker for Language Project
by Bryan Edds 29 Mar '11

29 Mar '11

Hello fellow Haskellers! I have a language I would like to prototype in Haskell. It's a 'language-oriented' programming language based on Lisp, ML, and Python. It's a relatively small language, but should be powerful enough to have many of its features implemented in terms of itself (classes, actors, almost all syntax, etc.) While the project is compensated, I'm just a commercial game programmer by day and don't have a corporate budget, so part of the motivation is the joy of the project itself. Otherwise, I have a budget of $4k - $6k USD over the next several months to compensate someone to hack it up for me. I don't have much in the way of specs, and the design is ongoing (almost certainly some holes), but there is an overview of the design here - http://channel9.msdn.com/Forums/Coffeehouse/Prototyping-New-Language-With-H… I really want to churn it out as a nice working concept to prove the language design and language oriented programming is practical even for soft-real time software like console games. The project will be open source throughout its development and the language will be free to use. I really want it to take off, despite my meager resources :) Beyond that, I'm looking for charitable investors once the prototype is finished and proven. I want to find other people are so sick of writing soft-real time software in C-family languages at their work place that it's worth the donation. Perhaps there is some company who might be interested in further incubating the project if it proves commercially interesting :) I do ask for the code to be reasonably clean as I would like to be able to help once I get some time. I would be implementing the thing fully myself, but I am way too swamped at work :) Since I have to rest my hands during my off hours, I would like to do most communication by voice. Feel free to record any of the communication if you like. If anyone is interested and has the credentials to bring the project to fruition, please contact me at bryanedds(a)yahoo.com straight away. Thanks!

3 3

How to best deal with nullPtr from alloca and friends?
by Jason Dagit 29 Mar '11

29 Mar '11

I was reading up on the documentation for alloca and friends[1], which says, "If any of the allocation functions fails, a value of nullPtr<http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/Foreign-P…> is produced." It seems like every example of FFI code that I find which uses alloca ignores the possibility of a nullPtr[2, 3, 4]. So then I started trying out examples with the help of dmwit and others from #haskell. It seems that actually, alloca and friends throw exceptions: dmwit> main = allocaArray (2^30) (\ptr -> print ((nullPtr :: Ptr Double) == ptr)) <dmwit> lispy: alloca also throws an exception. <dmwit> lispy: Or rather, allocaBytes throws an exception, and alloca is implemented in terms of allocaBytes, so I'm *guessing* that alloca throws an exception. I'm on a 64bit version of windows here with more than 4GB of memory to spare for the GHC process. Unfortunately, allocaBytes takes an Int so I can't test it with a request larger than the amount of physical ram I have. Just playing around with different arguments to allocaBytes I can get different behavior: <= 2^30 bytes, works perfectly == 2^30 + 2^20 bytes, I get an "<interactive>: out of memory" message and ghci terminates == 2^31-1, I get a crash where windows pops up a little dialog saying my program (ghci) has crashed. The behavior seems to be inconsistent with the documentation. What is the correct behavior for alloca and friends and should I be checking for nullPtr? Thanks, Jason [1] http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/Foreign-M… [2] http://en.wikibooks.org/wiki/Haskell/FFI [3] http://www.haskell.org/haskellwiki/HSFFIG/Examples [4] http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html

2 3