Re: suggestion: add a .ehs file type
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. Extensions that change the interpretation of an already valid haskell source file really need to be declared explicitly e.g. undecidableinstances. 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. -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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.8.1 port on FreeBSD-amd64?
As I have got an amd64 machine again, I am returning to my previous porting effort. When I try to build to .hc files on i386 system, I get the following error: ... gmake[2]: Entering directory `/usr/home/wb/ghc-6.8.1/libraries/unix' ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include HsUnix.h -#include execvpe.h -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi Prologue junk?: .type s32x_ret, @function s32x_ret: pushl %ebp movl%esp, %ebp ghc: 114363808 bytes, 9 GCs, 2951168/5799936 avg/max bytes residency (2 samples), 33M in use, 0.00 INIT (0.00 elapsed), 0.78 MUT (2.33 elapsed), 0.20 GC (0.23 elapsed) :ghc gmake[2]: *** [dist/build/System/Posix/Process.o] Fehler 255 gmake[2]: Leaving directory `/usr/home/wb/ghc-6.8.1/libraries/unix' gmake[1]: *** [make.library.unix] Fehler 2 gmake[1]: Leaving directory `/usr/home/wb/ghc-6.8.1/libraries' gmake: *** [stage1] Fehler 2 which I don't understand at all. The build of ghc-6.8.1 for native use on a FreeBSD-6.2 i386 did not cause any problems. Perhaps someone else has done the porting work already. Please give me a note, if anybody is able to provide me a set of files to get the bootstrap further. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Ok, added as a feature request. http://hackage.haskell.org/trac/ghc/ticket/1921#preview Simon Peyton-Jones wrote: | So, my suggestion is that in any case where the compiler currently | suggests use of a particular pragma in an error message, it should | instead turn that pragma on and produce a warning. In the cases where the compiler makes that suggestion, yes what you suggest would be feasible I think. But it would be patchy and ad hoc -- often the compiler would do the right thing (at least as you see it), but sometimes not. Nevertheless, patchy and ad-hoc solutions are sometimes very convenient. I certainly agree that messages of the form bad programmer, you clearly meant X but you didn't *write* X; so go write X and then I'll compile your program are tiresome. Why not make it a feature request and try to get people to vote for it (by adding themselves to the cc list and/or adding comments)? Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
