July 2009 - Haskell-Cafe

ICFP contest write-up
by Rafael Gustavo da Cunha Pereira Pinto 20 Jul '09

20 Jul '09

For all Portuguese reading haskellers, I am describing my ICFP 2009 contest write-up on my blog. Feel free to comment. http://rafaelgcpp.blogspot.com/search/label/ICFP2009 For the non-Portuguese readers, Google translation tools do a lousy job, but it is still readable. Regards Rafael Gustavo da Cunha Pereira Pinto

1 0

ANN: cautious-file 0.1.1: Ways to write a file cautiously, to avoid data loss
by Robin Green 20 Jul '09

20 Jul '09

I'm pleased to announce the first public release of cautious-file: http://hackage.haskell.org/package/cautious-file This library currently provides a writeFile function that is intended to have three advantages over Prelude.writeFile: 1. There was a controversy a few months ago about the new Linux filesystem ext4, and how existing applications which write certain files naively might expose their users to the risk of data loss after a crash or power failure. (Actually, it turns out that this is not a new issue - certain other filesystems or filesystem mount options can cause similar issues, but few people made a fuss about it.) cautious-file uses the recommended way of writing a file on POSIX (more or less). On non-POSIX systems (i.e. Windows), it tries to do something sensible, but it may not be the best way to do it, and I've only ran the tests on Linux. 2. With almost any filesystem or operating system, saving a file by overwriting it exposes the user to the risk of data loss if there is a crash or power failure. cautious-file creates a temporary file first and only overwrites the file when it has finished writing (on POSIX systems with sane filesystems, at least). 3. Prelude.writeFile is supposed to lock files so that they at least cannot be written to simultaneously in multiple threads. This is good for safety, but might lead to avoidable problems with IO exceptions when one thread tries to open a file for writing which is still being written to by another thread. Again, the use of a randomly-named temporary file avoids this problem (not with certainty, but with a high probability, which is good enough for some applications). It does not prevent all file-related race conditions (nothing with its type signature could!), but if you are sure you don't care which thread wins, you should be able to use cautious-file's writeFile. A variant, writeFileWithBackup, also allows you to supply a custom backup computation to backup old copy(ies) of the destination file (which is not necessary with Prelude.writeFile, because you can just do it before you call Prelude.writeFile, but is necessary with cautious-file). cautious-file is obviously not appropriate for all circumstances - for instance, it's not needed for writing truly temporary files. But of course if it's close to what you need, you can adapt it (and send me a patch if you like). There is a test runner that can be run by running "runhaskell Setup.lhs test" or "cabal test" in a built copy of the source distribution. The tests do not actually verify that data loss doesn't happen if there's a crash! Indeed, attention should be drawn to the standard BSD license - despite the name "cautious-file", there is no warranty. If in doubt, I suggest you take a close look at the source code - it's very short. I'd appreciate comments, patches, pointers to Haskell code that does the same thing already, etc. Thanks, -- Robin

2 2

was: Debugging methods for haskell structured data types the right way in haskell
by Fernan Bolando 20 Jul '09

20 Jul '09

On Sun, Jul 19, 2009 at 7:40 AM, wren ng thornton<wren(a)freegeek.org> wrote: > Fernan Bolando wrote: >> >> The intention is z0 is a system parameter and database, it contains a >> set of info needed to define a particular simulation >> >> it looks like ( [n,m...], [m,o,p]) >> >> n is is a list info settings for the circuit analysis >> m is a list of statistics for the circuits that is need in sub-sequent >> calculation >> m is a list of circuit settings like temperature etc. >> o is a list of matrix solution for non-linear newton raphson >> p is a list of matrix solution for time dependent calculations > > > This would be better as, > > > data SystemParameterDatabase = SystemParameterDatabase > { infoSettings :: InfoSettings > , statistics :: Statistics > , settings :: Settings > , nlnr :: [Matrix Double] > , timeDependent :: [Matrix Double] > } > > data InfoSettings = InfoSettings > { pMSET :: MSET > , aSetting :: A > , bSetting :: B > ... > } > > data Statistics = Statistics > { aStatistic :: A > , anotherStatistic :: A > , bStatistic :: B > ... > } > > data Settings = Settings > { temperature :: Kelvin > , etc :: Etc > } > ... > > > A single-constructor ADT, especially with the labeled-fields syntax, is > pretty close to C structs; no need to reinvent them and give yourself > headaches. > > > Really, the only thing you should be using lists for is a variable-length > sequence of elements drawn from the same type and distinguished only by > their position in the sequence. Whenever the length is fixed or the > (semantic) type of elements can be distinguished from one another (or > altered by pushing/popping the list), then a list is not what you want to be > using because it doesn't capture the intention of the type (and therefore > allows unintelligible values of the type, and inappropriate transformations > on the type). > > -- > Live well, > ~wren This is the kind of code recommendations I was looking. thanks -- http://www.fernski.com

2 1

Problem resizing widget contained in window
by Jeff Heard 19 Jul '09

19 Jul '09

I created a window, like so: Gtk.windowSetTitle win name Gtk.widgetSetName win "Hieroglyph" Gtk.onDestroy win (exitWith ExitSuccess) Gtk.windowSetDefaultSize win w h Gtk.containerResizeChildren win And an GLDrawingArea like so: config ← Gtk.glConfigNew [Gtk.GLModeRGBA, Gtk.GLModeMultiSample, Gtk.GLModeDouble, Gtk.GLModeDepth, Gtk.GLModeAlpha] area ← Gtk.glDrawingAreaNew config Gtk.onRealize area ◊ GL.drawBuffer $= GL.BackBuffers Gtk.onExpose area (λ_ → renderOnExpose bus ≫ return True) and finally show it like this: Gtk.containerAdd win area Gtk.widgetShowAll win Now, if someone resizes the window, the GLArea does not appear to resize along with it. Did I screw something up? -- Jeff

2 1

ANNOUNCE: graphviz-2999.0.0.0
by Ivan Lazar Miljenovic 19 Jul '09

19 Jul '09

I am pleased to announce a new release of the graphviz package for Haskell, which provides bindings to the GraphViz [1] suite of tools. [1] http://www.graphviz.org/ Probably the biggest and most important change in this release is that AFAICT, all 152 attributes utilised/supported by GraphViz [2] are now specified and supported by this library. However, I'm not fully sure how well the parsing of these attributes will turn out; if you notice a bug/problem then please let me know. [2] http://graphviz.org/doc/info/attrs.html I've specified this as being the first in the 2999.0 series of releases. I will switch to 3000.0 when the generic graph class has been released and graphviz switched to using it rather than just FGL. One other future change that I'm considering is to improve the parsing ability of the Dot language. At the moment, graphviz assumes the following layout is followed: * Graph attributes * Nodes with their attributes (clusters are supported only for creation, not parsing). * Edges with their attributes. To match the behaviour of upstream, this will need to be changed into just a list of statements, where a statement is one of five things [3]: * A Node * An Edge * An attribute (either for the graph overall, nodes or for edges) * "ID '=' ID" (not quite sure what this is; some kind of assignment) * A subgraph (clusters are a specific type of subraph) As the way of defining an attribute for a specific grouping of nodes/edges/subgraphs is to have them all listed after the attribute definition (whereas those beforehand do not have this attribute), the imperative nature of the Dot language does not allow us to split these statements up as we currently do. [3] http://graphviz.org/doc/info/lang.html As such, I'm asking which of the following two choices people would prefer: 1. Follow upstream so that it can fully parse a Dot graph 2. Keep it as it is, so that it is possible to consider all edges, etc. easily. Other major changes to this release: ==================================== * Fixed a bug where the Show instance and read function for DotEdge had the from/to nodes the wrong way round. This was not immediately noticed since the Graph -> DotGraph functions created them the wrong way round, so for those users who only used these this was not apparent. Spotted by Neil Brown. * Greatly improved Attribute usage: almost all attributes are now covered with allowed values. * Extend DotGraph to include whether a graph is strict or not and if it has an ID. Also move the directedGraph field. * Make "Dot" refer to the actual dot command and DotArrow refer to the ArrowType (rather than DotCmd and Dot as before). * Make the Data.GraphViz.ParserCombinators module available to end users again, but not re-exported by Data.GraphViz; it has a warning message up the top not to be used. It is there purely for documentative purposes. * Use extensible-exceptions so that base < 4 is once again supported. * Follow the PVP rather than using dates for versions: http://www.haskell.org/haskellwiki/Package_versioning_policy Note that this means that any library/application using more than a trivial sub-set of graphviz will most likely need to be updated. However, now that the PVP is being followed it should be easier to tell in future when updates will be required. Other items I'm wanting to do in future releases: ================================================= * Allow user to choose whether or not the graph is meant to be directed or undirected. * Improve parsing to fully (or at least follow more closely) support Dot. * Improve clustering/subgraph support. * Use a PrettyPrinter rather than Show to generate Dot output. * Improve Output support. * Find and fix the handle closing bug with graphvizWithHandle. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

4 4

ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
by roconnor＠theorem.ca 19 Jul '09

19 Jul '09

> Max Rabkin wrote: >> On Sat, Jul 4, 2009 at 8:38 PM, Andrew >> Coppin<andrewcoppin at btinternet.com> wrote: >> >>> A few reasons: >>> >>> 1. I never knew it existed. ;-) >>> >> >> A good reason. However, it's good to do a quick search over Hackage >> before uploading (or before writing) so you know what's out there. >> >> Also, if you hadn't used an "AC-" prefix, you'd have had a name >> collision. Is there a particular reason why you want your name in the >> package name rather than just the author field? >> I find it amazing that you independently chose to spell colour with a `u'. It makes me feel better about my choice. >>> 2. It's mind-blowingly complex. >>> >> >> Colour *is* complex. Which is why I'm so glad Russell O'Connor did all >> the hard work for me :) >> > > Well, no, because now I'm going to have to spend a few hours trying to > find out what CIE is before I can even use that library. > > I think really it's just aimed at a different problem. It looks like > it's trying to specify actual real-world colours. [It's news to me that > this isn't fundamentally impossible...] I'm only trying to specify > colours on a computer screen. And as we all know, computer screens > aren't calibrated in any way, and the same RGB value looks different on > each display. But then, I'm only trying to write a fractal generator, so > CIE specifications are somewhat overkill here. ;-) You can use by lib without worrying about the CIE. You can use my library without ever importing or using the word CIE. However, the CIE stuff is there for those who need it. Perhaps I (maybe with some help) need to make a tutorial on the haskell wiki to try to make it less intimidating. >>> 3. It doesn't appear to provide arithmetic over colours. >>> >> >> It provides darken, blend and addition (though addition is called >> mappend rather than (+)). signum, abs and fromInteger don't make a >> huge amount of sense for colours. >> > > Yeah, I implemented signum and so forth for colours and vectors, but > they're not particularly meaningful... [Insert remark here about > Haskell's numeric class hierachy.] > > So mappend gives you colour addition [with the perplexing comments about > "gamut", presumably some kind of small mammal?], but there's no > subtraction? No multiplication? No linear blending? Linear blending is done by the affineCombo function. I think the darken function will do what you mean by multiplication Colour subtraction can be done by adding (using mappend) a colour that has been darkend by a factor of (-1). I don't believe there is any demand for a colour subtraction fuction, so I don't have a name for it. I suppose these sorts of questions can be put nicely into a short tutorial on the wiki. >>> 4. It's parameterised over the component type; my library is hard-coded > to >>> specific types for speed. >>> >> >> My feeling would be to trust the specializer until it lets me down. >> Has it let you down in the past? >> > > Heh, my colour library includes a custom floor implementation that talks > to the GHC primops directly because calling floor is too slow... > > [In case that sounds like idle talk, I had a program go from 10 seconds > to less than 1 second just by using this function. There's a few tickets > about it on the GHC Trac.] Certainly speed is an issue that I haven't tackled yet since I don't know too much about how to optimized Haskell code. I was thinking of sprinkling in some SPECIALIZE pragmas and maybe adding some RULES to make operations more effecient. For example we could have a rule to rewrite floor to some sort of GHC specific fast floor function. (Although that rule probably deserves to be in some sort of more general location). Any help in this direction would be appricated (perferably while keeping things as portable as possible). This all being said, the major problem my code solves is doing blending in a linear colour space. This necessarily make converting to non-linear sRGB for output much slower. So for people who want speed over proper blending, then probably AC-Colour is the package they need to reach for. Essentially the two packages do fill different niches! >> BTW, the EasyRaster package looks useful. >> I haven't looked at EasyRaster yet, but I got excited when I saw it announced. :) -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

10 18

Problem with lazy IO
by Maciej Piechotka 19 Jul '09

19 Jul '09

Hello. I've tried to combine lazy IO and parsec. The hole process is done by network. Currently I have implemented 'short parsers' so I enter them on need. To update state I have following code: parser2nntp :: Monad m => NntpParser m a -> NntpT m a parser2nntp p = do s <- NntpT (gets $ input . connection) e <- runParserT (do v <- p i <- getInput return (v, i)) () "" s case e of Left er -> error $ show er Right (v, i') -> (NntpT (modify (pNI i')) >> return v) where pNI :: Monad m => ByteString ->NntpState m -> NntpState m pNI i s = s {connection = (connection s) {input = i}} However the 4 line (i <- getInput) blocks the execution as trace indicated. String returned have no input available so it should block on evaluation - and here I pass only a reference to it (or rather I think so). What's wrong? PS. Full code is in darsc nntp repository http://code.haskell.org/nntp/ - please note that it seems to require network compiled against parsec 3 - not 2.

1 1

Why is there no Zippable class? Would this work?
by Job Vranish 19 Jul '09

19 Jul '09

I was needing a way to zip generic data structures together today and was very annoyed to find that there is no Zippable class, or variant there of. So I made my own: class (Foldable f, Functor f) => Zippable f where fmaps :: (Foldable g) => g (a -> b) -> f a -> f b fmaps' :: [a -> b] -> f a -> f b -- to save a step on instance implementation zipWith :: (a -> b -> c) -> f a -> f b -> f c zip :: f a -> f b -> f (a, b) unzip :: f (a, b) -> (f a, f b) fmaps fs a = fmaps' (toList fs) a fmaps' fs a = fmaps fs a zipWith f a b = fmaps (fmap f a) b zip = zipWith (,) unzip a = (fmap fst a, fmap snd a) instance Zippable [] where fmaps' (fx:fs) (x:xs) = fx x : fmaps' fs xs fmaps' _ _ = [] --The fmaps function is also quite handy as a replacment for zipWith3, zipWith4, etc... --For example: x = [1, 3, 5, 7, 3] y = [6, 9, 3, 1, 4] z = [2, 4, 0, 8, 2] test = fmap (,,) x `fmaps` y `fmaps` z -- > [(1,6,2),(3,9,4),(5,3,0),(7,1,8),(3,4,2)] --you can also throw in a functor instance to remove the dependency on the Functor class, but it -- might not be worth it: instance (Zippable f) => Functor f where fmap f a = fmaps (repeat f) a Is there any good reason that there isn't something like this in the standard libraries? Or, as far as I can tell, on hackage? If not, then maybe I'll stick it on hackage. - Job Vranish

10 12

A voyage of undiscovery
by Andrew Coppin 18 Jul '09

18 Jul '09

I've been working hard this week, and I'm stumbled upon something which is probably of absolutely no surprise to anybody but me. Consider the following expression: (foo True, foo 'x') Is this expression well-typed? Astonishingly, the answer depends on where "foo" is defined. If "foo" is a local variable, then the above expression is guaranteed to be ill-typed. However, if we have (for example) foo :: x -> x as a top-level function, then the above expression becomes well-typed. I had never ever noticed this fact before. I'm still trying to bend my mind around exactly why it happens. As best as I can tell, top-level functions (and value constructors, for that matter) seem to get a "new" set of type variables each time they're used, but local variables each get a single type variable, so every mention of a local variable must be of the exact same type. Could this be what GHC's weird "forall" syntax is about? Does "forall x." mean that "x" gets replaced with a unique type variable each time? It's an interesting hypothesis... Anyway, not that anybody is likely to care, but I've just spent an entire week writing a program which can type-check simple Haskell expressions. As in, you type in an expression and give types to any free variables it involves (including value constructor functions), and it tells you the type of the expression and all its subexpressions. (Or tells you that it's ill-typed.) It turns out that this is radically less trivial than you'd imagine. (The ramblings above being just one of the issues I blundered into. Others include the subtleties of writing an expression parser, building a pretty-printer with bracketing that works correctly, and the fact that expression processing malfunctions horribly if you don't make all the variable names unique first...) Other issues were mostly related to the difficulty of constantly refactoring code because you're not quite sure what you're trying to do or how you're trying to do it. (And obscure type checker warnings about GADTs...) Well there we are. I don't suppose anybody will be overly impressed, but I'm glad to have finally got it to work. Now, if it could parse more than 10% of Haskell's syntax sugar, it might even be useful for something...

9 15

Debugging methods for haskell
by Fernan Bolando 18 Jul '09

18 Jul '09

Hi all I recently used 2 hours of work looking for a bug that was causing Program error: Prelude.!!: index too large This is not very informative. It did not give me a hint which function was causing this. In C adding a few printf would have helped me, but in haskell I was not sure how to do that. Can anybody point me to some debuggin method everyone uses. After 2 hours I did find the bug eventually. The code can be viewed here. Maybe some reformatting of the code would make finding bugs easier? http://plan9.bell-labs.com/sources/contrib/fernan/escomma/ fernan -- http://www.fernski.com

10 14