December 2009 - Haskell-Cafe

"Rebox Package" or "To Hackage or not to Hackage"
by John Van Enk 08 Dec '09

08 Dec '09

Hi List, I've recently had a situation where I used the same pattern quite a bit while reducing and evaluating an AST. I quickly wrapped the operation in a package and stuck it on github. http://github.com/sw17ch/rebox/blob/master/src/Data/Rebox.hs I'm wondering two things: 1) Does any one recognize the pattern I'm using here as something with a different name? 2) Is this worth sticking on Hackage? It's trivial, but we have plenty of trivial concepts on Hackage (and it's not a bad thing). Any feedback would be great. /jve

4 3

Re: [Haskell-cafe] Interactive chatbot
by Ben Millwood 08 Dec '09

08 Dec '09

Oops, I clicked "reply" instead of "reply to all". Duplicating the message below. I suppose this means someone is going to get two copies of this. Sorry someone! On Thu, Nov 5, 2009 at 12:56 AM, Ben Millwood <haskell(a)benmachine.co.uk> wrote: > On Wed, Nov 4, 2009 at 10:21 PM, Torsten Otto <t-otto-news(a)gmx.de> wrote: >> >> When we read the user's input through >>> t <- getLine >> it is not possible to delete typos before hitting enter and thereby sending >> the input off to the system (at least in OS X, bash). I didn't find that >> terribly problematic, but of course it is a bit of a show stopper from their >> point of view. >> > > As people have said it's worth checking what buffering settings you > are using (especially note that ghci changes some interesting settings > in relation to how input is handled, and compiled code may behave > differently), but it might also be worth checking the terminal > application's preferences to see if there are settings related to the > interpretation of the backspace key that you need to twiddle one way > or the other. In particular, if you are finding that pressing delete > makes ^H appear on the input line instead of deleting things, or if > pressing ctrl-H deletes stuff where the delete key fails to do so, it > might be a problem with your terminal rather than with your program. > This is only based on what I vaguely remember from faffing with the > Mac Terminal application some time ago when it wouldn't co-operate > with screen, but it may be worth a look. > > yours, > Ben Millwood >

2 1

The Transient monad
by Alberto G. Corona 08 Dec '09

08 Dec '09

Hi haskell cafe: concerning Stable Names http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-Stabl… makeStableName :: a -> IO (StableName a) I Did not test fully my proposal, and I´m thinking aloud, Just to inpire others and fish some ideas; The IO in makeStableName suggest more side effects than makeStableName really do. But still the call isn't pure. For calls such are makeStableName that gives a different result the FIRST time they are called but return the same result every time in the same session, I suggest to use a Transient monad: makeStableName :: a -> Transient (StableName a) The key here is to maintain the programmer aware that it is not pure, but there are no IO and that the results have no meaning from session to session. Instance Monad Transient where Transient x ↠ f = f x return x = Transient x We can Transient`ize IO calls by means of an implicit memoization: liftT:: IO a -> Transient a liftT= < whatever memoization code> liftT2=.... liftT3=.... Memorization then is embedded in the monad transformation This may be more elegant than IO plus unsafePerformIO and is more informative for the programmer. The transition form IO to pure can be done in two steps, see below Instead of unsafePerformIO, we can use: unsafePurifyTransient :: Transient a -> a unsafePurifyTransient (Transient x) = x for the inherently transient calls A safer version of unsafePerformIO using implicit memoization could be: unsafePerformIOT :: IO a -> a unsafePerformIOT = unsafePurifyTransient . liftT unsafePerformIOT guatantee that it returns the same value in the same session. 2009/12/8 Vladimir Zlatanov <vlado(a)dikini.net> > <jeanchristophe.mincke(a)gmail.com> wrote: > > I think lisp like symbols could be quite useful in the context of > embedded > > DSL to create ... well... symbols that can be interpreted as variables in > > that DSL. > > Well for such use-case you could use either stable names, or recode > them into a state monad- you will get either a global i.e. lisp like > unique symbols, or their equivalent within a state context. Or some > variation of the code posted previously in this thread. > > > http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-Stabl… > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

3 2

Lisp like symbols in haskell
by jean-christophe mincke 08 Dec '09

08 Dec '09

Hello, Has there already been attempts to introduce lisp like symbols in haskell? Thank you Regards J-C

12 13

ANNOUNCE: new installment of failure framework
by Michael Snoyman 08 Dec '09

08 Dec '09

We'd like to announce the next installment of the Failure Framework. Based on feedback, our main goals in this release is to reduce the number of external dependencies and avoid complications with monad transformer libraries at the core of the framework. We have made the following changes: * Failure is not tied directly to monads anymore. The main typeclass is Failure, which provides the failure function. MonadFailure, ApplicativeFailure and FunctorFailure are provided for convenience. * The Failure typeclass is now located in the failure package, which has no dependencies. All code dealing with transformers and mtl has been factored into control-monad-failure and control-monad-failure-mtl, respectively. In addition, we are simultaneously releasing the following packages: * safe-failure provides safe versions of dangerous, non total functions, such as head, by returning failures. It depends exclusively on failure. * attempt provides a concrete data type for handling extensible exceptions as failures. It depends exclusively on failure. * control-monad-attempt provides a monad transformer for attempt using the transformers library. We do not provide currently an mtl version of this package, but can provide one if there is demand. * control-monad-exception, explicitly typed, checked exceptions with monadic stack traces. Below are the links to the packages just released. Enjoy! http://hackage.haskell.org/package/failure-0.0.0 http://hackage.haskell.org/package/control-monad-failure-0.6.0 http://hackage.haskell.org/package/control-monad-failure-mtl-0.6.0 http://hackage.haskell.org/package/safe-failure-0.4.0 http://hackage.haskell.org/package/attempt-0.2.0 http://hackage.haskell.org/package/control-monad-attempt-0.0.0 http://hackage.haskell.org/package/control-monad-exception-0.8.0 http://hackage.haskell.org/package/control-monad-exception-mtl-0.8.0 http://hackage.haskell.org/package/control-monad-exception-monadsfd-0.8.0 http://hackage.haskell.org/package/control-monad-exception-monadstf-0.8.0 Michael Snoyman, Pepe Iborra, Nicolas Pouillard

3 3

Re: binding to C libraries on Windoww
by John Lato 08 Dec '09

08 Dec '09

> From: Andrew Coppin <andrewcoppin(a)btinternet.com> > > John Lato wrote: > >> The only workable approach is to have users specify the >> locations of these files, which unfortunately requires more >> sophistication than can be expected of most Windows users (and even >> some Windows developers). >> > > Well, I don't know. It's going to vary from package to package, but most > things that have a semi-official Windows version either come as a > Windows Installer package (which, one presumes records where it put > everything *somewhere* in the Windows registry), or possibly the > *developer* package comes as a simple Zip file that you just unzip to > wherever you fancy. Just tell the user the URL to grab the Zip file > from, unzip it and tell Cabal where the root is now. Shouldn't be too > hard. (Famous last words...) Indeed, in theory it would work this way. In practice, not so much. > >> On a related matter, many packagers resort to using configure-style >> configuration setups to assist with binding to C libraries. Cabal is >> now sophisticated enough to handle many of these steps (although not >> all), however packagers may not have had an opportunity to update >> their build process to remove the dependency on "configure". These >> packages will continue to require cygwin or mingw for the "configure" >> step. >> > > Ah yes, this is pretty much guaranteed to make stuff not work on > Windows. :-) Still, all Unix systems have Automake, configure, etc., so > I guess most people don't even think twice before using it. > > I gather it's supposed to be Cabal's job to figure this stuff out in > Haskell land? > AFAIK, this is true to an extent. I think that someone like Duncan could explain the role of Cabal better than I can. Of course Cabal was missing much of the necessary functionality until only recently. As an example, the possibility of listing C library dependencies was only added in 1.6 IIRC. >> One last wrinkle: many distributors of C libraries do not have Windows >> machines available to test, and (understandably) have little interest >> in supporting a platform they don't have and aren't familiar with. As >> a result, many C libraries are not well supported on Windows and >> require somebody familiar with gnu build tools (i.e. gcc, make, and >> autoconf) to be usable on Windows *at all*. This means that, as a >> Haskell developer wanting to use these libs, you need to use gnu build >> tools because you're not just binding to the library, you're >> maintaining a Windows port of it. >> > > This seems to be kind of the catch-22. Nobody uses Windows, so there > isn't much support for Windows, so we don't attract many Windows > users... QED. :-} > Agreed (by users I presume you mean Haskell developers). I remember that many readers of this list were shocked by the download numbers for the HP, particularly the high number of Windows downloads. I think it goes to show that there is interest among Windows developers, as long as they have the sense that their platform is equally-supported compared to Linux. There are many more potential windows developers than linux developers due to the size of the Windows install base, so good Windows support is one of the easiest ways to expand the audience. >> C and unix are pretty much designed to work together, and have been >> for decades, so I think it's reasonable to expect that Windows is the >> side that needs to adapt to support their model. > > In other words, "Windows needs to become just like Unix". Not going to > happen. ;-) Argue about whether this is good or bad amoungst yourselves. > But it's not happening. I don't mean that Windows needs to become just like Unix. I mean that if Windows supported a common installation location for .dll's and .h files (and binary packages regularly provided them), much of this difficulty would be easily resolved. It wouldn't be "becoming like Unix", it would mean adopting to a C distribution model that Unix happens to share. Regardless, I think I have a better chance of winning the lottery jackpot than seeing MS support this in my lifetime. > >> MS hasn't done so, >> which means that C developers would need to unacceptably compromise >> unix support in their packages in order to better support Windows. >> > > I don't know about that... Lots of commercial and open-source products > are available for Windows and Unix, seemingly without any problem. (GTK, > for example...) I don't deny that adding Windows support is _a lot more > work_ than adding support for just another Unix, though. > This goes back to the catch-22 you listed above, but I wouldn't say Windows support is "without any problem." First you need active Windows developers for this. Commercial products have a big advantage here. Second, Windows support means a host of platform-specific bugs to be dealt with in every part of the package. These are in addition to any other bugs that you'd have anyway. FWIW, I had great difficulty in building hCsound on Windows, and my primary development box at the time was WinXP. I did eventually make it work with the binary csound distribution, but not without a lot of pain derived from the specifics of the binaries in ways that cabal can't (and probably shouldn't) be expected to handle. John

1 0

Re: New Hackage category: Error Handling
by Henning Thielemann 08 Dec '09

08 Dec '09

On Mon, 7 Dec 2009, Michael Snoyman wrote: > I actually *did* read your article, and don't know what you are referring to. If this is true, sorry, I didn't had the impression. I also think that in an earlier mail I answered, that errors can leave you with corrupt data, say invalid file handles, memory pointers, or data structures that violate invariants. You won't like to close files from invalid file handles and free memory from corrupt pointers or run into infinite loops by traversing the corrupt data structures. That's the reason why it is better to stop execution of the program and hand over control to the next higher level, say the shell or the web browser, that can free resources safely.

3 5

Lots of Haskell at PEPM 2010 - Call for Participation
by Janis Voigtländer 08 Dec '09

08 Dec '09

Hi all, If you are planning to go to Madrid in January, for POPL, don't forget registering for PEPM as well! If you haven't yet been planning to go, maybe you want to reconsider, for PEPM if not for POPL. Why, you ask? Well, the PEPM program has *lots* of Haskell this year. Indeed, no fewer than 10 of the 21 presentations are directly related to Haskell. And the other papers are great, too, and many of them will be interesting to Haskell folk as well. Scan the speakers and titles below, and you will know why I think you won't want to miss out on that one. Best regards, Janis. =============================================================== CALL FOR PARTICIPATION ACM SIGPLAN 2010 Workshop on Partial Evaluation and Program Manipulation (PEPM'10) Madrid, January 18-19, 2010 (Affiliated with POPL'10) http://www.program-transformation.org/PEPM10 =============================================================== Abstracts of all papers and presentations are available from the above web site. INVITED TALKS: * Lennart Augustsson (Standard Chartered Bank, UK) Title: O, Partial Evaluator, Where Art Thou? * Jeremy Siek (University of Colorado at Boulder, USA) Title: General Purpose Languages Should be Metalanguages. CONTRIBUTED TALKS: * Nabil el Boustani and Jurriaan Hage. Corrective Hints for Type Incorrect Generic Java Programs. * Johannes Rudolph and Peter Thiemann. Mnemonics: Type-safe Bytecode Generation at Run Time. * Elvira Albert, Miguel Gomez-Zamalloa and German Puebla. PET: A Partial Evaluation-based Test Case Generation Tool for Java Bytecode. * Martin Hofmann. Igor2 - an Analytical Inductive Functional Programming System. * José Pedro Magalhães, Stefan Holdermans, Johan Jeuring and Andres Löh. Optimizing Generics Is Easy! * Michele Baggi, María Alpuente, Demis Ballis and Moreno Falaschi. A Fold/Unfold Transformation Framework for Rewrite Theories extended to CCT. * Hugh Anderson and Siau-Cheng KHOO. Regular Approximation and Bounded Domains for Size-Change Termination. * Évelyne Contejean, Pierre Courtieu, Julien Forest, Andrei Paskevich, Olivier Pons and Xavier Urbain. A3PAT, an Approach for Certified Automated Termination Proofs. * Fritz Henglein. Optimizing Relational Algebra Operations Using Generic Equivalence Discriminators and Lazy Products. * Adrian Riesco and Juan Rodriguez-Hortala. Programming with Singular and Plural Non-deterministic Functions. * Martin Hofmann and Emanuel Kitzelmann. I/O Guided Detection of List Catamorphisms. * Andrew Moss and Dan Page. Bridging the Gap Between Symbolic and Efficient AES Implementations. * Christopher Brown and Simon Thompson. Clone Detection and Elimination for Haskell. * Stefan Holdermans and Jurriaan Hage. Making Stricterness More Relevant. * Arun Lakhotia, Davidson Boccardo, Anshuman Singh and Aleardo Manacero Júnior. Context-Sensitive Analysis of Obfuscated x86 Executables. * Xin Li and Mizuhito Ogawa. Conditional Weighted Pushdown Systems and Applications. * Ivan Lazar Miljenovic. The SourceGraph Program. * Florian Haftmann. From Higher-Order Logic to Haskell: There and Back Again. SPECIAL FEATURE: * Andy Gill, Garrin Kimmell and Kevin Matlage. Capturing Functions and Catching Satellites. IMPORTANT DATES: * Early registration deadline: December 22, 2009 * Hotel registration deadline: December 28, 2009

1 0

How to deal with C buf in Haskell?
by Magicloud Magiclouds 08 Dec '09

08 Dec '09

Hi, I am warping some C libs. In one function, I do this: 183 allocaBytes bufLen $ \buf -> do 184 ret <- {# call buf_read #} 185 bluh 186 bala 187 buf 188 bufLen 189 if ret < 0 190 then userError "bufRead error" 191 else -- what should I do here? I am thinking about bytestring, to pass the content of the buf to the outside of the function. But I am not sure. What should I do? -- 竹密岂妨流水过山高哪阻野云飞

2 1

New Hackage category: Error Handling
by Gregory Crosswhite 08 Dec '09

08 Dec '09

Hey everyone, When I uploaded my new package, "error-message", I also went ahead and created a new category: "Error Handling". I did this because there are a number of packages related to this issue, so it might be helpful to have them presented together in one place. Thus, if you have or are in the process of writing a package related to this, please consider adding it to this category sometime so that my package doesn't get lonely. :-) Cheers, Greg

8 27