November 2007 - cabal-devel

patch applied (cabal): Stop using deprecated setup code in SetupWrapper
by Duncan Coutts 28 Nov '07

28 Nov '07

Tue Nov 20 08:14:35 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Stop using deprecated setup code in SetupWrapper M ./Distribution/Simple/SetupWrapper.hs -3 +2

1 0

patch applied (cabal): Add Command module to exposed-modules
by Duncan Coutts 28 Nov '07

28 Nov '07

Fri Nov 16 06:52:34 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Add Command module to exposed-modules M ./Cabal.cabal +1

1 0

patch applied (cabal): Add new Command abstraction for handling command line args
by Duncan Coutts 28 Nov '07

28 Nov '07

Fri Nov 16 06:12:25 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Add new Command abstraction for handling command line args Add instances of it for all existing Cabal commands. This should makes command line handling more regular and hopefully make it easier to override or make derived commands in cabal-install. So far we're only adding code, not modifying existing stuff except renaming some existing internal functions so they do not clash with the new code. A ./Distribution/Simple/Command.hs M ./Distribution/Simple/Setup.hs -13 +542

1 0

patch applied (cabal): Add emptyPFEFlags and emptySDistFlags for consistency
by Duncan Coutts 28 Nov '07

28 Nov '07

Fri Nov 16 05:56:25 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Add emptyPFEFlags and emptySDistFlags for consistency M ./Distribution/Simple/Setup.hs -2 +9

1 0

patch applied (cabal): Simplify parameters to defaultMain__
by Duncan Coutts 28 Nov '07

28 Nov '07

Fri Nov 16 05:23:23 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Simplify parameters to defaultMain__ Don't use maybe, just have the callers pass the defaults instead. Eliminate the Maybe PackageDescription parameter and instead just have the called override the readDesc in the UserHooks. This simplifies defaultMainWorker too as it can always just use readDesc. M ./Distribution/Simple.hs -28 +22

1 0

patch applied (cabal): Make scratchdir into a proper configure flag
by Duncan Coutts 28 Nov '07

28 Nov '07

Fri Nov 16 05:16:04 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Make scratchdir into a proper configure flag rather than using the flag extension mechanism. It was the old flag using it and I'm about to replace that whole system. M ./Distribution/Simple.hs -8 +3 M ./Distribution/Simple/Configure.hs -1 +2 M ./Distribution/Simple/Setup.hs +6

1 0

patch applied (cabal): Refactor: move UserHooks into it's own module
by Duncan Coutts 28 Nov '07

28 Nov '07

Wed Nov 14 07:06:59 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Refactor: move UserHooks into it's own module M ./Cabal.cabal +1 M ./Distribution/Simple.hs -158 +2 A ./Distribution/Simple/UserHooks.hs

1 0

patch applied (cabal): Tidy up args in the pfe, clean, haddock and hscolour default hooks
by Duncan Coutts 28 Nov '07

28 Nov '07

Wed Nov 14 07:01:31 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Tidy up args in the pfe, clean, haddock and hscolour default hooks Don't pass unnecessary args and inline trivial definitions M ./Distribution/Simple.hs -24 +8

1 0

[Fwd: GHC's CPP and Cabal's unlit]
by Duncan Coutts 28 Nov '07

28 Nov '07

-------- Forwarded Message -------- > From: Alistair Bayley <alistair(a)abayley.org> > To: glasgow-haskell-users(a)haskell.org, libraries(a)haskell.org > Subject: GHC's CPP and Cabal's unlit > Date: Wed, 28 Nov 2007 10:59:25 +0000 > > I'm doing some testing with GHC 6.6.1 and Cabal 1.3, and I'm trying to > figure out what happens with CPP and Cabal's unlit. > > I start with file Test.lhs: > > > {-# OPTIONS -fglasgow-exts #-} > > module Test where > > main = putStrLn "hello CPP" > > and run command: > ghc -E -x hs -cpp Test.lhs -o Test2.lhs > > which gives me Test2.lhs: > > {-# LINE 1 "Test.lhs" #-} > # 1 "Test.lhs" > # 1 "<built-in>" > # 1 "<command line>" > # 1 "Test.lhs" > > {-# OPTIONS -fglasgow-exts #-} > > module Test where > > main = putStrLn "hello CPP" > > > So I'm wondering: where does the {-# LINE #-} comment come from, and > also the # 1 lines? AFAICT the # 1 lines are ignored by GHC; I can > compile Test2.lhs without errors. Is there anything in GHC's docs > about this? > > More puzzling is that the files that Cabal runs through ghc's CPP > don't get the # n lines, so we end up with something like this: > > {-# LINE 1 "Test.lhs" #-} > > {-# OPTIONS -fglasgow-exts #-} > > module Test where > > main = putStrLn "hello CPP" > > which is not a valid .lhs file, because we have a code line next to a comment. > > I also note in Cabal the haddock command runs CPP before unlit. GHC > does it the other way around i.e. run unlit first then CPP, and I'm > wondering if Cabal shouldn't do the same thing? > > Thanks, > Alistair > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

1 0

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

28 Nov '07

I see, all you're saying is you'd like the default to be different. (That's not the same as saying "Extensions that change syntax are effectively declared by the use of that syntax", which is what you said earlier, BTW.) Well, we could change the default. I don't think it's a great idea personally - I think we should default to compiling whatever is the most recent standard, i.e. Haskell 98. But you're arguing that the proportion of Haskell 98 code that would fail to compile is relatively small; that might well be true. This isn't a decision we could take lightly, though. Furthermore, it's only something we could change in 6.10, by which time it is likely that we'll have a clearer idea of what Haskell' is, so there might well be a -fhaskell-prime flag (or it might even be the default). Cheers, Simon Alex Jacobson wrote: > > Simon, I think we've been trying to be too clever... > > The simple question is: for a given extension, what is the risk of > leaving it turned on by default? > > Clearly we don't want extensions turned on that causes code to compile > but with a different meaning. We may not want extensions turned on that > cause most reasonable code not to compile. > > But I would say neither risk is significant in the case of most > extensions. To use your examples: > > * FFI doesn't not cause h98 code to compile to a different meaning. The > worst case is that code that uses 'foreign' as a function name doesn't > compile. That seems okay in that more code probably uses FFI than uses > foreign as a function name and the user can apply a language pragma to > turn it off if really desired. > > * Existential types won't cause h98 code to compile with a different > meaning. The worst case is that code that uses 'forall' as a type > variable won't compile. That seems ok.... > > * TemplateHaskell also not compatible with h98. The worst case is the > loss "[d|" in list comprehensions. > > * MagicHash: Does not appear in the ToC or the Index of the user's guide > so should probably be turned off. I have no idea what it does. > > Note, in all cases where the extension is turned on by default, there > should be a language pragma to turn it off. > > > -Alex- > > Simon Marlow wrote: >> 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