- Libraries - Haskell.org

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

RE: state of the cabal (preprocessors)
by Simon Marlow 27 Oct '04

27 Oct '04

On 27 October 2004 18:15, Isaac Jones wrote: > 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? I think there's been a misunderstanding. At least I was assuming you would do the same thing for Hugs, that is preprocess the sources at build time. I thought this was the plan all along... apologies if I'm the source of the misunderstanding. Cheers, Simon

1 0

RE: System.FilePath propsal (Was: Cabal feedback notes)
by Simon Marlow 27 Oct '04

27 Oct '04

On 27 October 2004 17:47, Philippa Cowderoy wrote: > On Tue, 26 Oct 2004, Krasimir Angelov wrote: > >> It is not hard to split System.FilePath to >> System.FilePath.Posix and System.FilePath.Windows. I >> will do that if other people also agree on that. >> > > That makes life... irritating for those of us trying to write > genuinely portable code, insofar as there's no > System.FilePath.DoTheNativeThing. It'd be nice to be able to do > things like get a list of the files, just the files[1], in a given > directory without having to use a preprocessor or similar for > portability. > > [1] As opposed to directory entries like ".." I don't think Krasimir meant that System.FilePath would be *replaced* by the platform-specific versions, just that the platform-specific versions would be provided for those wishing to manipulate non-native paths. You'd still get System.FilePath. Cheers, Simon

1 0

RE: state of the cabal (preprocessors)
by Simon Marlow 27 Oct '04

27 Oct '04

On 25 October 2004 13:57, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >>> [Aside: Is there a general agreement that the OPTION pragma should >>> be understood by all Haskell systems, whereas system-specific >>> options are given by pragmas like OPTIONS-GHC, OPTIONS-NHC, etc. >>> or something along those lines?] >> >> I'm happy to switch to using {-# OPTIONS_GHC #-} (or something) if >> there's consensus. Consider that a vote in favour on behalf of the >> GHC camp. > > Currently I believe ghc uses > {-# OPTIONS ... #-} > whilst nhc98 uses the pair > {-# OPTIONS_COMPILE ... #-} > {-# OPTIONS_LINK ... #-} > and Hugs has > #!runhugs ... > > I have no specific preferences for naming, and am happy to change to > whatever consensus arrives. However I do think separating out extra > link options from the compile-time options could be useful. Are the link options from each module stored in the .hi file and collected together at link time? GHC doesn't have anything like that. Link-time options have a place in the package-wide Cabal description, too. Options in a source module are good for options which apply to this particular module and no other, whereas link options are more global. I'm not sure that I'd put link options in the source files even if I could. For the compile-time options, how about {-# OPTIONS_{GHC,NHC98,HUGS} ... #-} and we should probably have a compiler-independent way to specify extensions. Hmm, wasn't there a proposal for {-# LANGUAGE #-} at one time? Cheers, Simon

4 3

RE: System.FilePath propsal (Was: Cabal feedback notes)
by Simon Marlow 27 Oct '04

27 Oct '04

On 27 October 2004 14:58, Graham Klyne wrote: > Also, a very small point: I forgot that FilePath is defined in the > prelude... maybe a comment to this effect on the module export list? The library should export FilePath too, for consistency. Cheers, Simon

1 0

RE: System.FilePath propsal (Was: Cabal feedback notes)
by Simon Marlow 27 Oct '04

27 Oct '04

On 26 October 2004 19:44, Krasimir Angelov wrote: > It is not hard to split System.FilePath to > System.FilePath.Posix and System.FilePath.Windows. I > will do that if other people also agree on that. If you decide to do this, then System.Posix.FilePath and System.Win32.FilePath would be more consistent with the existing structure, I think. Cheers, Simon

1 0

RE: System.FilePath propsal (Was: Cabal feedback notes)
by Simon Marlow 27 Oct '04

27 Oct '04

On 26 October 2004 19:30, Krasimir Angelov wrote: > --- Peter Simons <simons(a)cryp.to> wrote: >> I think the use of FilePath is not a good idea to >> begin >> with. A file path should be a data type something >> like this, >> IMHO: >> >> type Segment = String >> data FilePath = Path [Segment] >> | RootedPath [Segment] >> >> You shouldn't write slashes or backslashes which are >> converted later, you should use a, say :/: operator to build >> paths portably right from the start. > > I don't think I will be happy with that. Most of I/O > functions in Haskell uses FilePath as String. If we > use data type instead of String we need to pretty > print/parse the structure each time when we use it for > I/O. Yes, in some sense having an abstract type or a datatype for FilePaths would be the right thing. But it's a much larger change, and would probably break a lot of code. The goal here is just to provide some utilities that already exist in one form or another in several places. By all means start discussing the ultimate FilePath representation separately, though. Cheers, Simon

1 0

RE: state of the cabal (preprocessors)
by Simon Peyton-Jones 27 Oct '04

27 Oct '04

| As to backwards compatibility in general, would there be a problem | if GHC and NHC continue to support their respective OPTIONS variants | as a deprecated feature? Then no old code should break. I think this is highly desirable. There are a lot of those OPTIONS pragmas out there now. Simon

1 0

RE: state of the cabal (preprocessors)
by Simon Marlow 26 Oct '04

26 Oct '04

To hopefully wind up this discussion, I'd like to make three proposals: 1. That if a compiler understands an in-file pragma specifying options, it should take the form {-# OPTIONS_<compiler> ... #-}. 2. We introduce a new pragma to specify the language extensions in force for the current source file. I suggest: {-# LANGUAGE <ext1>,...,<extn> #-} where <ext> is taken from the list of extensions understood by Cabal in the 'extensions' field of a package description (eg. OverlappingInstances, RecursiveDo, etc.). 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. Hmm, I've just realised some problems with this. Hugs probably won't be implementing {-# LANGUAGE #-} any time soon (I imagine?) so it wouldn't be portable. Also old compilers don't implement it, so we have a difficult migration path. Perhaps for the time being we just do 1 & 3, and use the package-wide list of extensions for portability. Cheers, Simon

4 4

RE: Tools for Windows (was: Building Haddock on Windows)
by Simon Marlow 26 Oct '04

26 Oct '04

On 25 October 2004 13:37, Graham Klyne wrote: > The comments that follow are provided to underscoring how I feel the > Haskell community is tending to favour Unix-like system users over > Windows users. If Haskell is to find more widespread use, I think > it's important to make life easy for Windows users who don't have > Unix-like tools installed (or who don't entirely understand the Unix > way of doing things). I couldn't agree more. If I had the time, I'd like to make a completely Windows-native version of GHC (no MinGW), since the MS compiler tools are now freely available as part of Visual C++ Express. In the meantime, we're heading in the right direction. GHC itself doesn't require Cygwin to run, and Cabal is designed to work without requiring Cygwin. So when everything is available as a Cabal package, you'll be able to build & install many tools and libraries without requiring Cygwin, the exceptions being those Cabal packages which use autoconf & make. One day Cabal will be able to produce a .msi. All the bits are there - it just needs someone to put them together. One day we'll have a compile farm churning out .msi's (and RPMs, .debs etc.) for all the known packages and putting them up for download on haskell.org. Also, in case you weren't aware of this, we have some pretty detailed instructions on setting up your build environment on Windows for buidling GHC, here: http://www.haskell.org/ghc/docs/latest/html/building/winbuild.html This is a superset of what you need to build Happy, Haddock etc. Cheers, Simon

1 0