October 2004 - Libraries

RE: Cabal feedback notes
by Simon Marlow 02 Nov '04

02 Nov '04

On 23 October 2004 10:01, Krasimir Angelov wrote: > One way to make Cabal really portable is to move the > entire platform specific code out of it. One example > is > Distribution.Simple.GHCPackageConfig.localPackageConfig > function, which uses HOME environment variable to > determine the user's home directory, but this doesn't > work under Windows. The CVS System.Directory module > already provides the getAppUserDataDirectory function > which is more suitable (and portable) in this case. localPackageConfig is only for GHC 6.2: in 6.4, GHC and ghc-pkg will know where the local package conf lives, so Cabal won't need this knowledge built-in. > Another example is > Distribution.Simple.Utils.findBinary. Recently I had > updated it and now it is portable but now I see that a > similar function is used in runghc tool but in its non > portable version. If we move this to the standard > libraries then we will be able to use it in both > cases. Most of the other #ifdef-s are related to the > filepath handling. It will be great benefit if we > isolate it in a separate library. I already use the > filepath routines in VSHaskell. You can see that a > similar functions are used in haddock, happy and alex > tools. Maybe if we agree on this it is not too late to > add it before the next GHC release. Last time this came up I asked for a concrete proposal, but no-one came forward with one. I'd do it myself, but I'm kind of busy right now. Would someone care to whip up a list of functions & signatures? I'm inclined to just stick something into the libraries even if it's not perfect. The filename handling issue is one of those things where trying to define a perfectly portable library is hard if not impossible, but having *something* is going to be useful to a lot of people, and as Krasimir says it'll have a lot of duplicated code. Data.FilePath or System.Directory? I'm inclined towards the latter, since we clearly want functions that actually inspect the filesystem (findBinary, getExecutableFilePath) along with functions that just manipulate filenames, and it seems strange to split them up. Cheers, Simon

16 34

Data.List.partition on infinite lists
by Lemming 01 Nov '04

01 Nov '04

I encountered that the implementation of 'partition' in GHC 6.2.1 fails on infinite lists: > partition :: (a -> Bool) -> [a] -> ([a],[a]) > partition p xs = foldr (select p) ([],[]) xs > select p x (ts,fs) | p x = (x:ts,fs) > | otherwise = (ts, x:fs) With the following definition we don't have this problem: > partition :: (a -> Bool) -> [a] -> ([a], [a]) > partition _ [] = ([],[]) > partition p (x:xs) = > let (y,z) = partition p xs > in if p x then (x : y, z) > else (y, x : z) Prelude> take 10 $ fst $ partition even [0..] [0,2,4,6,8,10,12,14,16,18] Prelude> take 10 $ snd $ partition even [0..] [1,3,5,7,9,11,13,15,17,19]

4 3

RE: state of the cabal (preprocessors)
by Simon Marlow 01 Nov '04

01 Nov '04

On 26 October 2004 18:00, Henrik Nilsson wrote: > However, at least superficially, it would seem simpler (and more > flexible, since normal comments would not interfere) to simply > require that all OPTIONS/LANGUAGE pragmas must occur before the > keyword "module". > > But maybe that is hard to implement, or undesirable for some other > reason? Well, it's more tricky because you have to ignore comments, and therefore understand nested comments, but that's not too hard. A little Alex or parsec parser should do the trick, being careful not to read the entire file. I think Cabal could provide the functionality in a library: getOptionsFromSource :: FilePath -> IO ( [Extension], -- LANGUAGE pragma, if any [(CompilerFlavour,[String])] -- OPTIONS_FOO pragmas ) Cheers, Simon

2 1

Re: state of the cabal (preprocessors)
by Isaac Jones 31 Oct '04

31 Oct '04

"Simon Marlow" <simonmar(a)microsoft.com> writes: > On 26 October 2004 22:34, Isaac Jones wrote: > >> "Simon Marlow" <simonmar(a)microsoft.com> writes: >> >> (snip) >>> 3. We add CPP to the list of extensions in Cabal, so you can say {-# >>> LANGUAGE CPP #-} to get C preprocessing in the current file, or add >>> CPP to the list of extensions in the package description to get CPP >>> on every file. That doesn't preclude also using a .cpp extension, >>> but it means you don't have to. >> >> For hugs this would mean preprocessing all files and putting the new >> .hs files into a temp directory and compiling these. > > Yes, modulo Henrik's comments. I think you mean put the preprocessed > .hs files into the dist/build/ directory and install them from there. Right, but I was actually talking about the 'build' step, which is a bit funny... For the build step, we have to do preprocessing still, so that the developer or user of VS can use the code. For the install step, unlike the other systems, we're proposing that we do the preprocessing here rather than at the build step since presumably it would be more convinient to be platform independent at that point? I'm not sure why this is such a great idea. For each other haskell implementation, once you build, it's tied to the platform, and you no longer need the build tools. Why not do the same thing for hugs? Otherwise, the install step won't be based on the sources produced during the build step, but rather at the unpreprocessed sources. Usually the build step prepares the sources. Also, what if there are other preprocessors that have to be run after cpp? Are we going to require these to be installed on the target machine too? Sorry if I'm going over ground we've already covered... I am in a training class this week and don't have much internet time. Feel free to point me to the archive URLs for any of my questions :) peace, isaac

2 2

hunit
by Ian Lynagh 31 Oct '04

31 Oct '04

Hi all, What's the canonical source for hunit these days? Both http://hunit.sourceforge.net/ and fptools claim to have 1.0, but the former is in a flat namespace while the latter uses hierarchical libraries. Thanks Ian

1 0

RE: Building Haddock on Windows
by Graham Klyne 29 Oct '04

29 Oct '04

At 11:52 25/10/04 +0100, Simon Marlow wrote: >I've now put binary zips for Windows of Haddock and Happy up on >haskell.org. These are snapshots of recent CVS sources: > > http://www.haskell.org/haddock/haddock-Win32-snap.zip > http://www.haskell.org/happy/dist/happy-Win32-snap.zip > >There's already a binary zip of Alex available. Thanks. I've added some links from the Wiki page: http://www.haskell.org/hawiki/LibrariesAndTools http://www.haskell.org/hawiki/LibrariesAndTools#head-ed5b9922c3c8f6a33ac20f… #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

3 3

Re: Wiki spame [ was: Building Haddock on Windows ]
by Udo Stenzel 29 Oct '04

29 Oct '04

Sven Panne <Sven.Panne(a)aedion.de> schrieb am 29.10.04 08:44:28: > That's > exactly why I think that very open Wikis are doomed to death nowadays, given > the criminal energy of spammers. I don't think the problem is as serious as you make it look. Any registered wikizen can restore any page to a known good state with just two clicks (info icon, then "restore"). Spammers use scripts these days on wikis, and spam scripts seem to exist for only a few wiki engines at the moment. I suspect they stop working if we make some small changes (like renaming the "edit" action) to MoinMoin. The proposed all-encompassing solution to WikiSpam is to integrate a captcha into the edit page, which would keep scripts out for good. Some future version of MoinMoin will probably include something like that. In short, I think the hawiki is still quite useable and won't drown in unhandled spam anytime soon. Regards, Udo. __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

1 0

Re: understanding HaXml and escaping
by Malcolm Wallace 28 Oct '04

28 Oct '04

[moved to libraries list from haskell list] > You have a Dtd2Haskell tool, but DTDs are very > inexpressive and the result is string based types. Yes, DTDs are pretty blunt. > Is there a tool for converting e.g. relaxNG into > haskell types? Then we get direct support for > e.g. doubles or URLs. Not yet. I have thought about conversions from e.g. XML Schema, and I'm certain it would be very useful, but (a) judging by the proliferation of competition in extended type systems for XML, there seems to be little consensus yet on the "best"; (b) I don't have the time anyway - there's unlikely to be a nice research paper in it... Perhaps it would make a nice student project...? Regards, Malcolm

1 0

Re: understanding HaXml and escaping
by Malcolm Wallace 28 Oct '04

28 Oct '04

[moving discussion from Haskell list to libraries list] "S. Alexander Jacobson" <alex(a)alexjacobson.com> writes: > It would be helpful to have an example of > using combinators to take a value of type e.g. > > import Network.URI > import System.Time > data Foo = Foo {uri::URI, > name::String, > stamp::ClockTime} > > and produce e.g. a string such as > > <? xml version="1.0" ?> > <? xml-stylesheet type="text/xsl" href="myStyle.xsl"?> > <Foo xmlns:Foo="http://mynamespace" > uri="http://someURL" name="blah" > stamp="Mon, 11 Oct 2004 09:05:31 -0400"/> Well, fundamentally, this kind of conversion is dependent not only on the Haskell type defined by your application, but also the way you want to represent it in XML. There are lots of possible choices for the latter. The DRiFT implementation that derives the Haskell2Xml class makes one choice for the type mapping, using nested elements - you have made a rather different choice that uses attributes instead. Neither is more "correct" - it is a stylistic judgement. Although one could perhaps define some kind of meta-language for describing various kinds of HaskellType -> XMLType translation, with an automatic processor to derive a particular translation for the type instances you want today, that is probably overkill. Why not just write the specific mapping by hand in the first place (as you have now done)? > Note, I think I've figured out how to do this > using raw types (after modifying to allow PIs in > the prolog!), but I assume using the combinators > is more correct. No, the combinators are not "more correct". They are just one possible implementation choice, heavily biased towards XML -> XML transformations. If you are mainly generating documents rather than transforming them, then the combinators might be unhelpful. So just use the raw XML element etc types instead. At least you can re-use the parser, validator, and pretty-printer. > But I actually think the document function should > *automatically* implement xmlEscape. Otherwise, > it is too easy for the user to produce incorrect > documents notwithstanding what the library claims > to promise! Yes, good point. > Will this work to insert a PI before the first > element? No, the CFilter combinators only manipulate the element content, not the DTD or Prolog. (Other XML toolboxes may have made different choices here - I think Uwe Schmidt's HXT allows combinator-processing of the DTD for instance.) Regards, Malcolm

1 0

Regexp library
by Ian Lynagh 27 Oct '04

27 Oct '04

Hi all, I've written a simple regexp library for POSIX EREs, with a similar interface to Text.Regex. Benefits over Text.Regex include: Works in nhc98 Laziness: RE> match "^a" ('a':error "Foo") Just [] Could easily be altered for regexps on lists of other datatypes Missing features: Text.Regex's matchRegexAll (should be simple to add) [[=a=]] and [[.ch.]] (don't plan to add these) I haven't looked at cabalising it or anything yet. It can be downloaded from http://urchin.earth.li/~ian/re-0.0.1.tar.gz or darcs get http://urchin.earth.li/darcs/ian/regexp Thanks Ian

2 2