November 2007 - cabal-devel

patch applied (cabal-branches/cabal-1.2): FIX BUILD with GHC 6.2: getTemporaryDirectory wasn't available
by Ian Lynagh 27 Nov '07

27 Nov '07

Fri Nov 23 01:31:21 PST 2007 Simon Marlow <simonmar(a)microsoft.com> * FIX BUILD with GHC 6.2: getTemporaryDirectory wasn't available M ./Distribution/Compat/Directory.hs -1 +58 M ./Distribution/Simple/GHC.hs -2 +2

1 0

patch applied (cabal): Partial implementation of installing for nhc98
by Duncan Coutts 27 Nov '07

27 Nov '07

Tue Nov 27 09:41:32 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Partial implementation of installing for nhc98 Doesn't install into the right place by default yet. M ./Distribution/Simple/Install.hs -2 +4 M ./Distribution/Simple/NHC.hs -1 +31

1 0

patch applied (cabal): Library archive creation for nhc98
by Duncan Coutts 27 Nov '07

27 Nov '07

Tue Nov 27 09:40:17 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Library archive creation for nhc98 So far only for vanilla not profiling libs. M ./Distribution/Simple/NHC.hs -6 +60

1 0

Re: suggestion: add a .ehs file type
by Simon Marlow 27 Nov '07

27 Nov '07

Alex Jacobson wrote: > > Simon, from what I can tell, with GHC 6.8.1, use of foreign as a > function name or forall as a type variable or leaving out a space in a > list-comprehension doesn't "parse differently" when the relevant > extensions are enabled, it causes a parse error. > > Extensions allow the same code to parse but with different meanings need > to be declared explicitly. But, extensions that are obvious from syntax > should be allowed to be declared simply from the use of that syntax. So for the first example I gave, f x y = x 3# y the "MagicHash" extension is one that you'd require to be explicitly declared, because the expression parses both with and without the extension. Now, Let's take the Template Haskell example: f x = [d|d<-xs] So this is valid Haskell 98, but invalid H98+TH. You would therefore like this example to parse unambiguously as H98, correct? But in order to do that, our parser would need arbitrary lookahead: it can't tell whether the expression is legal H98+TH until it gets to the '<-' in this case. Certainly it's possible to implement this using a backtracking parser, but Haskell is supposed to be parsable with a shift-reduce parser such as the one GHC uses. Or we could try parsing the whole module with various combinations of extensions turned on or off, but I'm sure you can see the problems with that. So basically the problem is that you need a parser that parses a strict superset of Haskell98 - and that's hard to achieve. Cheers, Simon > I am not taking a position here on the merits of any extensions. > > -Alex- > > > Simon Marlow wrote: >> Alex Jacobson wrote: >> >>> Extensions that change syntax are effectively declared by the use of >>> that syntax. If you can parse the source, then you know which >>> extensions it uses. >> >> I thought we'd already established that this isn't possible. Here are >> some code fragments that parse differently depending on which >> extensions are enabled: >> >> f x y = x 3# y >> >> f x = [d|d<-xs] >> >> foreign x = x >> >> f :: forall -> forall -> forall >> >> You could argue that these syntax extensions are therefore badly >> designed, but that's a separate discussion. >> >> Cheers, >> Simon >> >>> -Alex- >>> >>> >>> Duncan Coutts wrote: >>>> On Fri, 2007-11-23 at 16:26 +0100, Wolfgang Jeltsch wrote: >>>>> Am Freitag, 23. November 2007 03:37 schrieben Sie: >>>>>> On Fri, 2007-11-23 at 01:50 +0100, Wolfgang Jeltsch wrote: >>>>>>> Dont’t just think in terms of single modules. If I have a Cabal >>>>>>> package, >>>>>>> I can declare used extensions in the Cabal file. A user can >>>>>>> decide not >>>>>>> to start building at all if he/she sees that the package uses an >>>>>>> extension unsupported by the compiler. >>>>>> Indeed. In theory Cabal checks all the extensions declared to be >>>>>> used by >>>>>> the package are supported by the selected compiler. In practise >>>>>> I'm not >>>>>> sure how well it does this or what kind of error message we get. >>>> >>>>> The problem is, of course, that you are not forced to specify all >>>>> used extensions in the Cabal file since you can still use language >>>>> pragmas. Sometimes it is even desirable to use LANGUAGE pragmas >>>>> instead of information in the Cabal file. For example, even if >>>>> some modules use undecidable instances, I might not want all >>>>> modules of the package to be compiled with -XUndecidableInstances >>>>> since this could hide problems with my class structure. >>>> >>>> Our tentative plan there is to separate the extensions field into those >>>> used in some module, and those applied by cabal to every module. So >>>> that >>>> would allow you to specify a feature in one file but not all, while >>>> still declaring to the outside world that the package uses the feature. >>>> >>>> As for enforcing that, that may come almost for free when we get >>>> dependency chasing as we'll be looking for imports anyway. It shouldn't >>>> be much harder to look for language pragmas too. >>>> >>>> Duncan >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> > >

1 0

portability and .cabal files?
by Claus Reinke 26 Nov '07

26 Nov '07

how is portability (meant to be) documented in .cabal files? the only thing i can find in Cabal/authors.html are 'os()' and 'arch()', but those are tests, rather than dependency fields. should .cabal files for non-portable packages consist of a big if with the tested and known-to-work os/arch combinations as test and an empty else-branch for unknown/untested/known-to-fail combinations? shouldn't hackage display portability of its packages? if i look through the system-dependent packages on hackage, hardly any of them indicate their platform limitations anywhere but in free-form comments and module names, so if you wanted to filter packages by supported platforms, you'd be stuck.. claus

5 10

patch applied (cabal): Escape some special characters
by Duncan Coutts 26 Nov '07

26 Nov '07

Mon Nov 26 08:32:53 PST 2007 Ian Lynagh <igloo(a)earth.li> * Escape some special characters M ./Distribution/Configuration.hs -1 +1 M ./Distribution/Simple.hs -1 +1

1 0

patch applied (cabal): Fix a broken link
by Duncan Coutts 26 Nov '07

26 Nov '07

Mon Nov 26 08:31:37 PST 2007 Ian Lynagh <igloo(a)earth.li> * Fix a broken link M ./Distribution/Simple/GHC.hs -1 +1

1 0

patch applied (cabal): Escape some special characters in the haddock docs
by Duncan Coutts 26 Nov '07

26 Nov '07

Mon Nov 26 07:51:45 PST 2007 Ian Lynagh <igloo(a)earth.li> * Escape some special characters in the haddock docs M ./Distribution/Simple/PreProcess.hs -2 +2

1 0

patch applied (cabal): Fix what looks like a doc braino
by Duncan Coutts 26 Nov '07

26 Nov '07

Mon Nov 26 07:48:24 PST 2007 Ian Lynagh <igloo(a)earth.li> * Fix what looks like a doc braino M ./Distribution/Simple/InstallDirs.hs -1 +1

1 0

patch applied (cabal): Put nhc98 .hi files in the target dir rather than the src dir
by Duncan Coutts 26 Nov '07

26 Nov '07

Mon Nov 26 16:38:00 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Put nhc98 .hi files in the target dir rather than the src dir So they end up next to the .o files under dist/ just like for ghc. M ./Distribution/Simple/NHC.hs -5 +5

1 0