November 2013 - Haskell-Cafe

Return of the revenge of the revisit of the extensible records, reiterated
by Atze van der Ploeg 06 Dec '13

06 Dec '13

Dear all, Extensible records have been a long outstanding feature request for GHC. Using the new closed type families and type literals, it is actually possible to implement Daan Leijen's "`Extensible Records with Scoped Labels" system as a library. I have implemented this library at https://github.com/atzeus/openrec (the documentation is at http://homepages.cwi.nl/~ploeg/openrecvardocs/) The only thing it requires is the availability of a closed type family that compares two type level symbols (i.e. the ordering on strings): type family (m :: Symbol) <=.? (n :: Symbol) :: Bool patches to GHC that implement this built-in closed type family are also at the github site. I would like to generate some discussion about: * Is this the interface we would like for open records and variants? * Would it be worthwhile to invest in syntactic sugar for open record operations? * Any comments on the interface and or its implementation? Cheers! Atze van der Ploeg

6 20

Re: [Haskell-cafe] free vs. operational vs. free-operational
by oleg＠okmij.org 05 Dec '13

05 Dec '13

Alejandro Serrano Mena wrote: > I really like the separation between providing a data type and then a > interpretation that operational embodies... Then perhaps you may like extensible effects then. They are designed around the separation of requestors and their interpreters. However, the set of requests is open (and can be extended at any time without recompiling the program). Likewise the interpreters can be extended incrementally. One can add an interpreter for an effect without caring what other effects are there -- unless one has some reason for caring about other effects (e.g.,m for finalization). One may then snoop on other effects while interpreting. Moreover, the handlers may be scattered around program; they don't have to be all at the very top. Crucially, unlike data types a la carte, extensible effects provide effect encapsulation: one can not only add effects but subtract them, by completely handling the effects. The type system ensures that all effects must be completely handled at the end.

7 13

Cannot find HS*.o linked object for loading into ghci after last update
by Thiago Padilha 05 Dec '13

05 Dec '13

Hi After last update, cabal-install stopped generating an HSfoo-VERSION.o(assuming the package name is 'foo') in the dist/build directory. How can I force cabal to generate this file again?

2 2

Simple script to make existing GHC or HP installation work with Xcode 5
by Mark Lentczner 05 Dec '13

05 Dec '13

Friends - I've developed a simple shell script that should enable your existing GHC 7. or HP installation work with Xcode 5. https://gist.github.com/mzero/7245290 Place that script somewhere, make it executable, and run it. *Then follow the instructions it tells you!* You will end up having to run it more than once: First time it will tell you where to install a copy of the script Second time it will patch your GHC settings file(s) The script is safe to install and setup before you upgrade to Xcode 5, as it reverts to "getting out of the way" if it detects Xcode 4 based installation. It has been tested on two machines: - OS X 10.8 and Xcode 4 - OS X 10.9 and Xcode 5 If a few more intrepid souls test it and it works, I'll post instructions in more prominent places! I'll be testing OS X 10.9 and Xcode 4, tomorrow, and expect it should work fine on OS X10.8 with Xcode 5. But looking for reports that it all works. - Mark "Mac Packager" Lentczner

3 2

Re: [Haskell-cafe] Writer + log each computation to stdout
by oleg＠okmij.org 04 Dec '13

04 Dec '13

Bryan Vicknair wrote: > I have a bunch of little database IO functions. Each does something to the > database, and returns a log string describing what it did, and possibly a > meaningful result from the database. > ...and a few functions that orchestrate all the little functions into doing > useful work. > > I don't want the individual functions to know what is done with the log string > describing what they did. Top-level orchestrating functions should make that > decision, which can be one of: > > 1) Collect and print all to a log once all computations are done. > 2) Print to stdout *as each computation is run*. > 3) Ignore them. What an excellent case for extensible effects! Many thanks to Ben Foppa for making the package available on hackage, as extensible-effects. Extensible Effects designed specifically to separate a client (the requestor of an action) from a handler, the executor of an action. A logging client merely requests a string to be logged. It has no idea what happens when that request is executed. Therefore, the same client can be used with several handlers, even within the same expression. One can also build various interceptors, such as logIntercept, which is similar to Unix' tee. The following file illustrates how to solve the problem with all three scenarios. http://okmij.org/ftp/ The extensible effects package actually defines a very similar function, calls trace. For illustration and clarity, the file develops the Logging effect from scratch. After all, Extensible Effects encourages developing effects to suit the problem at hand. Defining a new effect is as simple as -- The request to log a string -- The request carries the String to log. It seems no particular -- reply is needed for the request (other than the simple acknowledgment), -- so we set the reply to be unit. data Log v = Log String (() -> v) deriving (Typeable, Functor) Clients use the function logit :: Member Log r => [Char] -> Eff r () (this signature, as all signatures in the code, are inferred). The signature says that the function request Log effect to be done. It does not concern itself how this effect its to be done. The file shows three handlers: runLogCollect, runLogTrace, runLogIgnore. There is also another handler, logIntercept, that like Unix 'tee', prints out the log message immediately while still propagating it. It can be used with any of the three handlers.

2 2

Need help: Cabal rejecting stringsearch, conflict in base
by Thiago Negri 04 Dec '13

04 Dec '13

I don't know what to do. :-( I can't install scotty or yesod. $ cabal install scotty cabal: Could not resolve dependencies: trying: scotty-0.5.0 (user goal) trying: base-4.7.0.0/installed-dc1... (dependency of scotty-0.5.0) trying: wai-extra-1.3.4.6 (dependency of scotty-0.5.0) trying: stringsearch-0.3.6.4 (dependency of wai-extra-1.3.4.6) rejecting: stringsearch-0.3.6.4:-base3 (conflict: base==4.7.0.0/installed-dc1..., stringsearch-0.3.6.4:base3 => base>=2 && <3) rejecting: stringsearch-0.3.6.4:+base3 (conflict: base==4.7.0.0/installed-dc1..., stringsearch-0.3.6.4:base3 => base>=3 && <4) Backjump limit reached (change with --max-backjumps).

6 6

Writer + log each computation to stdout
by Bryan Vicknair 04 Dec '13

04 Dec '13

Hello, I have a bunch of little database IO functions. Each does something to the database, and returns a log string describing what it did, and possibly a meaningful result from the database. query :: IO (String, a) update :: a -> IO (String, ()) ...and a few functions that orchestrate all the little functions into doing useful work. syncWeek :: Week -> IO () syncAll : : IO () I don't want the individual functions to know what is done with the log string describing what they did. Top-level orchestrating functions should make that decision, which can be one of: 1) Collect and print all to a log once all computations are done. 2) Print to stdout *as each computation is run*. 3) Ignore them. Here is my understanding of how common monads would handle these requirements: Writer: 1 and 3 are easy. This is what I originally attempted to use, but I couldn't figure out how to accomplish #2. Reader: 2 and 3 can be accomplished if each function reads a shouldLog config variable from the reader and does a putStrLn depending on the value. Very ugly, as now each function has to know how to log output. State: Not sure, but the Writer docs in the transformers package points to this monad as maybe solving requirement #2 above. The use case is that when I call the top-level functions from a command line script, I want to see logging happening in real-time to stdout, but I may call the same top-level functions from a larger application that may be logging to somewhere other than stdout, and may call the top-level functions from yet another larger application which doesn't want anything to be logged. How can I glue together a bunch of smaller computations, which may call each other, and decide at a higher level what to do with the logging result of each computation? Seems like a perfect fit for Writer, except for the requirement to be able to print to stdout at each step. Bryan Vicknair

5 4

The rmonad package is mysterious
by Simon Marechal 03 Dec '13

03 Dec '13

I tried to do something simple using the rmonad package (attached). I followed the example that's in haddocks (it is wrong, constraints has no arguments), grabbed the list of extensions from rmonad's source, but this program doesn't typecheck: Could not deduce (Hashable a) arising from a use of `HM.singleton' This seems to be an obvious use of this package ... am I missing something ?

2 1

free vs. operational vs. free-operational
by Alejandro Serrano Mena 01 Dec '13

01 Dec '13

Dear Café, I've been reading lately about the relation between the 'free' package and the 'operational' package for rolling your own monads [1] [2]. Furthermore, I've discovered that the 'free-operational' package, which is some sort of bridge between the two worlds, and provides not only Monad but also Applicative and Alternative instances for ProgramT. The problem is that right now everything is a little confused in my head. In particular, I have the following questions: - I've read that free allows you to 'bake algebraic laws' in the resulting monad. How does this work? Why doesn't operational offer that feature? - One of the things I really like from the free package is that it provides support for many monad transformer stacks, whereas operational does not? Is there any special restriction why operational cannot do this? Would it be possible to provide similar instances for free-operational? - It seems that free gives more features (Alternative, Applicative) with the same work. In which situations should I prefer operational to free? I really like the separation between providing a data type and then a interpretation that operational embodies... - Should I replace my usage of operational with free-operational altogether? Thanks for the help :) [1] http://www.reddit.com/r/haskell/comments/17a33g/free_functors_the_reason_fr… [2] http://stackoverflow.com/questions/14263363/is-operational-really-isomorphi…

3 5

[ANN] XSLT2 for C/C++: alpha realease of Saxon-HE 9.5 (and soon Xpath2, Xquery)
by Olivier JEULIN 29 Nov '13

29 Nov '13

Hello, for those working with XML and XSLT/XQuery/XPath, you may be interested to know that Saxonica is releasing an alpha version of its free (and open source) XSLT2/Xquery engine Saxon-HE 9.5. (I'm not affiliated with Saxon, I'm just spreading the news :-) ) The good news is: this finally brings XSLT 2 to C/C++, instead of XSLT 1 (which is already supported by libxml2). XSLT 2 is a MUCH more mature version of XSLT, with cleaner definition of function and a nice functional approach. XSLT 3 will be even better (higher order functions) but may not be supported by the free version of Saxon. http://www.saxonica.com/saxon-c/index.xml I hope that someone will make a binding for haskell ^^,

3 2