- Libraries - Haskell.org

RE: Preprocessors
by Simon Marlow 21 Oct '04

21 Oct '04

On 20 October 2004 17:03, Peter Simons wrote: > Sven Panne writes: > > > If you mean "everyone happy with a LGPL", then I would > > agree. But GHC and Hugs use a BSD-style license, so cpphs > > is not an option for them. > > Why not? I wouldn't go so far as to say "not an option", but we definitely prefer as much of the system to be BSD-licensed as possible. It makes life much easier for our commercial users. I could talk at length on the subject, but life's too short :-p Cheers, Simon

4 3

monadLib 1.0 available
by Iavor S. Diatchki 20 Oct '04

20 Oct '04

Hello everyone, A version of the monad library I work on every now and then is now available from my web page: http://www.cse.ogi.edu/~diatchki/monadLib/ It can also be obtained from the 'fptools' CVS repository in subdirectory: libraries/monads (note that the files under Unstable/* are obsolete and i don't plan to work on them anymore) In principle it is quite similar to the library distributed with the usual Haskell implementations. In this version there was no effort to make the two compatable. The library interface is documented using the haddock tool (thanks Simon!). For questions, suggestions, or bug reports, please drop me a mail. -Iavor

1 0

RE: state of the cabal (preprocessors)
by Graham Klyne 20 Oct '04

20 Oct '04

This has me thinking that it might be helpful if Cabal's package config file allowed package filenaming conventions to be specified (with appropriate defaults so that most packagers don't have to worry about it). #g -- At 14:12 20/10/04 +0100, Simon Marlow wrote: >On 19 October 2004 18:03, Malcolm Wallace wrote: > > >> I agree with Henrik about doing the preprocessing for Hugs at > >> installation or packaging time, so that users don't need the full > >> environment. > >> That's what currently happens with the fptools libraries. > > > > OK, so I think we are probably agreed on this then: > > > > * When Cabal is installing for Hugs, it does 'cpp -D__HUGS__' > > (or equivalent) on all Haskell source files, as it copies them > > into the installation location. > >Sure, I thought that was the plan already? For Hugs, "compiling" >consists of preprocessing and nothing more. > > > If any more complicated situations arise between the ordering of > > cpp and other preprocessors, use a chain of file extensions to > > disambiguate? e.g. > > .ly.cpp = cpp first -> .ly, then literate happy to get .hs file. > > .cpp.ly = literate happy -> .cpp.hs, then cpp to get plain .hs > > file. > >The second example is inconsistent - if the convention is that the >suffix at the end of the filename specifies the topmost layer, then >.cpp.hs is a plain Haskell file (whereas .hs.cpp would be Haskell to be >processed with CPP). You'd have to modify Happy to generate .hs.cpp >from .ly, or do this with an explicit -o option to Happy. > >While consistency is a good thing, in this case I'm not convinced. >Converting all my .hs files to .hs.cpp is going to be really painful. >Plus it's not really a compiler-independent CPP phase because of the >preprocessor symbols injected by the compiler. > >I think a special case for CPP is in order, because (at least in my >experience) a lot of Haskell is CPP'd. All of GHC and most of the >libraries are CPP'd for example. > >So I'd be happy if Cabal had a package-wide CPP flag. That is, with the >flag on, all .hs and .lhs files in the package are CPP'd. Think of it >as a flag that affects the language, in the same way that we turn on >various Haskell extensions via flags (I know the analogy isn't perfect). > >If you want per-file granularity, then a directive in the Haskell file >would be fine. GHC currently uses {-# OPTIONS -cpp #-}, but I'd be >happy to implement a different syntax. > >Cheers, > Simon >_______________________________________________ >Libraries mailing list >Libraries(a)haskell.org >http://www.haskell.org/mailman/listinfo/libraries ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

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

20 Oct '04

On 19 October 2004 18:03, Malcolm Wallace wrote: >> I agree with Henrik about doing the preprocessing for Hugs at >> installation or packaging time, so that users don't need the full >> environment. >> That's what currently happens with the fptools libraries. > > OK, so I think we are probably agreed on this then: > > * When Cabal is installing for Hugs, it does 'cpp -D__HUGS__' > (or equivalent) on all Haskell source files, as it copies them > into the installation location. Sure, I thought that was the plan already? For Hugs, "compiling" consists of preprocessing and nothing more. > If any more complicated situations arise between the ordering of > cpp and other preprocessors, use a chain of file extensions to > disambiguate? e.g. > .ly.cpp = cpp first -> .ly, then literate happy to get .hs file. > .cpp.ly = literate happy -> .cpp.hs, then cpp to get plain .hs > file. The second example is inconsistent - if the convention is that the suffix at the end of the filename specifies the topmost layer, then .cpp.hs is a plain Haskell file (whereas .hs.cpp would be Haskell to be processed with CPP). You'd have to modify Happy to generate .hs.cpp from .ly, or do this with an explicit -o option to Happy. While consistency is a good thing, in this case I'm not convinced. Converting all my .hs files to .hs.cpp is going to be really painful. Plus it's not really a compiler-independent CPP phase because of the preprocessor symbols injected by the compiler. I think a special case for CPP is in order, because (at least in my experience) a lot of Haskell is CPP'd. All of GHC and most of the libraries are CPP'd for example. So I'd be happy if Cabal had a package-wide CPP flag. That is, with the flag on, all .hs and .lhs files in the package are CPP'd. Think of it as a flag that affects the language, in the same way that we turn on various Haskell extensions via flags (I know the analogy isn't perfect). If you want per-file granularity, then a directive in the Haskell file would be fine. GHC currently uses {-# OPTIONS -cpp #-}, but I'd be happy to implement a different syntax. Cheers, Simon

2 1

RE: Preprocessors (was: state of the cabal (preprocessors))
by Simon Marlow 20 Oct '04

20 Oct '04

On 20 October 2004 10:22, Ketil Malde wrote: > I've recently run into a problem using the preprocessor (ghc -cpp). > It seems it barfs on 's (apostrophe). Annoying, since naming > variables something-prime is a fairly common idiom. > > Is this something that has a workaround, or could be fixed? > > (The specific problem is redefining 'head' in a macro > and using it like: > > let w' = head ... -- breaks > > One workaround is to write it as: > > let w' = > head ... -- works > ) That shouldn't happen, and indeed it doesn't happen to us. Could you provide more details: platform, GHC & GCC versions, and sample code that exhibits the problem. Probably best to move this to glasgow-haskell-bugs(a)haskell.org too. Cheers, Simon

1 0

RE: state of the cabal (preprocessors)
by Graham Klyne 19 Oct '04

19 Oct '04

At 12:46 19/10/04 +0100, Simon Marlow wrote: >Also, I recommend that we use the compiler itself for preprocessing: > > ghc -E foo.hs -o foo.phs Er, shouldn't it be possible to use Cabal with a system that has just Hugs installed? #g -- At 12:46 19/10/04 +0100, Simon Marlow wrote: >On 19 October 2004 09:58, Malcolm Wallace wrote: > > > Isaac Jones <ijones(a)syntaxpolice.org> writes: > > > >> The issue with cpp is that we can't go by extensions as we do with > >> the rest of the preprocessors... There is a function in HMake which > >> tests to see if a file needs to be cpp'd, so we can employ that. I > >> think we'll probably have to just treat cpp a little differently > >> from the others, unfortunitely, and I haven't gotten around to it. > > > > On the other hand, you could reject the convention that cpp sources > > are not distinguished by file extension - e.g. create a new convention > > that, say, a .cpphs extension is preprocessed by cpp(hs) to get a > > plain .hs file. > > > > Since Cabal is pretty new, this won't break any existing Cabal > > packages, and when converting non-Cabal packages to Cabal, there is > > some work to do anyway, so why not just adopt this as one extra rule > > to follow? > > > > This is just a suggestion - I'm in two minds whether it is a good > > idea myself, but it is at least worth considering the possibility. > >And I suppose the literate version would be .lcpphs? (unlit first, then >cpp, then Haskell). It would be more consistent and arguably correct, >but I'm not sure that we should do it. > >Another solution is to adopt a new extension for plain Haskell, say >.phs. The conversion from .hs to .phs is either via CPP or just 'cat', >depending on some setting somewhere. Also, I recommend that we use the >compiler itself for preprocessing: > > ghc -E foo.hs -o foo.phs > >because only the compiler knows what the values for the preprocessor >symbols __HASKELL__, __GLASGOW_HASKELL__, i386_TARGET_ARCH etc. should >be. Otherwise we'll have to run the compiler during ./setup configure >to find out the values of these symbols (isn't that what hmake does? >What about when a new compiler comes along?). > >Cheers, > Simon >_______________________________________________ >Libraries mailing list >Libraries(a)haskell.org >http://www.haskell.org/mailman/listinfo/libraries ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

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

19 Oct '04

On 19 October 2004 13:42, Malcolm Wallace wrote: >> Another solution is to adopt a new extension for plain Haskell, say >> .phs. The conversion from .hs to .phs is either via CPP or just >> 'cat', depending on some setting somewhere. > > Not very pretty. True :-) >> Also, I recommend that we use the compiler itself for preprocessing: >> >> ghc -E foo.hs -o foo.phs > > You are right that the compiler is best placed to define pp symbols, > so this is all very well, but neither nhc98 nor Hugs currently have > the -E option to stop immediately after pp. And come to think of it, > the only real reason to have cpp done separately at all is because > Hugs does not have a preprocessor call builtin, like ghc and nhc98 do. > So maybe the best solution is to ship Hugs with -F"cpphs.hugs" > enabled by default? Then no separate extension would be required, > and Cabal could just defer all cpp-ing to the compiler. That would be fine, except that Cabal might want to get access to the raw CPP'd source file for two reasons I can think of: - calculating dependencies, like hmake does - running Haddock As long as you can do preprocessing with 'ghc -E' or similar (cpphs?) then everything's fine. Cheers, Simon

1 0

URI handling code
by Graham Klyne 19 Oct '04

19 Oct '04

I recently placed my revised version of URI handling code in cvs.haskell.org: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/network/Network/ and http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/network/tests/ Today, I see that the new URI specification upon which it has been based has been approved for publication as a full Internet standard: http://lists.w3.org/Archives/Public/uri/2004Oct/0012.html #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

state of the cabal (preprocessors)
by Isaac Jones 19 Oct '04

19 Oct '04

Hey all. Just thought I'd give an update... Cabal now does something [1] for preprocessors, though it's perhaps not perfect. I need a real test case, a smallish program that uses a preprocessor (except for cpp, which isn't yet supported). Any suggestions? Something that uses happy perhaps? Once I have such an example, and get cpp working nicely, then I'll release 0.2. Here's the cabal web page: http://www.haskell.org/cabal/ You can of course see what I have now by using darcs to check out the repository. On Debian simply: % apt-get install darcs % darcs get http://cvs.haskell.org/darcs/cabal peace, isaac [1] Foo.y is a happy grammer which, when processed, will produce Foo.hs. The description file should include the module Foo. ./setup sdist (source distribution): Include Foo.y, not Foo.hs. Maybe we could add a flag to include Foo.hs as well. This makes sense for some preprocessors and not for others, but I'm wary of including too much preprocessor-specific behavior. ./setup clean: Removes Foo.hs if Foo.y exists. ./setup build: Preprocesses Foo.y to Create Foo.hs before any compilation. The issue with cpp is that we can't go by extensions as we do with the rest of the preprocessors... There is a function in HMake which tests to see if a file needs to be cpp'd, so we can employ that. I think we'll probably have to just treat cpp a little differently from the others, unfortunitely, and I haven't gotten around to it.

3 2

FFI bindings to OpenSSL available
by Peter Simons 18 Oct '04

18 Oct '04

Hi, I've just made the first version of my OpenSSL bindings available under: http://cryp.to/hopenssl/ Currently, the library contains only one module, Digest.hs, which provides a convenient Haskell interface to the message digest algorithms found in OpenSSL "crypto" library. (MD2, MD5, SHA, SHA1, DSS, DSS1, MDC2, and RIPEMD160.) A similar API to the symmetric cipher algorithms is expected to follow shortly. Patches, additions, and general feedback is -- as always -- highly welcome. Peter

1 0