- cabal-devel - Haskell.org

patch applied (cabal-branches/cabal-1.2): Escape some special characters in the haddock docs
by Ian Lynagh 27 Nov '07

27 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-branches/cabal-1.2): Fix what looks like a doc braino
by Ian Lynagh 27 Nov '07

27 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

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

26 Nov '07

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

Re: suggestion: add a .ehs file type
by Duncan Coutts 24 Nov '07

24 Nov '07

On Fri, 2007-11-23 at 14:59 -0500, Alex Jacobson wrote: > Cabal is not a solution to this problem because > > 1. you want your code to work via ghci and runhaskell and perhaps via > searchpath. > > 2. you may want to move a module from one package to another and you > don't want to have to examine the cabal file to figure out how to do > that. The source file should have enough information. I agree. I'd prefer to see the extensions field in the .cabal be just the union of the ones specified in LANGUAGE pragmas in the source files and not have the meaning of applying those extensions. So I'd like to see it become a declaration to the outside world about what extensions are needed to compile the package, not a way of applying extensions to all modules in the package. In practise for backwards compatibility we'll have to have both for the time being. Duncan

1 0

patch applied (cabal): Workaround import bug in nhc98
by Duncan Coutts 24 Nov '07

24 Nov '07

Fri Nov 23 13:00:09 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Workaround import bug in nhc98 Cabal can now build using itself and nhc98 M ./Distribution/Simple/SetupWrapper.hs -1 +1

1 0

patch applied (cabal): Add support for building libs and exes with nhc98 via hmake
by Duncan Coutts 24 Nov '07

24 Nov '07

Fri Nov 23 12:57:50 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Add support for building libs and exes with nhc98 via hmake Doesn't do installation yet or check for existence of dependent packages. M ./Distribution/Simple/NHC.hs -26 +89 M ./Distribution/Simple/Program.hs -1 +9

1 0

Re: suggestion: add a .ehs file type
by Duncan Coutts 23 Nov '07

23 Nov '07

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

1 0

patch applied (cabal-branches/cabal-1.2): Fix finding ghc's ld.exe on windows.
by Ian Lynagh 22 Nov '07

22 Nov '07

Tue Nov 20 02:11:10 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Fix finding ghc's ld.exe on windows. It looks like it had worked but the ld -x test broke that too. Grr. M ./Distribution/Simple/GHC.hs -9 +9

1 0

patch applied (cabal-branches/cabal-1.2): Export PreProcessor constructor and mkSimplePreProcessor
by Ian Lynagh 22 Nov '07

22 Nov '07

Fri Nov 16 06:53:27 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Export PreProcessor constructor and mkSimplePreProcessor Otherwise it is impossible to declare new pre-processors in Setup.hs files M ./Distribution/Simple/PreProcess.hs -2 +2

1 0

patch applied (cabal-branches/cabal-1.2): Fix a bug in the Unlit pre-processor
by Ian Lynagh 22 Nov '07

22 Nov '07

Wed Oct 24 11:19:08 PDT 2007 David Waern <davve(a)dtek.chalmers.se> * Fix a bug in the Unlit pre-processor With this patch, unlit can handle line pragmas with filenames that contain spaces. M ./Distribution/Simple/PreProcess/Unlit.hs -2 +2

1 0