From bulat.ziganshin at gmail.com Wed Nov 1 02:42:49 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 1 03:01:20 2006 Subject: [Hugs-users] Record puns, time for removal? In-Reply-To: <5ab17e790610311106h2da03268i12f0865c24ce34de@mail.gmail.com> References: <404396ef0610270857v23da104bmad3299563440aab3@mail.gmail.com> <8F85FE95-5C5A-4777-8F43-3A45F05FDCDF@comcast.net> <036EAC76E7F5EC4996A3B3C3657D4116070D5BF4@EUR-MSG-21.europe.corp.microsoft.com> <20061031003042.GD28257@momenergy.repetae.net> <20061030195747.89a445e2.seth@cql.com> <404396ef0610301704ya26851cu3ceeccebe6034c6@mail.gmail.com> <1511496422.20061031135945@gmail.com> <20061031082155.56b692c0.seth@cql.com> <5ab17e790610311106h2da03268i12f0865c24ce34de@mail.gmail.com> Message-ID: <843147467.20061101104249@gmail.com> Hello Iavor, Tuesday, October 31, 2006, 10:06:01 PM, you wrote: > By the way, if I recall correctly, in Johan Nordlander's O'Hugs the .. > notation (called record packing, I think) could also be used to create > record values. I think it worked like this: >> data Point = Point { x,y :: Int } >> pt = let { x = 3; y = 4 } in Point { .. } > The ".." is expanded to "{x = x, y = y}" based on the fields for the > particular constructor. It seems that if we have the "Point { .. }" > pattern, we should also have the constructor version. What do people > think? yes, yes, yes! definitely! i'll just show my code: parseCmdline cmdline = do ..... return$ Just$ Command { cmd_name = cmd , cmd_arcspec = arcspec , cmd_arclist = error "Using uninitialized cmd_arclist" , cmd_arcname = error "Using uninitialized cmd_arcname" , cmd_arc_filter = const True , cmd_filespecs = filespecs , cmd_added_arcnames = return [] , cmd_diskfiles = return [] , cmd_subcommand = False , opt_scan_subdirs = scan_subdirs , opt_add_dir = add_dir , opt_arc_basedir = arc_basedir , opt_disk_basedir = disk_basedir , opt_group_dir = group_dir , opt_group_data = group_data , opt_data_compressor = data_compressor , opt_dir_compressor = dir_compressor , opt_include_dirs = include_dirs , opt_indicator = indicator , opt_overwrite = overwrite , opt_keep_time = keep_time , opt_time_to_last = time_to_last , opt_test = test_files , opt_keep_broken = keep_broken , opt_match_with = match_with , opt_append = append , opt_recompress = recompress , opt_noarcext = noarcext , opt_nodir = nodir , opt_debug = debug , opt_cache = cache , opt_update_type = update_type , opt_x_include_dirs = x_include_dirs , opt_match_excluded = match_excluded , opt_sort_order = sort_order , opt_find_group = find_group . fiFilteredName , opt_groups_count = length group_strings , opt_find_type = find_type . fiFilteredName , opt_types_count = maximum group_types + 1 , opt_arccmt_file = arccmt_file , opt_lock_archive = lock_archive , opt_sfx = sfx , ref_ask_overwrite = ref_ask_overwrite } -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Nov 1 02:42:49 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 1 03:10:35 2006 Subject: [Hugs-users] Record puns, time for removal? In-Reply-To: <5ab17e790610311106h2da03268i12f0865c24ce34de@mail.gmail.com> References: <404396ef0610270857v23da104bmad3299563440aab3@mail.gmail.com> <8F85FE95-5C5A-4777-8F43-3A45F05FDCDF@comcast.net> <036EAC76E7F5EC4996A3B3C3657D4116070D5BF4@EUR-MSG-21.europe.corp.microsoft.com> <20061031003042.GD28257@momenergy.repetae.net> <20061030195747.89a445e2.seth@cql.com> <404396ef0610301704ya26851cu3ceeccebe6034c6@mail.gmail.com> <1511496422.20061031135945@gmail.com> <20061031082155.56b692c0.seth@cql.com> <5ab17e790610311106h2da03268i12f0865c24ce34de@mail.gmail.com> Message-ID: <843147467.20061101104249@gmail.com> Hello Iavor, Tuesday, October 31, 2006, 10:06:01 PM, you wrote: > By the way, if I recall correctly, in Johan Nordlander's O'Hugs the .. > notation (called record packing, I think) could also be used to create > record values. I think it worked like this: >> data Point = Point { x,y :: Int } >> pt = let { x = 3; y = 4 } in Point { .. } > The ".." is expanded to "{x = x, y = y}" based on the fields for the > particular constructor. It seems that if we have the "Point { .. }" > pattern, we should also have the constructor version. What do people > think? yes, yes, yes! definitely! i'll just show my code: parseCmdline cmdline = do ..... return$ Just$ Command { cmd_name = cmd , cmd_arcspec = arcspec , cmd_arclist = error "Using uninitialized cmd_arclist" , cmd_arcname = error "Using uninitialized cmd_arcname" , cmd_arc_filter = const True , cmd_filespecs = filespecs , cmd_added_arcnames = return [] , cmd_diskfiles = return [] , cmd_subcommand = False , opt_scan_subdirs = scan_subdirs , opt_add_dir = add_dir , opt_arc_basedir = arc_basedir , opt_disk_basedir = disk_basedir , opt_group_dir = group_dir , opt_group_data = group_data , opt_data_compressor = data_compressor , opt_dir_compressor = dir_compressor , opt_include_dirs = include_dirs , opt_indicator = indicator , opt_overwrite = overwrite , opt_keep_time = keep_time , opt_time_to_last = time_to_last , opt_test = test_files , opt_keep_broken = keep_broken , opt_match_with = match_with , opt_append = append , opt_recompress = recompress , opt_noarcext = noarcext , opt_nodir = nodir , opt_debug = debug , opt_cache = cache , opt_update_type = update_type , opt_x_include_dirs = x_include_dirs , opt_match_excluded = match_excluded , opt_sort_order = sort_order , opt_find_group = find_group . fiFilteredName , opt_groups_count = length group_strings , opt_find_type = find_type . fiFilteredName , opt_types_count = maximum group_types + 1 , opt_arccmt_file = arccmt_file , opt_lock_archive = lock_archive , opt_sfx = sfx , ref_ask_overwrite = ref_ask_overwrite } -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Wed Nov 1 04:10:44 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 1 04:10:44 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <20061030051714.GI2239@momenergy.repetae.net> References: <20061005135618.1ADCD3242DE@www.haskell.org><45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> The thread about "stand-alone" deriving is long-ish now, so I have summarised the issues here: http://haskell.org/haskellwiki/GHC/StandAloneDeriving Perhaps those who are interested can add their thoughts? Bjorn is busy at the moment, but I think he'll get back to the implementation in a while, so now is a good time to refine the design. I've tried to note all the issues that came up by email, but I might have missed. I put it on the GHC wiki, because I'm not proposing it for Haskell'. (Someone else is free to do so, of course.) Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | John Meacham | Sent: 30 October 2006 05:17 | To: haskell-prime@haskell.org | Subject: Re: Proposal for stand-alone deriving declarations? | | On Fri, Oct 06, 2006 at 10:39:39AM -0500, Michael Shulman wrote: | > On 10/6/06, John Hughes wrote: | > >deriving (Eq Foo, Ord Foo) | > > | > >instead of | > > | > >deriving (Eq, Ord) for Foo | > | > So what does | > | > newtype Foo a = Foo a | > newtype Bar b = Bar b | > class C a b | > deriving (C (Foo a) (Bar b)) | > | > mean? I could see it meaning any or all of the following: | > | > instance (C (Foo a) b) => (C (Foo a) (Bar b)) | > instance (C a (Bar b)) => (C (Foo a) (Bar b)) | > instance (C a b) => (C (Foo a) (Bar b)) | | | this is why we should make this explicit when deriving "complex" newtype | instances, so we would write exactly the instance we want to derive: | | > deriving (C (Foo a) b) => (C (Foo a) (Bar b)) | > deriving (C a (Bar b)) => (C (Foo a) (Bar b)) | > deriving (C a b) => (C (Foo a) (Bar b)) | | respectively. | | John | | -- | John Meacham - ?repetae.net?john? | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime From simonpj at microsoft.com Wed Nov 1 05:21:57 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 1 05:22:16 2006 Subject: instance Data (Complex a) In-Reply-To: References: Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160712FE83@EUR-MSG-21.europe.corp.microsoft.com> I've added 'deriving Data' to Complex. (There are probably other missing ones too...let us know.) S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] | On Behalf Of Chad Scherrer | Sent: 26 October 2006 19:08 | To: GHC Users | Subject: instance Data (Complex a) | | I was playing around with the Data.Generics stuff, and I'm getting an | error that says | | No instance for (Data (Complex Double)) | | Looking at the source for Data.Complex, I see it is an instance of | Typeable, but not of Data. Is there a reason not to add "deriving | Data" on the end of this? | | Thanks, | Chad | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From maeder at tzi.de Wed Nov 1 05:31:25 2006 From: maeder at tzi.de (Christian Maeder) Date: Wed Nov 1 05:31:18 2006 Subject: ANNOUNCE: GHC version 6.6 for PC-Solaris In-Reply-To: <20061011130020.GA11286@matrix.chaos.earth.li> References: <20061011130020.GA11286@matrix.chaos.earth.li> Message-ID: <4548777D.4050506@tzi.de> Herewith I announce a binary distribution for PCs under Solaris 10. http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/versions/ghc-6.6-i386-unknown-solaris2.tar.bz2 It's only a prototypical distribution that has been created without a threaded rts and without object-code splitting (SplitObjs=No in mk/build.mk) But this ghc is able to build large projects and ghci is working for our students. Although our hardware supports also the amd64 instruction set architecture (isa), the binary distribution uses the i386 isa. So there is room for improvement, volunteers are welcome. The build includes (html) documentation and the usual extra libraries. Cheers Christian -bash-3.1$ uname -a SunOS z01 5.10 Generic_118855-19 i86pc i386 i86pc -bash-3.1$ ldd ghc-6.6 libdl.so.1 => /lib/libdl.so.1 libreadline.so.5 => /usr/local/lib/libreadline.so.5 libncurses.so.5 => /usr/local/lib/libncurses.so.5 libm.so.2 => /lib/libm.so.2 libgmp.so.3 => /usr/local/lib/libgmp.so.3 librt.so.1 => /lib/librt.so.1 libc.so.1 => /lib/libc.so.1 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libaio.so.1 => /lib/libaio.so.1 libmd5.so.1 => /lib/libmd5.so.1 libmp.so.2 => /lib/libmp.so.2 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 From maeder at tzi.de Thu Nov 2 04:01:25 2006 From: maeder at tzi.de (Christian Maeder) Date: Thu Nov 2 04:01:16 2006 Subject: ghc-testsuite-6.6 on Macs (Intel) In-Reply-To: <45476C12.9080807@tzi.de> References: <45476C12.9080807@tzi.de> Message-ID: <4549B3E5.7060306@tzi.de> Christian Maeder schrieb: > Did someone run the test-suite of the binary distributions? > http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 This distribution on our MacIntel produced the following summary in a newly made ghc-6.6 sources tree with TEST_HC=": OVERALL SUMMARY for test run started at Wed Nov 1 18:06:39 CET 2006 1455 total tests, which gave rise to 6918 test cases, of which 0 caused framework failures 1178 were skipped 5660 expected passes 56 expected failures 0 unexpected passes 24 unexpected failures Unexpected failures: conc019(normal,optasm,prof,profasm) conc024(prof,profasm) conc049(optasm) ffi009(threaded1) ffi012(normal,opt,optasm,prof,profasm,ghci,threaded1,threaded2) ffi016(normal,opt,optasm) ghcpkg01(normal) ghcpkg03(normal) memo001(threaded1) net001(threaded2) signals002(ghci) conc019 failed with: caught: thread blocked indefinitely and con024: thread blocked indefinitely From clemens at endorphin.org Thu Nov 2 08:11:31 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Thu Nov 2 08:11:53 2006 Subject: Failed OccName lookup in RnEnv with Template Haskell Hack Message-ID: <877iyexabg.wl%clemens@endorphin.org> I have written a set of function that generates hsSyn data structures, in particular HsExpr. I want run these functions at compile time, so it can generate user code. I do this via Template Haskell and an ugly hack in TH. TcSplice.lhs expects an ExpQ monad as result for splice expressions. I hesitate to rewrite my functions to generate a TH.Exp hierarchy instead of a (HsExpr RdrName) hierarchy. The hack is to extend TH.Exp with a new constructor InternalE (HsExpr RdrName) and to add a pattern to hsSyn/Convert.lhs in ctvl :: TH.Exp -> CvtM (LHsExpr RdrName) cvt (InternalE expr) = return expr This effectively percises the whole TH.Exp -> HsExpr conversion by providing a Exp constructor with a HsExpr payload, and extending the conversion to just unwrap this payload. This enables me to hand HsExpr to the compiler via Template Haskell via this elegant ugly hack: foobar = $(return (InternalE References: <453CC2D5.4080107@imn.htwk-leipzig.de> Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160718AF88@EUR-MSG-21.europe.corp.microsoft.com> Johannes Thanks for the summary. Concerning some specific points: | when "ghc --make" finds a source file that starts wrongly | (e. g. "modul Foo" instead of "module Foo") | (might occur from unobserved CVS merge conflicts) it just says | | : file name does not match module name `Main' | | and it is quite impossible to find out which file is to blame That is terrible. I have fixed it. | In some places I found it convenient to write type decls like | | foo ( x :: a ) ( y :: [ b ] ) = ... | | because this gave me at least some kind of documentation | while I was too lazy to figure out all the type class requirements Yes, this whole scoped type variable thing is far from settled. | the "coverage condition not satisfied" error message | (with functional dependencies) should include a hint | that "-fallow-undecidable-instances" might help. Good idea. I've done that. | library changes: | | Network.CGI is new, but we have Network.CGI.Compat. | Which however refers to Text.XHtml, not Text.Html, | so I had to change these imports as well. Ian: should we update the release notes abou this? Simon From mattcbro at earthlink.net Thu Nov 2 21:54:27 2006 From: mattcbro at earthlink.net (SevenThunders) Date: Thu Nov 2 21:54:13 2006 Subject: Memory leak in FFI callback: GHC 6.6 Message-ID: <7150757.post@talk.nabble.com> I'm not sure if this is a bug, but it sure seems that way to me. When using the "wrapper" technique for creating a Haskell callback function it seems that freeHaskellFunPtr is not properly freeing the resource. Here is an example program module Main where import Foreign import Foreign.Ptr import Foreign.Storable -- | A convenient type synonym for storable arrays type Darr = Ptr (Double) -- | Function type for mapping doubles to doubles type Dfunc = Double -> Double -- | A convenient type synonym for monad containing storable arrays type IODarr = IO (Darr) foreign import ccall "wrapper" mkDfunc :: Dfunc -> IO (FunPtr Dfunc) foreign import ccall "cleaky.h cfunc" cfunc :: (FunPtr Dfunc) -> IO ( Double ) dadd :: Dfunc dadd x = x + 1.0 getleaky :: Dfunc -> IO () getleaky cf = do pcf <- mkDfunc cf -- pd <- cfunc pcf print pcf freeHaskellFunPtr pcf main = sequence_ [getleaky dadd | q <- [1..500000]] It's compiled with ghc -fglasgow-exts -fffi -prof -auto -I. --make leaky.hs cleaky.o A possible cleaky.c and cleaky.h are #include #include #include "cleaky.h" double state = 1.0 ; double cfunc(DFptr fptr) { // printf("In cfunc, fptr: %p\n", fptr) ; state = (*fptr) (state) ; // printf("state: %g\n", state) ; return(state) ; } typedef double (*DFptr) (double) ; double cfunc(DFptr) ; though they are not used. leaky.exe grows the heap linearly without bound on windows XP 64. The profiler never reports this correctly either. calling leaky +RTS -hc -RTS does not show the increase in the memory usage. -- View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6-tf2565446.html#a7150757 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From simonpj at microsoft.com Fri Nov 3 03:57:49 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 3 03:58:16 2006 Subject: Memory leak in FFI callback: GHC 6.6 In-Reply-To: <7150757.post@talk.nabble.com> References: <7150757.post@talk.nabble.com> Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116071C8CE4@EUR-MSG-21.europe.corp.microsoft.com> Dear SevenThunders (if that is how you like to addressed) Thanks for extracting a small program that exhibits the leak; that is really helpful. We'll look into it. Would you like to create a Trac bug and attach your files? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] | On Behalf Of SevenThunders | Sent: 03 November 2006 02:54 | To: glasgow-haskell-users@haskell.org | Subject: Memory leak in FFI callback: GHC 6.6 | | | I'm not sure if this is a bug, but it sure seems that way to me. When using | the "wrapper" technique for creating a Haskell callback function it seems | that freeHaskellFunPtr is not properly freeing the resource. | | Here is an example program | | module Main where | import Foreign | import Foreign.Ptr | import Foreign.Storable | | -- | A convenient type synonym for storable arrays | type Darr = Ptr (Double) | -- | Function type for mapping doubles to doubles | type Dfunc = Double -> Double | -- | A convenient type synonym for monad containing storable arrays | type IODarr = IO (Darr) | | | foreign import ccall "wrapper" mkDfunc :: Dfunc -> IO (FunPtr Dfunc) | foreign import ccall "cleaky.h cfunc" cfunc :: (FunPtr Dfunc) -> IO ( Double | ) | | | dadd :: Dfunc | dadd x = x + 1.0 | | getleaky :: Dfunc -> IO () | getleaky cf = do | pcf <- mkDfunc cf | -- pd <- cfunc pcf | print pcf | freeHaskellFunPtr pcf | | | main = sequence_ [getleaky dadd | q <- [1..500000]] | | | It's compiled with | ghc -fglasgow-exts -fffi -prof -auto -I. --make leaky.hs cleaky.o | | A possible cleaky.c and cleaky.h are | #include | #include | #include "cleaky.h" | | | double state = 1.0 ; | | double cfunc(DFptr fptr) | { | // printf("In cfunc, fptr: %p\n", fptr) ; | state = (*fptr) (state) ; | // printf("state: %g\n", state) ; | return(state) ; | } | | typedef double (*DFptr) (double) ; | double cfunc(DFptr) ; | | though they are not used. | | leaky.exe grows the heap linearly without bound on windows XP 64. The | profiler never reports this correctly either. | calling | leaky +RTS -hc -RTS | does not show the increase in the memory usage. | | -- | View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6- | tf2565446.html#a7150757 | Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Fri Nov 3 04:51:50 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 3 04:51:39 2006 Subject: Failed OccName lookup in RnEnv with Template Haskell Hack In-Reply-To: <877iyexabg.wl%clemens@endorphin.org> References: <877iyexabg.wl%clemens@endorphin.org> Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116071C8DBC@EUR-MSG-21.europe.corp.microsoft.com> | The problem is that the RdrNames carried in the HsExpr are not found | in the Renamer environment. To give you an example | | foobar = | $(return (InternalE (HsVar (mkUnqual varName | (mkFastString "myfoo"))))) | | which should in the overall result "foobar = myfoo" | | Running this gives me a "Not in scope" error but the myfoo variable is | obviously in the global environment as running this with | -ddump-rn-trace shows: Well that is indeed puzzling, but you are doing something quite tricky here. In TH, a TH splice uses only data types and functions declared in the TH library. But your splices use data types declared in GHC itself. I'm not quite sure how you make the compilation and linking stuff work out, but you certainly need to take great care that the TH splice code is uses the same data types, compiled in the same way, as the compiler it's linked with. Yes, it's hard to think about; I don't have it fully paged in myself. So the ice is thin. I can't account for the behaviour you are seeing -- but I can't see how to help you more. Perhaps do the HsVar and VarE thing in the *same* expression (in a pair, say), and confirm that they do generate the same HsExpr. Then start tracing the global envt lookup and its results. Simon | | test.hs:49:7: | Not in scope: `myfoo{v}' | Global envt is: | [cut] | myfoo{v}: main:MyAdd.myfoo{v rI9} imported from MyAdd at test.hs:13:20-24 | [cut] | | In contrast, the TH variant works without any flaws: | | $(return (VarE (mkName "myfoo"))) | | I assert that the VarE variant and the InternalE variant are converted | to exactly the same HsExpr by hsSyn/Convert.lhs. Using -ddump-slices | -dppr-debug shows that both splices generate "myfoo{v}". | | Using a few more hacks, I even made sure that the printed FastStrings | "myfoo" are equal in terms of "getKey# (getUnique str)", this pretty | much rules out a bug in UniqFM.hs. | | Does anyone (especially the developers that are intimate with TH and | HsSyn) know what could be the cause? I spent twelve fruitless hours | searching for the cause. | | Many thanks in advance, | --- | Fruhwirth Clemens - http://clemens.endorphin.org | for robots: sp4mtrap@endorphin.org | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From maeder at tzi.de Fri Nov 3 05:43:22 2006 From: maeder at tzi.de (Christian Maeder) Date: Fri Nov 3 05:43:06 2006 Subject: ghc-6.6 under sparc-sun-solaris In-Reply-To: <1161113730.24110.261.camel@localhost> References: <452E4305.9080806@tzi.de> <452F4099.6030600@tzi.de> <1160726495.24110.77.camel@localhost> <452F55E5.60203@tzi.de> <1160825329.24110.108.camel@localhost> <4534AD46.1050703@tzi.de> <1161113730.24110.261.camel@localhost> Message-ID: <454B1D4A.4080501@tzi.de> Duncan Coutts schrieb: > On Tue, 2006-10-17 at 12:15 +0200, Christian Maeder wrote: >> P.S. building under solaris requires over 2GB memory (and takes a day) It's only have half of this. I've mixed up "du -s" (showing Blocks) and "du -sh". My tree also included a binary-dist. -bash-3.00$ du -s 2266972 . -bash-3.00$ du -sh 1.1G . -bash-3.00$ cd ghc-6.6/ #this is the binary-dist only -bash-3.00$ du -sh 331M . > It takes 12 hours on my old 500Mhz sparc with 1GB ram. I know split-objs > takes lots of memory when building the archive, but 2GB seems excessive. Judging from the first and last created files (below) it took 9 hours on my machine: Model: Sun Fire 280R Memory Size (MB): 3072 Processor Speed (MHz): 900 -bash-3.00$ ll utils/mkdependC/mkdependC -rwxr-xr-x 1 maeder wimi 6057 Oct 20 16:54 utils/mkdependC/mkdependC -bash-3.00$ ll compiler/stage2/ghc-6.6 -rwxr-xr-x 1 maeder wimi 21069118 Oct 21 01:52 compiler/stage2/ghc-6.6 Cheers Christian fast 3:30 hours took: Hardware Architecture: pc Operating System: solaris10 Model: AMD Athlon-64 Memory Size (MB): 1024 Processor Speed (MHz): 2000 -bash-3.1$ ll utils/mkdependC/mkdependC -rwxr-xr-x 1 maeder wimi 6054 Nov 2 13:21 utils/mkdependC/mkdependC -bash-3.1$ ll compiler/stage2/ghc-6.6 -rwxr-xr-x 1 maeder wimi 20629720 Nov 2 16:49 compiler/stage2/ghc-6.6 From mattcbro at earthlink.net Fri Nov 3 14:03:51 2006 From: mattcbro at earthlink.net (SevenThunders) Date: Fri Nov 3 14:03:36 2006 Subject: Memory leak in FFI callback: GHC 6.6 In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D4116071C8CE4@EUR-MSG-21.europe.corp.microsoft.com> References: <7150757.post@talk.nabble.com> <036EAC76E7F5EC4996A3B3C3657D4116071C8CE4@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <7165550.post@talk.nabble.com> Simon Peyton-Jones wrote: > > Dear SevenThunders (if that is how you like to addressed) > > Thanks for extracting a small program that exhibits the leak; that is > really helpful. We'll look into it. Would you like to create a Trac bug > and attach your files? > > Simon > > > You can call me Matthew. The bug, if that's what it is, is now ticket number 985. By the way, why can't I get the callback to actually work in this example? If I for example uncomment the line -- pd <- cfunc pcf and say print out the value of pd, I get garbage values. Should I have used CDouble? I think for windows HsDouble = double in C land. -- View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6-tf2565446.html#a7165550 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From dgoldsmith at mac.com Fri Nov 3 18:14:42 2006 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Fri Nov 3 18:14:38 2006 Subject: Bad control characters in GHCi 6.6 (Mac OS X PPC) In-Reply-To: <51AD18AC-DE93-49A9-B218-34229B352F4C@mac.com> References: <8b2a1a960610181758p5b5256eexef125e695984bb35@mail.gmail.com> <2E9B33CE230409489A7ED37E5E34090F05C5206B@EUR-MSG-20.europe.corp.microsoft.com> <8b2a1a960610230859v5f09cc83j312e6257b292955a@mail.gmail.com> <51AD18AC-DE93-49A9-B218-34229B352F4C@mac.com> Message-ID: <519549F9-7C8D-48C3-9795-F0E0DC49E8FA@mac.com> On Oct 30, 2006, at 2:40 PM, Deborah Goldsmith wrote: > I think I have this partially figured out. The following patch to libraries/readline/configure.ac seems to do the trick for Darwin: --- configure.ac.save 2006-10-10 12:09:04.000000000 -0700 +++ configure.ac 2006-11-02 17:32:50.000000000 -0800 @@ -43,7 +43,10 @@ dnl ** is our readline really readline, or is it BSD's libedit? if test x"$HaveLibReadline" = xYES ; then - AC_CHECK_LIB(readline, rl_readline_version, ReadlineIsLibedit=NO, ReadlineIsLibedit=YES) + AC_CHECK_DECL(rl_readline_version, ReadlineIsLibedit=NO, ReadlineIsLibedit=YES, +[#include +#include +]) fi if test $HaveLibTermcap = YES && test x"$HaveLibReadline" = xYES && test x"$ReadlineIsLibedit" = xNO ; then @@ -56,9 +59,12 @@ AC_SUBST(READLINE_LIBS) if test x"$HaveLibReadline" = xYES && test x"$ReadlineIsLibedit" = xNO ; then - AC_CHECK_LIB(readline, rl_erase_empty_line, + AC_CHECK_DECL(rl_erase_empty_line, [AC_DEFINE([HAVE_READLINE_4], [1], [Define to 1 if readline has version >= 4.0.])], - [AC_DEFINE([HAVE_READLINE_4], [0], [Define to 1 if readline has version >= 4.0.])]) + [AC_DEFINE([HAVE_READLINE_4], [0], [Define to 1 if readline has version >= 4.0.])], +[#include +#include +]) AC_CHECK_LIB(readline, rl_free_undo_list, [AC_DEFINE([HAVE_READLINE_4_2], [1], [Define to 1 if readline has version >= 4.2.])], [AC_DEFINE([HAVE_READLINE_4_2], [0], [Define to 1 if readline has version >= 4.2.])]) When I build with this patch after configuring to look for GNU readline in /usr/local, everything works. I don't know if this particular patch will work well on other systems. Maybe folks could try it out? Thanks, Deborah From clemens at endorphin.org Sat Nov 4 03:44:27 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Sat Nov 4 03:44:41 2006 Subject: Failed OccName lookup in RnEnv with Template Haskell Hack In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D4116071C8DBC@EUR-MSG-21.europe.corp.microsoft.com> References: <877iyexabg.wl%clemens@endorphin.org> <036EAC76E7F5EC4996A3B3C3657D4116071C8DBC@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <87u01f61p0.wl%clemens@endorphin.org> At Fri, 3 Nov 2006 09:51:50 -0000, "Simon Peyton-Jones" wrote: > > | The problem is that the RdrNames carried in the HsExpr are not found > | in the Renamer environment. To give you an example > | > | foobar = > | $(return (InternalE (HsVar (mkUnqual varName > | (mkFastString "myfoo"))))) > | > | which should in the overall result "foobar = myfoo" > | > | Running this gives me a "Not in scope" error but the myfoo variable is > | obviously in the global environment as running this with > | -ddump-rn-trace shows: > > Well that is indeed puzzling, but you are doing something quite tricky > here. In TH, a TH splice uses only data types and functions declared in > the TH library. But your splices use data types declared in GHC itself. > I'm not quite sure how you make the compilation and linking stuff work > out, but you certainly need to take great care that the TH splice code > is uses the same data types, compiled in the same way, as the compiler > it's linked with. Yes, it's hard to think about; I don't have it fully > paged in myself. > > So the ice is thin. I can't account for the behaviour you are seeing -- > but I can't see how to help you more. Perhaps do the HsVar and VarE > thing in the *same* expression (in a pair, say), and confirm that they > do generate the same HsExpr. Then start tracing the global envt lookup > and its results. Nothing is more effective in blocking you to find a solution than broken a test case. I was creating thousands of FastStrings in the template haskell splice, I was even abusing conversion routings of the TH->HsSyn converted to create fast strings for me, but all fast strings I could ever possible create in a splice, (even with the help of the TH converter) would have been interned in linker environment of the splice! This is different from the compiler's linker environment. The data structures created by the splice are relinked into the compiler environment, but the FastStrings are incorrectly relinked. That is, they are not interned in the compilers FastString symbol table. That's not the linkers fault of course, as it can not know that creating a FastString has a side effect that must be redone in the environment it's linking to. I solved this problem partially for HsVar by recreating the FastStrings it contains via back-and-forth conversion to String. Of course, this is very cumbersome if I would have to do this for every FastString/OccName/RdrName that is contained in an HsExpr tree. Writting the tree traversal code is the exhausting part in this case, but maybe generics will save us one day. However, the best fix in my case is to lift the HsExpr generating function into the compiler. All FastStrings are now created in the proper environment. Thanks for your suggestions, Simon. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap@endorphin.org From mpchase at mac.com Sun Nov 5 10:23:39 2006 From: mpchase at mac.com (Melissa Chase) Date: Sun Nov 5 10:23:30 2006 Subject: Problem running X11 on PPC Mac Message-ID: <962D595B-A0A2-4C76-83A5-B47F4248F097@mac.com> I'm new to Haskell (and GHC) and am not sure if this is the appropriate place to post this (or if it should be reported as a bug). Yesterday I downloaded the binary build of 6.6 for the PPC Mac. I am running Mac OSX 10.4.8. I have XCode 2.4.1 and X11 1.1 installed. I was trying to get the graphics for SOE working and tried the first SimpleGraphics module. I used "import Graphics.SOE" and once I discovered that I had to set DYLD_LIBRARY_PATH to the X11 libraries (in /usr/X116/lib), the module loaded in ghci. When I tried to run main0, I got the following error message: Loading package X11-1.1 ... linking ... : /opt/local/lib/ghc-6.6/HSX11_cbits.o: unknown symbol `_printf$LDBLStub' ghc-6.6: unable to load package `X11-1.1' I ran nm on that object file and the symbol appears in it as undefined, and is not defined in any of the .o or .a files in the ghc lib directory. I subsequently built the DarwinPorts version of ghc 6.6 and have the same problem. Penny From dgoldsmith at mac.com Sun Nov 5 15:08:08 2006 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Sun Nov 5 15:07:57 2006 Subject: Problem running X11 on PPC Mac In-Reply-To: <962D595B-A0A2-4C76-83A5-B47F4248F097@mac.com> References: <962D595B-A0A2-4C76-83A5-B47F4248F097@mac.com> Message-ID: <248CB5AE-2CA1-4584-BE35-33BB8FCDEB02@mac.com> This problem pops up sometimes for all sorts of open source software (try Googling _printf$LDBLStub), and can be due to mixing modules compiled by gcc 3.3 and gcc 4.0, and/or due to failure to link with - lSystemStubs. I've had good luck using X11 with GHC if I launch it first, and run GHC from inside Xterm rather than Terminal. That way you don't need to fiddle with DYLD_LIBRARY_PATH. I haven't tried it on PPC, though, just Intel. I'll try it at work tomorrow. You might want to do "gcc_select" and see which version of gcc is the default on your system, though is likely not the issue since you had problems with the binary distribution. Deborah On Nov 5, 2006, at 7:23 AM, Melissa Chase wrote: > I'm new to Haskell (and GHC) and am not sure if this is the > appropriate place to post this (or if it should be reported as a > bug). Yesterday I downloaded the binary build of 6.6 for the PPC > Mac. I am running Mac OSX 10.4.8. I have XCode 2.4.1 and X11 1.1 > installed. > > I was trying to get the graphics for SOE working and tried the > first SimpleGraphics module. I used "import Graphics.SOE" and once > I discovered that I had to set DYLD_LIBRARY_PATH to the X11 > libraries (in /usr/X116/lib), the module loaded in ghci. When I > tried to run main0, I got the following error message: > > Loading package X11-1.1 ... linking ... : > /opt/local/lib/ghc-6.6/HSX11_cbits.o: unknown symbol `_printf > $LDBLStub' > ghc-6.6: unable to load package `X11-1.1' > > I ran nm on that object file and the symbol appears in it as > undefined, and is not defined in any of the .o or .a files in the > ghc lib directory. > > I subsequently built the DarwinPorts version of ghc 6.6 and have > the same problem. > > Penny > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Mon Nov 6 06:23:36 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 6 06:23:13 2006 Subject: Memory leak in FFI callback: GHC 6.6 In-Reply-To: <7165550.post@talk.nabble.com> References: <7150757.post@talk.nabble.com><036EAC76E7F5EC4996A3B3C3657D4116071C8CE4@EUR-MSG-21.europe.corp.microsoft.com> <7165550.post@talk.nabble.com> Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160722B118@EUR-MSG-21.europe.corp.microsoft.com> Matthew Thanks for submitting the Trac bug. I don't know what the answer to your qn below is, but maybe someone else on ghc-users does. Meanwhile, I added the qn to the bug report. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] | On Behalf Of SevenThunders | Sent: 03 November 2006 19:04 | To: glasgow-haskell-users@haskell.org | Subject: RE: Memory leak in FFI callback: GHC 6.6 | | | | Simon Peyton-Jones wrote: | > | > Dear SevenThunders (if that is how you like to addressed) | > | > Thanks for extracting a small program that exhibits the leak; that is | > really helpful. We'll look into it. Would you like to create a Trac bug | > and attach your files? | > | > Simon | > | > | > | | You can call me Matthew. The bug, if that's what it is, is now ticket | number 985. By the way, why can't I get the callback to actually work in | this example? If I for example uncomment the line | -- pd <- cfunc pcf | | and say print out the value of pd, I get garbage values. | | Should I have used CDouble? I think for windows HsDouble = double in C | land. | -- | View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6- | tf2565446.html#a7165550 | Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonmarhaskell at gmail.com Mon Nov 6 07:53:55 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Nov 6 07:53:48 2006 Subject: seq vs. pseq In-Reply-To: <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <454F3063.2070609@microsoft.com> Malcolm Wallace wrote: > Simon Marlow wrote: > > >>The difference is subtle. The semantics of seq and pseq are >>identical; however, GHC can see that seq is strict in both its >>arguments and hence could choose to evaluate them in either order, >>whereas pseq is only strict in its first argument as far as the >>strictness analyser is concerned. The point is that pseq is useful >>for controlling evaluation order, which is what you want for adding >>parallelism to a program. seq, on the other hand, is not useful for >>controlling evaluation order. > > This is a rather weird thing, and I would consider it a bug in the > Haskell Report, rather than a bug in ghc. (It bites hard when you are > trying to implement something like HPC.) > > The very name 'seq' surely suggests that you are controlling the > evaluation order. "Please evaluate this thing on the left first". But > that is _not_ what the Haskell Report says! Ghc takes the Report > literally, and so the thing on the right is just as likely to be > evaluated before the thing on the left! The report is in general very careful to say absolutely *nothing* about evaluation order, leaving the implementation free to choose, either at compile time or possibly even runtime. This is an important principle, and something I feel quite strongly should be kept at the front of our minds for Haskell Prime. If it isn't already mentioned explicitly in the Haskell 98 report, I think it should be. Incedentally, this is also one reason I think lazy I/O is a wart (despite its obvious usefulness): because it necessarily requires talking about evaluation order. However, having said all that, arguably an exception should be made in this case. The main use of seq (and strictness annotations) is to control operational behaviour, rather than to change the semantics of the program - for example, it is most often used to prevent space leaks by "evaluating something earlier than it would otherwise be" (inverted commas because this isn't currently what seq actually does, as pointed out above). Indeed, if GHC was in the habit of causing the second argument of seq to be evaluated before the first, then a lot of people would probably be surprised. eg. imagine what happens to foldl': foldl' f a [] = a foldl' f a (x:xs) = let a' = f a x in a' `seq` foldl' f a' xs It wouldn't do what you want at all. So I'm agreeing with Malcolm, except that I believe that the evaluation-order property of seq should be a strong hint, not a requirement - otherwise we fall into the trap of mandating evaluation order. Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Mon Nov 6 08:53:52 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Nov 6 08:55:17 2006 Subject: seq vs. pseq In-Reply-To: <454F3063.2070609@microsoft.com> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> Message-ID: <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow wrote: > The report is in general very careful to say absolutely *nothing* > about evaluation order, leaving the implementation free to choose, Yes, this is a highly desirable goal. > However, having said all that, arguably an exception should be made in > this case. The main use of seq (and strictness annotations) is to > control operational behaviour, rather than to change the semantics of > the program Indeed, `seq` is widely viewed as a wart on the language _because_ it specifies the evaluation order, which is something otherwise avoided in the Report. So the doubly bizarre thing is that, actually, `seq` does not control the evaluation order (which is the only valid reason for wanting to use it in the first place), but nevertheless it undesirably changes the semantics of programs such that equational reasoning no longer holds. I think if we are going to allow ourselves the luxury of semantic breakage, it should at least be worth the cost - we should get some real and definite operational control in return. That is why I think this: > the evaluation-order property of seq should be a strong hint, not a > requirement - otherwise we fall into the trap of mandating evaluation > order. is not strong enough. `seq` should guarantee sequential evaluation. If you want a strong (but not mandatory) hint to the compiler about strictness, than that should be a different construct at the user level. At the moment, these alternatives are named `pseq` and `seq`. One suggestion is just to reverse their sense. Another is to use bang patterns for hints. Another might be to introduce strictness hints in type signatures. Regards, Malcolm From simonmarhaskell at gmail.com Mon Nov 6 11:55:50 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Nov 6 11:55:27 2006 Subject: seq vs. pseq In-Reply-To: <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <454F6916.7060003@microsoft.com> Malcolm Wallace wrote: > Indeed, `seq` is widely viewed as a wart on the language _because_ it > specifies the evaluation order, which is something otherwise avoided in > the Report. I don't agree with that statement - the main problem with (polymorphic) seq is that its existence implies that the function type is lifted, which has wide-ranging ramifications. > So the doubly bizarre thing is that, actually, `seq` does not control > the evaluation order (which is the only valid reason for wanting to use > it in the first place), but nevertheless it undesirably changes the > semantics of programs such that equational reasoning no longer holds. > > I think if we are going to allow ourselves the luxury of semantic > breakage, it should at least be worth the cost - we should get some > real and definite operational control in return. > > That is why I think this: > >>the evaluation-order property of seq should be a strong hint, not a >>requirement - otherwise we fall into the trap of mandating evaluation >>order. > > is not strong enough. `seq` should guarantee sequential evaluation. If > you want a strong (but not mandatory) hint to the compiler about > strictness, than that should be a different construct at the user level. Not "strictness" - seq already provides that, we're talking about an operational property, that the language definition otherwise does not specify (I just want to be clear about terminology). GHC currently has seq and pseq; pseq guarantees sequential evaluation, seq does not. You want seq to have the pseq behaviour, and to specify this in the report (somehow - lacking any framework to describe operational properties this could only be an informal statement). This would have some undesirable consequences. In an expression like 'a `seq` b `seq` c', I bet in most cases the programmer would be happy for a and b to be evaluated in parallel, but you would require them to be evaluated in strict sequence. What's more, given this expression, the strictness analyser would only be able to infer that 'a' was used strictly, because if it also inferred b and c as strict then the simplifier might reorder the evaluations (normally reordering the evaluation of arguments to a strict function is perfectly ok). So lots of uses of seq to add strictness for performance would simply not work. Forcing seq to evaluate its arguments in strict sequence would be a really bad idea. For those (few) times when you really do want sequential ordering, for controlling parallelism, then we need pseq (call it something else if you want, I'm not fussy about names). Cheers, Simon From ross at soi.city.ac.uk Mon Nov 6 12:21:04 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 6 12:20:48 2006 Subject: seq vs. pseq In-Reply-To: <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20061106172104.GA8989@soi.city.ac.uk> On Mon, Nov 06, 2006 at 01:53:52PM +0000, Malcolm Wallace wrote: > So the doubly bizarre thing is that, actually, `seq` does not control > the evaluation order (which is the only valid reason for wanting to use > it in the first place), but nevertheless it undesirably changes the > semantics of programs such that equational reasoning no longer holds. When I've used seq, it's to ensure that a function is strict in that argument, and therefore has been evaluated before the function is called. (If the language had unlifted types, I might have used those instead). Beyond that, I don't care exactly when it was evaluated; it might be long before, thanks to propagation of strictness information. seq has a clear denotational semantics. One can still do equational reasoning with it, though there will be side conditions about whether something is _|_ or not. The downside is that the eta rules get such side conditions, and polymorphic seq greatly weakens parametricity. Apart from that, the only thing wrong with seq is its name. From seth at cql.com Mon Nov 6 13:28:27 2006 From: seth at cql.com (Seth Kurtzberg) Date: Mon Nov 6 12:58:31 2006 Subject: seq vs. pseq In-Reply-To: <20061106172104.GA8989@soi.city.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> <20061106172104.GA8989@soi.city.ac.uk> Message-ID: <2677.160.81.2.142.1162837707.squirrel@216.217.47.170> On Mon, November 6, 2006 9:21 am, Ross Paterson wrote: > On Mon, Nov 06, 2006 at 01:53:52PM +0000, Malcolm Wallace wrote: >> So the doubly bizarre thing is that, actually, `seq` does not control >> the evaluation order (which is the only valid reason for wanting to use >> it in the first place), but nevertheless it undesirably changes the >> semantics of programs such that equational reasoning no longer holds. > > When I've used seq, it's to ensure that a function is strict in that > argument, and therefore has been evaluated before the function is called. > (If the language had unlifted types, I might have used those instead). > Beyond that, I don't care exactly when it was evaluated; it might be > long before, thanks to propagation of strictness information. > > seq has a clear denotational semantics. One can still do equational > reasoning with it, though there will be side conditions about whether > something is _|_ or not. The downside is that the eta rules get such > side conditions, and polymorphic seq greatly weakens parametricity. > > Apart from that, the only thing wrong with seq is its name. What would be the correct way to get the effect that he expected from seq? > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- Seth Kurtzberg seth@cql.com Software Engineer Specializing in Reliability and Security From Malcolm.Wallace at cs.york.ac.uk Mon Nov 6 13:25:48 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Nov 6 13:28:53 2006 Subject: seq vs. pseq In-Reply-To: <20061106172104.GA8989@soi.city.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> <20061106172104.GA8989@soi.city.ac.uk> Message-ID: <20061106182548.4a894a98.Malcolm.Wallace@cs.york.ac.uk> Ross Paterson wrote: > When I've used seq, it's to ensure that a function is strict in that > argument, and therefore has been evaluated before the function is > called. (If the language had unlifted types, I might have used those > instead). Beyond that, I don't care exactly when it was evaluated; it > might be long before, thanks to propagation of strictness information. When I use `seq`, it is sometimes in a construction like unsafePerformIO (emit "squawk!) `seq` x where I am trying to force the impure side-effect to happen, exactly and immediately before x is evaluated. Whilst this is not good style in a general sense, I argue that it is perfectly safe inside certain kinds of library (e.g. for calculating coverage information, or for emitting tracing information). But if the language itself cannot guarantee this exact placement of side-effects, then it becomes impossible to write computation-reflective tools like Hat and hpc for Haskell, in Haskell. That would surely be a sad state of affairs. Regards, Malcolm From ross at soi.city.ac.uk Mon Nov 6 13:57:43 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 6 13:57:20 2006 Subject: seq vs. pseq In-Reply-To: <20061106182548.4a894a98.Malcolm.Wallace@cs.york.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> <20061106172104.GA8989@soi.city.ac.uk> <20061106182548.4a894a98.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20061106185743.GA17783@soi.city.ac.uk> On Mon, Nov 06, 2006 at 06:25:48PM +0000, Malcolm Wallace wrote: > When I use `seq`, it is sometimes in a construction like > > unsafePerformIO (emit "squawk!) `seq` x > > where I am trying to force the impure side-effect to happen, exactly and > immediately before x is evaluated. Whilst this is not good style in a > general sense, I argue that it is perfectly safe inside certain kinds of > library (e.g. for calculating coverage information, or for emitting > tracing information). But if the language itself cannot guarantee this > exact placement of side-effects, then it becomes impossible to write > computation-reflective tools like Hat and hpc for Haskell, in Haskell. > That would surely be a sad state of affairs. Without admitting the existence of "unsafePerformIO", I submit unsafePerformIO (emit "squawk! >> return x) where >> really does imply sequencing. From basvandijk at home.nl Mon Nov 6 15:37:59 2006 From: basvandijk at home.nl (Bas van Dijk) Date: Mon Nov 6 15:37:36 2006 Subject: Desugaring overloaded functions Message-ID: <200611062137.59437.basvandijk@home.nl> Dear GHC Hackers, I'm using the GHC API for a project of mine. I have a question about the way GHC 'desugars' the following overloaded function: incL :: (Num a) => [a] -> [a] incL [] = [] incL (x : xs) = (1 + x) : (incL xs) After calling 'Desugar.deSugar' on this function I get the following Core representation: Test.incL = \ (@ a_ag0) ($dNum_al8 :: {GHC.Num.Num a_ag0}) -> __letrec { incL_afU :: [a_ag0] -> [a_ag0] incL_afU = \ (ds_dlZ :: [a_ag0]) -> case ds_dlZ of wild_B1 { [] -> __letrec { } in GHC.Base.[] @ a_ag0; : x_adm xs_adn -> __letrec { } in GHC.Base.: @ a_ag0 (+_al3 lit_al2 x_adm) (incL_afU xs_adn) }; $dNum_alp :: {GHC.Num.Num a_ag0} $dNum_alp = $dNum_al8; fromInteger_alm :: GHC.Num.Integer -> a_ag0 fromInteger_alm = GHC.Num.fromInteger @ a_ag0 $dNum_alp; lit_al2 :: a_ag0 lit_al2 = fromInteger_alm (GHC.Num.S# 1); +_al3 :: a_ag0 -> a_ag0 -> a_ag0 +_al3 = GHC.Num.+ @ a_ag0 $dNum_al8; } in incL_afU; This is great! However, I don't understand why: 'incL_afU', '$dNum_alp', 'fromInteger_alm', 'lit_al2' and '+_al3' are all listed under the same letrec? What I expect is that a dependency analysis is also applied to this letrec resulting in something like: Test.incL = \ (@ a_ag0) ($dNum_al8 :: {GHC.Num.Num a_ag0}) -> let $dNum_alp :: {GHC.Num.Num a_ag0} $dNum_alp = $dNum_al8; in ( let +_al3 :: a_ag0 -> a_ag0 -> a_ag0 +_al3 = GHC.Num.+ @ a_ag0 $dNum_al8; in ( let fromInteger_alm :: GHC.Num.Integer -> a_ag0 fromInteger_alm = GHC.Num.fromInteger @ a_ag0 $dNum_alp; in ( let lit_al2 :: a_ag0 lit_al2 = fromInteger_alm (GHC.Num.S# 1); in ( __letrec { incL_afU :: [a_ag0] -> [a_ag0] incL_afU = \ (ds_dlZ :: [a_ag0]) -> case ds_dlZ of wild_B1 { [] -> __letrec { } in GHC.Base.[] @ a_ag0; : x_adm xs_adn -> __letrec { } in GHC.Base.: @ a_ag0 (+_al3 lit_al2 x_adm) (incL_afU xs_adn) }; } in incL_afU; ) ) ) ) I would really like the output of 'Desugar.deSugar' to be like the latter. Because than I can apply some beta-reductions to get rid of the non-recursive lets and use that as input for the rest of my project... So, why isn't a dependency analysis applied to the letrec? And is it possible to manually apply a dependency analysis? If so, where can I find such a function? Many thanks in advance, Bas van Dijk P.S. I know that applying 'SimplCore.core2core' will result in something that I almost want: [Test.incL :: forall a_ad8. (GHC.Num.Num a_ad8) => [a_ad8] -> [a_ad8] Test.incL = \ (@ a_akG) ($dNum_akS :: {GHC.Num.Num a_akG}) -> let { lit_akM :: a_akG lit_akM = case $dNum_akS of tpl_Xb { GHC.Num.:DNum tpl_B2 tpl_B3 tpl_B4 tpl_B5 tpl_B6 tpl_B7 tpl_B8 tpl_B9 tpl_Ba -> tpl_Ba (GHC.Num.S# 1) } } in __letrec { incL_akH [LoopBreaker Nothing] :: [a_akG] -> [a_akG] incL_akH = \ (ds_dle :: [a_akG]) -> case ds_dle of wild_B1 { [] -> GHC.Base.[] @ a_akG; : x_adb xs_adc -> GHC.Base.: @ a_akG (case $dNum_akS of tpl_X9 { GHC.Num.:DNum tpl_B2 tpl_B3 tpl_B4 tpl_B5 tpl_B6 tpl_B7 tpl_B8 tpl_B9 tpl_Ba -> tpl_B4 lit_akM x_adb }) (incL_akH xs_adc) }; } in incL_akH] However the rest of my project has trouble with the way 'fromInteger_alm' and '+_al3' are optimzed to case-expressions. So I would rather not use 'core2core'. From frederik at a5.repetae.net Mon Nov 6 16:12:21 2006 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon Nov 6 16:12:07 2006 Subject: make option suggestion Message-ID: <20061106211221.GA2187@a5.repetae.net> Hello, I have a proposal for ghc. I think that it should take a new option, say "--make-command". This will specify a command to be run whenever a source file is read in by ghc. The command will be passed an argument, which is the name of the source file. The idea is that the command can be used to create auto-generated "source" files when ghc needs them. The purpose of this would be the following. Suppose I have a source file, say Source.hs, which is generated from some template, say Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc --make', then the copy of Source.hs which ghc uses will be out of date. That's because ghc doesn't know about the fact that Source.hs is generated from Source.hs.in. If I use ghc, then I'll have to remember to manually generate a new version of Source.hs every time I modify Source.hs.in. But under the present proposal, I would simply write a Makefile with the rules for generating Source.hs, and then pass --make-command=make to ghc. For instance, my Makefile might say: Source.hs: Source.hs.in $(TAC) < $< > $@ Then every time I run ghc, and Source.hs is out of date, an up-to-date version of Source.hs will be generated automatically - because ghc will call 'make Source.hs' before reading it in. Does this sound like a good idea? Frederik -- http://ofb.net/~frederik/ From duncan.coutts at worc.ox.ac.uk Mon Nov 6 16:31:48 2006 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 6 16:25:57 2006 Subject: make option suggestion In-Reply-To: <20061106211221.GA2187@a5.repetae.net> References: <20061106211221.GA2187@a5.repetae.net> Message-ID: <1162848708.7179.34.camel@localhost> I think this kind of build system feature ought to go into Cabal so it can be used more widely and without people needing Makefiles. I admit that we're not there yet with how easy it is to generate source files. Duncan On Mon, 2006-11-06 at 21:12 +0000, Frederik Eaton wrote: > Hello, > > I have a proposal for ghc. I think that it should take a new option, > say "--make-command". This will specify a command to be run whenever a > source file is read in by ghc. The command will be passed an argument, > which is the name of the source file. The idea is that the command can > be used to create auto-generated "source" files when ghc needs them. > > The purpose of this would be the following. Suppose I have a source > file, say Source.hs, which is generated from some template, say > Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc > --make', then the copy of Source.hs which ghc uses will be out of > date. That's because ghc doesn't know about the fact that Source.hs is > generated from Source.hs.in. If I use ghc, then I'll have to remember > to manually generate a new version of Source.hs every time I modify > Source.hs.in. > > But under the present proposal, I would simply write a Makefile with > the rules for generating Source.hs, and then pass --make-command=make > to ghc. For instance, my Makefile might say: > > Source.hs: Source.hs.in > $(TAC) < $< > $@ > > Then every time I run ghc, and Source.hs is out of date, an up-to-date > version of Source.hs will be generated automatically - because ghc > will call 'make Source.hs' before reading it in. > > Does this sound like a good idea? > > Frederik > From ndmitchell at gmail.com Mon Nov 6 16:37:18 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Nov 6 16:36:55 2006 Subject: make option suggestion In-Reply-To: <1162848708.7179.34.camel@localhost> References: <20061106211221.GA2187@a5.repetae.net> <1162848708.7179.34.camel@localhost> Message-ID: <404396ef0611061337q2ea76b0lbb5cdd303a950296@mail.gmail.com> Hi Just for completeness, I came up with a proposal that would solve all this, but in a very non-cabal style way. Taking an example of happy, every generated file (File.hs) would have as its first line: {-# ORIGIN happy sourcefile.y -options -to -happy #-} Then you just modify all haskell generating tools to output this (easy) and suddenly the whole problem of preprocessors goes away. I realise its not the "cabal" style way of doing it - since the information gets put in the generated files etc - but it is pretty simple. You can also add to the file Happy.y: {-# GENERATE happy sourcefile.y -options -to -happy #-} To complete the other side of the generation. Thanks Neil On 11/6/06, Duncan Coutts wrote: > I think this kind of build system feature ought to go into Cabal so it > can be used more widely and without people needing Makefiles. > > I admit that we're not there yet with how easy it is to generate source > files. > > Duncan > > On Mon, 2006-11-06 at 21:12 +0000, Frederik Eaton wrote: > > Hello, > > > > I have a proposal for ghc. I think that it should take a new option, > > say "--make-command". This will specify a command to be run whenever a > > source file is read in by ghc. The command will be passed an argument, > > which is the name of the source file. The idea is that the command can > > be used to create auto-generated "source" files when ghc needs them. > > > > The purpose of this would be the following. Suppose I have a source > > file, say Source.hs, which is generated from some template, say > > Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc > > --make', then the copy of Source.hs which ghc uses will be out of > > date. That's because ghc doesn't know about the fact that Source.hs is > > generated from Source.hs.in. If I use ghc, then I'll have to remember > > to manually generate a new version of Source.hs every time I modify > > Source.hs.in. > > > > But under the present proposal, I would simply write a Makefile with > > the rules for generating Source.hs, and then pass --make-command=make > > to ghc. For instance, my Makefile might say: > > > > Source.hs: Source.hs.in > > $(TAC) < $< > $@ > > > > Then every time I run ghc, and Source.hs is out of date, an up-to-date > > version of Source.hs will be generated automatically - because ghc > > will call 'make Source.hs' before reading it in. > > > > Does this sound like a good idea? > > > > Frederik > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From frederik at a5.repetae.net Mon Nov 6 16:16:42 2006 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon Nov 6 17:34:30 2006 Subject: hsman Message-ID: <20061106211642.GB2187@a5.repetae.net> Hello, I have a perl script which I call 'hsman', which indexes Haddock-generated HTML files, and allows users to search for functions and also GHC manual topics. For instance, I can run: $ hsman foldl to open the documentation on 'foldl'. There is also tab-completion in zsh. If people think this would be useful to others, then I can polish it up to be included with 'ghc' distribution. Does that sound like a good idea? Best, Frederik -- http://ofb.net/~frederik/ From john at repetae.net Mon Nov 6 19:24:28 2006 From: john at repetae.net (John Meacham) Date: Mon Nov 6 19:23:43 2006 Subject: make option suggestion In-Reply-To: <404396ef0611061337q2ea76b0lbb5cdd303a950296@mail.gmail.com> References: <20061106211221.GA2187@a5.repetae.net> <1162848708.7179.34.camel@localhost> <404396ef0611061337q2ea76b0lbb5cdd303a950296@mail.gmail.com> Message-ID: <20061107002428.GB17609@momenergy.repetae.net> I would definitely like something like this. like {-# PREPROCESS drift-ghc #-} to specify the file should be preprocced by drift-ghc. John -- John Meacham - ?repetae.net?john? From ndmitchell at gmail.com Mon Nov 6 19:57:58 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Nov 6 19:57:33 2006 Subject: hsman In-Reply-To: <20061106211642.GB2187@a5.repetae.net> References: <20061106211642.GB2187@a5.repetae.net> Message-ID: <404396ef0611061657p2a89d14ev711d5f11cfd95ecd@mail.gmail.com> Hi Fredrick, > I have a perl script which I call 'hsman', which indexes > Haddock-generated HTML files, and allows users to search for functions > and also GHC manual topics. Have you seen hoogle? http://haskell.org/hoogle - what features does your program offer over hoogle, and would you be interested in putting them into hoogle so everyone gets it. Thanks Neil From quancta at gmail.com Mon Nov 6 22:32:39 2006 From: quancta at gmail.com (Quan Ta) Date: Mon Nov 6 22:32:14 2006 Subject: hsman In-Reply-To: <404396ef0611061657p2a89d14ev711d5f11cfd95ecd@mail.gmail.com> References: <20061106211642.GB2187@a5.repetae.net> <404396ef0611061657p2a89d14ev711d5f11cfd95ecd@mail.gmail.com> Message-ID: how about searching code that's outside of the standard library? Hoogle doesn't seem to know about HaXml, or haskelldb for example (maybe I am missing something obvious) Quan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20061106/e72591bc/attachment.htm From seth at cql.com Mon Nov 6 22:40:28 2006 From: seth at cql.com (Seth Kurtzberg) Date: Mon Nov 6 22:40:06 2006 Subject: hsman In-Reply-To: References: <20061106211642.GB2187@a5.repetae.net> <404396ef0611061657p2a89d14ev711d5f11cfd95ecd@mail.gmail.com> Message-ID: <20061106224028.ec4daf05.seth@cql.com> On Mon, 6 Nov 2006 21:32:39 -0600 "Quan Ta" wrote: > how about searching code that's outside of the standard library? Hoogle > doesn't seem to know about HaXml, or haskelldb for example (maybe I am > missing something obvious) You want to distinguish between capabilities, and the fact that the database for hoogle may not include all the data that is available. If the issue is only the availability of the data, perhaps the best option is to add the data to hoogle. > > Quan > From Malcolm.Wallace at cs.york.ac.uk Tue Nov 7 03:47:01 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Nov 7 03:46:35 2006 Subject: hsman In-Reply-To: <20061106224028.ec4daf05.seth@cql.com> References: <20061106211642.GB2187@a5.repetae.net> <404396ef0611061657p2a89d14ev711d5f11cfd95ecd@mail.gmail.com> <20061106224028.ec4daf05.seth@cql.com> Message-ID: <20061107084701.3e7d30d7.Malcolm.Wallace@cs.york.ac.uk> Seth Kurtzberg writes: > > how about searching code that's outside of the standard library? Hoogle > > doesn't seem to know about HaXml, or haskelldb for example (maybe I am > > missing something obvious) > > You want to distinguish between capabilities, and the fact that the > database for hoogle may not include all the data that is available. > If the issue is only the availability of the data, perhaps the best > option is to add the data to hoogle. Don't forget that, as well as a web engine, Hoogle is also a command-line tool. You can download it, and populate its database with all (and exactly) the libraries you have installed. Regards, Malcolm From ross at soi.city.ac.uk Tue Nov 7 04:15:15 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 7 04:15:01 2006 Subject: seq vs. pseq In-Reply-To: <20061106172104.GA8989@soi.city.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> <20061106172104.GA8989@soi.city.ac.uk> Message-ID: <20061107091515.GA3191@soi.city.ac.uk> On Mon, Nov 06, 2006 at 05:21:04PM +0000, Ross Paterson wrote: > Apart from that, the only thing wrong with seq is its name. I take back that part. Simon's "strong hint" suggestion looks like a good idea. It's just one of a number of implicit assumptions we make about operational behaviour. After all the Report doesn't actually say that monomorphic pattern-bound variables are shared, either. From ross at soi.city.ac.uk Tue Nov 7 04:16:37 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 7 04:16:12 2006 Subject: seq vs. pseq In-Reply-To: <454F3063.2070609@microsoft.com> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> Message-ID: <20061107091637.GB3191@soi.city.ac.uk> On Mon, Nov 06, 2006 at 12:53:55PM +0000, Simon Marlow wrote: > Incedentally, this is also one reason I think lazy I/O is a wart (despite > its obvious usefulness): because it necessarily requires talking about > evaluation order. What is lazy output? Buffering? From simonmarhaskell at gmail.com Tue Nov 7 04:58:03 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Nov 7 04:57:38 2006 Subject: seq vs. pseq In-Reply-To: <20061106182548.4a894a98.Malcolm.Wallace@cs.york.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> <20061106172104.GA8989@soi.city.ac.uk> <20061106182548.4a894a98.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <455058AB.6020200@microsoft.com> Malcolm Wallace wrote: > Ross Paterson wrote: > > >>When I've used seq, it's to ensure that a function is strict in that >>argument, and therefore has been evaluated before the function is >>called. (If the language had unlifted types, I might have used those >>instead). Beyond that, I don't care exactly when it was evaluated; it >>might be long before, thanks to propagation of strictness information. > > > When I use `seq`, it is sometimes in a construction like > > unsafePerformIO (emit "squawk!) `seq` x > > where I am trying to force the impure side-effect to happen, exactly and > immediately before x is evaluated. Whilst this is not good style in a > general sense, I argue that it is perfectly safe inside certain kinds of > library (e.g. for calculating coverage information, or for emitting > tracing information). But if the language itself cannot guarantee this > exact placement of side-effects, then it becomes impossible to write > computation-reflective tools like Hat and hpc for Haskell, in Haskell. > That would surely be a sad state of affairs. My take on this kind of thing is that if you want a specific operational behaviour, then you're doing something implementation-specific. We shouldn't mandate any kind of operational behaviour across Haskell implementations. Yes, I'm saying you can't do this portably, and it is good that you can't, becauuse it gives implementations more flexibility. Cheers, Simon From simonmarhaskell at gmail.com Tue Nov 7 05:42:45 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Nov 7 05:42:20 2006 Subject: ghc-testsuite-6.6 on Macs In-Reply-To: <45476C12.9080807@tzi.de> References: <45476C12.9080807@tzi.de> Message-ID: <45506325.6000906@microsoft.com> Christian Maeder wrote: > Did someone run the test-suite of the binary distributions? > > http://www.haskell.org/ghc/dist/6.6/ghc-6.6-ppc-apple-darwin.tar.gz > http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 > > I've build a (ppc-) mac-distribution from sources and my results are > shown below. > > I had the following 3 unexpected failures under linux, too (by using > "make TEST_HC=" and the was from > http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2) > > cg058(ghci) We also have cg058(ghci) failing on x86, I think it just runs out of time. We should make this test a bit quicker. > ghcpkg01(normal) > ghcpkg03(normal) Any idea why these are failing for you? > I thought the failure signals002(ghci) was related to > http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/10947 > In fact, I needed to kill the ghc-process to continue the tests. > > The test files cc004.hs and ffi012.hs failed with several messages of > the form: > > calling convention not supported on this architecture: stdcall > When checking declaration: > foreign import stdcall safe "wrapper" > wrap_f :: F -> IO (FunPtr F) > > However, they did not make it into the summary They are probably expected failures for you. > Cheers Christian > > > OVERALL SUMMARY for test run started at Mon Oct 23 14:54:15 CEST 2006 > 1455 total tests, which gave rise to > 6441 test cases, of which > 0 caused framework failures > 1126 were skipped > > 5242 expected passes > 55 expected failures > 3 unexpected passes > 15 unexpected failures > > Unexpected passes: > barton-mangler-bug(optasm) > cholewo-eval(optasm,profasm) > > Unexpected failures: > barton-mangler-bug(opt) > cabal02(normal) > cg058(ghci) > conc019(opt,profasm) > conc024(opt) > ffi009(ghci) > forkprocess01(ghci) > galois_raytrace(opt,prof) > ghcpkg01(normal) > ghcpkg03(normal) > joao-circular(prof,profasm) > signals002(ghci) some of those could be floating-point differences. In any case, it would be good to investigate all of them and get any expected failures registered properly in the testsuite. Can you (or someone else) take a look and find out why each of them is failing? Cheers, Simon From simonmarhaskell at gmail.com Tue Nov 7 05:54:27 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Nov 7 05:54:01 2006 Subject: make option suggestion In-Reply-To: <20061106211221.GA2187@a5.repetae.net> References: <20061106211221.GA2187@a5.repetae.net> Message-ID: <455065E3.2060104@microsoft.com> Frederik Eaton wrote: > Hello, > > I have a proposal for ghc. I think that it should take a new option, > say "--make-command". This will specify a command to be run whenever a > source file is read in by ghc. The command will be passed an argument, > which is the name of the source file. The idea is that the command can > be used to create auto-generated "source" files when ghc needs them. > > The purpose of this would be the following. Suppose I have a source > file, say Source.hs, which is generated from some template, say > Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc > --make', then the copy of Source.hs which ghc uses will be out of > date. That's because ghc doesn't know about the fact that Source.hs is > generated from Source.hs.in. If I use ghc, then I'll have to remember > to manually generate a new version of Source.hs every time I modify > Source.hs.in. > > But under the present proposal, I would simply write a Makefile with > the rules for generating Source.hs, and then pass --make-command=make > to ghc. For instance, my Makefile might say: > > Source.hs: Source.hs.in > $(TAC) < $< > $@ > > Then every time I run ghc, and Source.hs is out of date, an up-to-date > version of Source.hs will be generated automatically - because ghc > will call 'make Source.hs' before reading it in. > > Does this sound like a good idea? Since you already have a Makefile, why not add this to it: SRCS = Source.hs ... prog: $(SRCS) ghc --make $(SRCS) -o prog and then just say 'make' to build your program? Surely that's easier than typing 'ghc --make-command=make ...'? Maybe I'm missing something? Cheers, Simon From simonmarhaskell at gmail.com Tue Nov 7 05:58:56 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Nov 7 05:58:30 2006 Subject: make option suggestion In-Reply-To: <20061107002428.GB17609@momenergy.repetae.net> References: <20061106211221.GA2187@a5.repetae.net> <1162848708.7179.34.camel@localhost> <404396ef0611061337q2ea76b0lbb5cdd303a950296@mail.gmail.com> <20061107002428.GB17609@momenergy.repetae.net> Message-ID: <455066F0.70309@microsoft.com> John Meacham wrote: > I would definitely like something like this. > like > > {-# PREPROCESS drift-ghc #-} > > to specify the file should be preprocced by drift-ghc. I worry that putting details of the build procedure into the source file will lead to problems. Often build parameters need to be configurable, eg. do I use happy's -g option or not? It depends what Haskell compiler you're using. Build systems are usually well suited to doing configurable things. Also, we don't really want pathnames leaking into source files. So we're left with just specifying the kind of preprocessor to use, as in the example above. It's certainly more general than the existing scheme of looking at the file extension, but I wonder whether it's worth it. Cheers, Simon From frederik at a5.repetae.net Tue Nov 7 06:16:37 2006 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue Nov 7 06:16:28 2006 Subject: make option suggestion In-Reply-To: <404396ef0611061337q2ea76b0lbb5cdd303a950296@mail.gmail.com> References: <20061106211221.GA2187@a5.repetae.net> <1162848708.7179.34.camel@localhost> <404396ef0611061337q2ea76b0lbb5cdd303a950296@mail.gmail.com> Message-ID: <20061107111637.GF17992@a5.repetae.net> The {-# ORIGIN ... #-} keyword sounds like a nice solution, but wouldn't it require creating each generated file initially by hand, so that the compilers know that it exists? I'd rather have a build system where I can delete all of the generated files before distributing my code, and still have compilation work. Maybe I'm not understanding. Cheers, Frederik On Mon, Nov 06, 2006 at 09:37:18PM +0000, Neil Mitchell wrote: > Hi > > Just for completeness, I came up with a proposal that would solve all > this, but in a very non-cabal style way. > > Taking an example of happy, every generated file (File.hs) would have > as its first line: > > {-# ORIGIN happy sourcefile.y -options -to -happy #-} > > Then you just modify all haskell generating tools to output this > (easy) and suddenly the whole problem of preprocessors goes away. > > I realise its not the "cabal" style way of doing it - since the > information gets put in the generated files etc - but it is pretty > simple. > > You can also add to the file Happy.y: > {-# GENERATE happy sourcefile.y -options -to -happy #-} > > To complete the other side of the generation. > > Thanks > > Neil > > On 11/6/06, Duncan Coutts wrote: > >I think this kind of build system feature ought to go into Cabal so it > >can be used more widely and without people needing Makefiles. > > > >I admit that we're not there yet with how easy it is to generate source > >files. > > > >Duncan > > > >On Mon, 2006-11-06 at 21:12 +0000, Frederik Eaton wrote: > >> Hello, > >> > >> I have a proposal for ghc. I think that it should take a new option, > >> say "--make-command". This will specify a command to be run whenever a > >> source file is read in by ghc. The command will be passed an argument, > >> which is the name of the source file. The idea is that the command can > >> be used to create auto-generated "source" files when ghc needs them. > >> > >> The purpose of this would be the following. Suppose I have a source > >> file, say Source.hs, which is generated from some template, say > >> Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc > >> --make', then the copy of Source.hs which ghc uses will be out of > >> date. That's because ghc doesn't know about the fact that Source.hs is > >> generated from Source.hs.in. If I use ghc, then I'll have to remember > >> to manually generate a new version of Source.hs every time I modify > >> Source.hs.in. > >> > >> But under the present proposal, I would simply write a Makefile with > >> the rules for generating Source.hs, and then pass --make-command=make > >> to ghc. For instance, my Makefile might say: > >> > >> Source.hs: Source.hs.in > >> $(TAC) < $< > $@ > >> > >> Then every time I run ghc, and Source.hs is out of date, an up-to-date > >> version of Source.hs will be generated automatically - because ghc > >> will call 'make Source.hs' before reading it in. > >> > >> Does this sound like a good idea? > >> > >> Frederik > >> > > > >_______________________________________________ > >Glasgow-haskell-users mailing list > >Glasgow-haskell-users@haskell.org > >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -- http://ofb.net/~frederik/ From frederik at a5.repetae.net Tue Nov 7 06:22:44 2006 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue Nov 7 06:22:50 2006 Subject: hsman In-Reply-To: <404396ef0611061657p2a89d14ev711d5f11cfd95ecd@mail.gmail.com> References: <20061106211642.GB2187@a5.repetae.net> <404396ef0611061657p2a89d14ev711d5f11cfd95ecd@mail.gmail.com> Message-ID: <20061107112244.GG17992@a5.repetae.net> Hi Neil, I've seen hoogle and I like it. Does Hoogle have the following features? - ability to index any library - ability to use from the console - command-line autocompletion Of course, there are many features that Hoogle has, which my program is missing. Frederik On Tue, Nov 07, 2006 at 12:57:58AM +0000, Neil Mitchell wrote: > Hi Fredrick, > > >I have a perl script which I call 'hsman', which indexes > >Haddock-generated HTML files, and allows users to search for functions > >and also GHC manual topics. > > Have you seen hoogle? http://haskell.org/hoogle - what features does > your program offer over hoogle, and would you be interested in putting > them into hoogle so everyone gets it. > > Thanks > > Neil > -- http://ofb.net/~frederik/ From maeder at tzi.de Tue Nov 7 06:39:22 2006 From: maeder at tzi.de (Christian Maeder) Date: Tue Nov 7 06:39:01 2006 Subject: ghc-testsuite-6.6 on Macs In-Reply-To: <45506325.6000906@microsoft.com> References: <45476C12.9080807@tzi.de> <45506325.6000906@microsoft.com> Message-ID: <4550706A.4010008@tzi.de> Simon Marlow schrieb: >> ghcpkg01(normal) >> ghcpkg03(normal) > > Any idea why these are failing for you? Maybe rather than using my installed ghc-pkg (that lists haskell-src) some inplace ghc-pkg was used: ghc-pkg: dependency haskell-src doesn't exist (use --force to override) make[2]: *** [ghcpkg01] Fehler 1 >> I thought the failure signals002(ghci) was related to >> http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/10947 >> In fact, I needed to kill the ghc-process to continue the tests. >> >> The test files cc004.hs and ffi012.hs failed with several messages of >> the form: >> >> calling convention not supported on this architecture: stdcall >> When checking declaration: >> foreign import stdcall safe "wrapper" >> wrap_f :: F -> IO (FunPtr F) >> >> However, they did not make it into the summary > > They are probably expected failures for you. Yes they are indeed, but should these really be "expected failures"? > some of those could be floating-point differences. In any case, it > would be good to investigate all of them and get any expected failures > registered properly in the testsuite. Can you (or someone else) take a > look and find out why each of them is failing? Yes, I hope someone else joins in. Christian From ndmitchell at gmail.com Tue Nov 7 06:42:41 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Nov 7 06:42:14 2006 Subject: hsman In-Reply-To: <20061107112244.GG17992@a5.repetae.net> References: <20061106211642.GB2187@a5.repetae.net> <404396ef0611061657p2a89d14ev711d5f11cfd95ecd@mail.gmail.com> <20061107112244.GG17992@a5.repetae.net> Message-ID: <404396ef0611070342j10052152l3f0f69efc2eac2ba@mail.gmail.com> Hi > - ability to index any library Yes, runhaskell Setup haddock -hoogle will generate a hoogle database for any library. Hoogle 4 (currently in development) will make searching multiple libraries much much easier. > - ability to use from the console Yes, although may currently be a bit broken (I'll make a command line release today hopefully which guarantees to work) > - command-line autocompletion No, how do I add it? I use Windows which doesn't support this, but if someone gives me the technical details of how to do it, I'm sure I can add it. Thanks Neil From frederik at a5.repetae.net Tue Nov 7 07:07:14 2006 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue Nov 7 07:06:56 2006 Subject: make option suggestion In-Reply-To: <455065E3.2060104@microsoft.com> References: <20061106211221.GA2187@a5.repetae.net> <455065E3.2060104@microsoft.com> Message-ID: <20061107120714.GI17992@a5.repetae.net> > Since you already have a Makefile, why not add this to it: > > SRCS = Source.hs ... > prog: $(SRCS) > ghc --make $(SRCS) -o prog > > and then just say 'make' to build your program? Surely that's easier than typing 'ghc > --make-command=make ...'? Maybe I'm missing something? Hi Simon, I think it's actually not easier. In your example, I would have to list all of the generated dependencies for 'prog' in the makefile. Further, if I want to compile multiple programs, all of which depended on Source.hs, then I would have to have separate entries for each of them. My punishment for using generated files is that 'ghc --make' no longer infers dependencies for them, and I am forced to list each one by hand as a dependency of the program or library I am building, for each program. Thus if I want to build n programs, each of which uses m generated source files, the amount of text I have to put in my makefile scales as n*m. This may seem trivial for most projects, but it also means that each time I add a generated source file, or a program, I have to remember to create several Makefile entries of the proper form, which can be cumbersome. You say "since you already have a Makefile", but in my proposal, 'make' isn't actually necessary - a simple shell script with a 'case' statement would do. It's just a way of getting ghc to tell us what the dependencies of a certain compilation are. In multi-target invocations, ghc could even set an environment variable indicating which target is being compiled - then we could change --make-command to be something which also records dependencies for use in a makefile. Lastly, my proposal is trivial to use with Cabal, by setting GHC-Options, whereas yours would perhaps require me to switch to using Cabal via 'make', which would probably be almost as annoying as putting the commands to generate my source files in Setup.hs in the first place... There are several issues which need to be worked out - when '--make-command' is specified, then how should ghc test for existence of source files, how should it ask for their modification times, etc. I think these all have pretty simple solutions though. Cheers, Frederik -- http://ofb.net/~frederik/ From Alistair_Bayley at invescoperpetual.co.uk Tue Nov 7 08:03:38 2006 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Tue Nov 7 08:03:24 2006 Subject: hsman In-Reply-To: <404396ef0611070342j10052152l3f0f69efc2eac2ba@mail.gmail.com> Message-ID: <252C89C12FCAD84BA018CAD5268682FD05B5F9AD@GBLONXMB02.corp.amvescap.net> > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Neil Mitchell > > > - command-line autocompletion > > No, how do I add it? I use Windows which doesn't support this, but if > someone gives me the technical details of how to do it, I'm sure I can > add it. How would it work on Unix? I assume that the command-line program just takes it's input "from the command line", so it doesn't get invoked until after you've finished typing the command... Unless this is a proposal to create a console version of hoogle, a bit like ghci, which could take advantage of System.Console.Readline. BTW, on Windows XP command line filename completion is enabled - just use the Tab key. On NT4 and W2K you have to tweak the registry to switch it on (and you can choose which key to use, if you don't like Tab). Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From Malcolm.Wallace at cs.york.ac.uk Tue Nov 7 08:01:46 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Nov 7 08:03:51 2006 Subject: seq vs. pseq In-Reply-To: <455058AB.6020200@microsoft.com> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> <20061106172104.GA8989@soi.city.ac.uk> <20061106182548.4a894a98.Malcolm.Wallace@cs.york.ac.uk> <455058AB.6020200@microsoft.com> Message-ID: <20061107130146.37ba7867.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow wrote: > > When I use `seq`, it is sometimes in a construction like > > > > unsafePerformIO (emit "squawk!) `seq` x > > My take on this kind of thing is that if you want a specific > operational behaviour, then you're doing something > implementation-specific. We shouldn't mandate any kind of > operational behaviour across Haskell implementations. Yes, I'm > saying you can't do this portably, and it is good that you can't, > because it gives implementations more flexibility. Hmmm. I absolutely agree with the general point that Haskell should, as much as possible, not mandate any specific operational behaviour. But what if I want to _observe_ or record the actual operational behaviour of some particular implementation? For instance, to generate a heap profile, or a computational trace, or a coverage log, or something. The results may well be different for every different implementation, and I am perfectly happy with that. I may actually want to see the differences. But do you really want to say "The Haskell language provides the programmer no mechanism to observe this"? "Use some other language, or some compiler-specific hack"? To me, it is unacceptable to be prevented from write an observational tool for a language in the language itself. Especially since we already have a couple of features in the language that _do_ affect the operational behaviour. They are warts, yes, but if we have to have them, I want them to be genuinely useful. We should bite the bullet and specify in what way they affect the operational semantics, without implying any more specific operational behaviour elsewhere in the language. Regards, Malcolm P.S. Actually, as Ross points out, there is an implied operational semantics of the I/O monad. Maybe that is where the Report needs to become more specific, and mandate certain behaviours. From ndmitchell at gmail.com Tue Nov 7 08:30:43 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Nov 7 08:30:16 2006 Subject: hsman In-Reply-To: <252C89C12FCAD84BA018CAD5268682FD05B5F9AD@GBLONXMB02.corp.amvescap.net> References: <404396ef0611070342j10052152l3f0f69efc2eac2ba@mail.gmail.com> <252C89C12FCAD84BA018CAD5268682FD05B5F9AD@GBLONXMB02.corp.amvescap.net> Message-ID: <404396ef0611070530x4636b1c2h70c02d493b193e26@mail.gmail.com> Hi > How would it work on Unix? I assume that the command-line program just > takes it's input "from the command line", so it doesn't get invoked > until after you've finished typing the command... > > Unless this is a proposal to create a console version of hoogle, a bit > like ghci, which could take advantage of System.Console.Readline. I do have something like that in the works (hoogli), but its not ready for the world quite yet. > BTW, on Windows XP command line filename completion is enabled - just > use the Tab key. On NT4 and W2K you have to tweak the registry to switch > it on (and you can choose which key to use, if you don't like Tab). Yes, I know command line completion works - but only for files, not for anything else, and there is no way to make it work for other things. However, I know that zsh can do funky things like autocompleting ssh paths etc - and I think I remember seeing that there was some way a program could tell zsh what it could autocomplete to - but that is a hazy memory from a while ago. Thanks Neil From kr.angelov at gmail.com Tue Nov 7 09:55:19 2006 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Tue Nov 7 09:54:52 2006 Subject: Template Haskell quotion for [] Message-ID: Hello, I had this example that was working with earliest versions of GHC but it doesn't work with GHC-6.6. $(deriveReflectable ''[]) Above this isn't a double quote but two single quotes. It may not be clear with some fonts. Is this a bug or just there is a change in the syntax? The error that I get is: src/Database/HarmonyDB/Instances.hs:1:0: Illegal variable name: `[]' When splicing generated code into the program Regards, Krasimir From kolmodin at dtek.chalmers.se Tue Nov 7 10:12:36 2006 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Tue Nov 7 10:12:09 2006 Subject: hsman In-Reply-To: <404396ef0611070530x4636b1c2h70c02d493b193e26@mail.gmail.com> References: <404396ef0611070342j10052152l3f0f69efc2eac2ba@mail.gmail.com> <252C89C12FCAD84BA018CAD5268682FD05B5F9AD@GBLONXMB02.corp.amvescap.net> <404396ef0611070530x4636b1c2h70c02d493b193e26@mail.gmail.com> Message-ID: <4956.140.166.149.119.1162912356.squirrel@webmail.chalmers.se> > Hi > >> How would it work on Unix? I assume that the command-line program just >> takes it's input "from the command line", so it doesn't get invoked >> until after you've finished typing the command... Not necessarily true if completion is involved ... see below. > However, I know that zsh can do funky things like > autocompleting ssh paths etc - and I think I remember seeing that > there was some way a program could tell zsh what it could autocomplete > to - but that is a hazy memory from a while ago. Have a look at the (unreleased) bash completion for ghc-pkg: http://www.haskell.org/~kolmodin/code/ghc-bash-completion/ghc-pkg source it in bash to get it started. As you can see that ghc-pkg doesn't have special support for autocompletion, but it's possible anyway. To make it a bit simpler to write the completion, it's nice if the application in question has support for it. A nice example of this is darcs[1] which implements the command '--commands' and the flag '--list-option'. Cheers, Lennart Kolmodin [1] http://www.abridgegame.org/repos/darcs-unstable/darcs_completion From simonpj at microsoft.com Tue Nov 7 10:30:52 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Nov 7 10:30:39 2006 Subject: Desugaring overloaded functions In-Reply-To: <200611062137.59437.basvandijk@home.nl> References: <200611062137.59437.basvandijk@home.nl> Message-ID: | This is great! However, I don't understand why: | 'incL_afU', | '$dNum_alp', | 'fromInteger_alm', | 'lit_al2' and | '+_al3' are all listed under the same letrec? The desugarer simply does whatever is easiest, leaving it to the simplifier to untangle the resulting dependencies. Doubtless we could make the desugarer more complicated, but doing so would make the simplifier no simpler (since it must do dependency analysis anyway). Hence the current story. | I would really like the output of 'Desugar.deSugar' to be like the latter. | Because than I can apply some beta-reductions to get rid of the non-recursive | lets and use that as input for the rest of my project... The bit that does the dependency analysis is called the Occurrence Analyser. Its in compiler/simplCore/OccAnal. A single run of the occurrence analyser will produce a fully-dependency-analysed program. Maybe that's what you want? Simon From frederik at a5.repetae.net Tue Nov 7 17:59:34 2006 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue Nov 7 17:59:16 2006 Subject: hsman In-Reply-To: <404396ef0611070530x4636b1c2h70c02d493b193e26@mail.gmail.com> References: <404396ef0611070342j10052152l3f0f69efc2eac2ba@mail.gmail.com> <252C89C12FCAD84BA018CAD5268682FD05B5F9AD@GBLONXMB02.corp.amvescap.net> <404396ef0611070530x4636b1c2h70c02d493b193e26@mail.gmail.com> Message-ID: <20061107225934.GJ17992@a5.repetae.net> > Yes, I know command line completion works - but only for files, not > for anything else, and there is no way to make it work for other > things. However, I know that zsh can do funky things like > autocompleting ssh paths etc - and I think I remember seeing that > there was some way a program could tell zsh what it could autocomplete > to - but that is a hazy memory from a while ago. What I did, to make things more modular, was add an option to my program to list the completions of a given set of arguments. So prepending "--completions" to the argument list and running the program just prints out a list of completions for the last argument. It's not really correct, since the user might have backed up to e.g. the second-to-last argument and pressed TAB there, but I'm not sure how to fix it. It's probably a simple modification, that a real zsh person could figure out in a second. I have a file containing the following in my fpath: ---------------------------------------------------------------- #!/bin/zsh _haskell-man () { L=($($words[0] --completions $words)) compadd -a -- L } compdef _haskell-man hsman ---------------------------------------------------------------- Anyway, you say you are working on a command line interface - OK, but I think the current situation is just a bit embarrassing, and I have something that works now. I can access all Perl documentation with 'man', and that is very convenient. It is just two words, e.g.: $ man CGI I think it is reasonable to expect any other kind of documentation to be just as easy to look up. I think a satisfactory system for Haskell should: - be usable from the command line, and with tab completion (i.e. users shouldn't have to enter an interactive loop like ghci) - be able to show the haddock documentation for a given function (the most common usage) in one step (i.e. not 2 steps as with the hoogle web interface). when there is more than one match, my program chooses a default; the user can ask to see all matches with a separate option. this is usually preferable, because many functions, for instance foldl1, are defined in multiple places with exactly the same documentation (Prelude, Data.List, Data.Foldable), and the user doesn't care which one pops up. Best, Frederik -- http://ofb.net/~frederik/ From ndmitchell at gmail.com Tue Nov 7 18:04:09 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Nov 7 18:03:41 2006 Subject: hsman In-Reply-To: <20061107225934.GJ17992@a5.repetae.net> References: <404396ef0611070342j10052152l3f0f69efc2eac2ba@mail.gmail.com> <252C89C12FCAD84BA018CAD5268682FD05B5F9AD@GBLONXMB02.corp.amvescap.net> <404396ef0611070530x4636b1c2h70c02d493b193e26@mail.gmail.com> <20061107225934.GJ17992@a5.repetae.net> Message-ID: <404396ef0611071504t672bb47fm1f25125bbe12a04f@mail.gmail.com> Hi > Anyway, you say you are working on a command line interface - OK, but > I think the current situation is just a bit embarrassing, and I have > something that works now. I can access all Perl documentation with > 'man', and that is very convenient. It is just two words, e.g.: Fair enough, you are certainly welcome to "compete" with Hoogle :) It might even persuade me to get the Hoogle thing done faster (although I did go and release a command line version today) > - be usable from the command line, and with tab completion (i.e. users > shouldn't have to enter an interactive loop like ghci) I think it should do both. > - be able to show the haddock documentation for a given function (the > most common usage) in one step (i.e. not 2 steps as with the hoogle > web interface). Hoogle 4 does this to some degree. I can certainly add a flag that makes it more encouraged to show some documentation even when there are multiple matches. Thanks Neil From basvandijk at home.nl Tue Nov 7 20:21:44 2006 From: basvandijk at home.nl (Bas van Dijk) Date: Tue Nov 7 20:21:16 2006 Subject: Desugaring overloaded functions In-Reply-To: References: <200611062137.59437.basvandijk@home.nl> Message-ID: <200611080221.44586.basvandijk@home.nl> On Tuesday 07 November 2006 16:30, Simon Peyton-Jones wrote: > The bit that does the dependency analysis is called the Occurrence > Analyser. Its in compiler/simplCore/OccAnal. A single run of the > occurrence analyser will produce a fully-dependency-analysed program. Maybe > that's what you want? That's exactly what I want. I tried it and it works perfectly. Thanks very much, Bas van Dijk From bulat.ziganshin at gmail.com Wed Nov 8 02:03:47 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 8 02:58:41 2006 Subject: subtle inlining problem Message-ID: <484242054.20061108100347@gmail.com> Hello glasgow-haskell-users, in the following definitions: > {-# INLINE getInteger #-} > getInteger = ... -- large definition that will be not inlined > -- without pragma > > instance Binary Integer where > get = getInteger is Integer.get will be inlined or not? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From basvandijk at home.nl Wed Nov 8 07:57:12 2006 From: basvandijk at home.nl (Bas van Dijk) Date: Wed Nov 8 07:56:47 2006 Subject: Desugaring overloaded functions In-Reply-To: <200611080221.44586.basvandijk@home.nl> References: <200611062137.59437.basvandijk@home.nl> <200611080221.44586.basvandijk@home.nl> Message-ID: <200611081357.12612.basvandijk@home.nl> Hello, I have another question about the desugarer. When I desugar and apply OccurAnal.occurAnalysePgm on: incL [] = [] incL (x : xs) = (1 + x) : (incL xs) I get the beautiful: Test.incL :: forall a_ad8. (GHC.Num.Num a_ad8) => [a_ad8] -> [a_ad8] [Exported] [] Test.incL = \ (@ a_akG) ($dNum_akS :: {GHC.Num.Num a_akG}) -> let { $dNum_alc [Once Nothing] :: {GHC.Num.Num a_akG} [] $dNum_alc = $dNum_akS } in let { fromInteger_al9 [Once! Nothing] :: GHC.Num.Integer -> a_akG [] fromInteger_al9 = GHC.Num.fromInteger @ a_akG $dNum_alc } in let { $dNum_al7 [Once Nothing] :: {GHC.Num.Num a_akG} [] $dNum_al7 = $dNum_akS } in let { +_akN [OnceL! Nothing] :: a_akG -> a_akG -> a_akG [] +_akN = GHC.Num.+ @ a_akG $dNum_al7 } in let { lit_akM [OnceL Nothing] :: a_akG [] lit_akM = fromInteger_al9 (GHC.Num.S# 1) } in __letrec { incL_akO [OnceL! Nothing] :: [a_akG] -> [a_akG] [] incL_akO = incL_akH; incL_akH [LoopBreaker Nothing] :: [a_akG] -> [a_akG] [] incL_akH = \ (ds_dle [Once! Nothing] :: [a_akG]) -> case ds_dle of wild_B1 [Dead Nothing] { [] -> GHC.Base.[] @ a_akG; : x_adb [Once Nothing] xs_adc [Once Nothing] -> GHC.Base.: @ a_akG (+_akN lit_akM x_adb) (incL_akO xs_adc) }; } in incL_akH This is almost exactly what I want. There is one thing I don't understand though. Namely the __letrec defining: incL_akO = incL_akH incL_akH = ... incL_ak0 ... Why this indirection? Is this also because the desugarer tries to do the most simple thing? Or is there an other reason? And is there a preprocess function that translates this into: incL_akH = ... incL_akH ... ? regards, Bas van Dijk From simonmarhaskell at gmail.com Wed Nov 8 08:23:34 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Nov 8 08:23:06 2006 Subject: seq vs. pseq In-Reply-To: <20061107130146.37ba7867.Malcolm.Wallace@cs.york.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> <20061106172104.GA8989@soi.city.ac.uk> <20061106182548.4a894a98.Malcolm.Wallace@cs.york.ac.uk> <455058AB.6020200@microsoft.com> <20061107130146.37ba7867.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4551DA56.2050200@microsoft.com> Malcolm Wallace wrote: > Simon Marlow wrote: > > >>>When I use `seq`, it is sometimes in a construction like >>> >>> unsafePerformIO (emit "squawk!) `seq` x >> >>My take on this kind of thing is that if you want a specific >>operational behaviour, then you're doing something >>implementation-specific. We shouldn't mandate any kind of >>operational behaviour across Haskell implementations. Yes, I'm >>saying you can't do this portably, and it is good that you can't, >>because it gives implementations more flexibility. > > Hmmm. I absolutely agree with the general point that Haskell should, as > much as possible, not mandate any specific operational behaviour. But > what if I want to _observe_ or record the actual operational behaviour > of some particular implementation? For instance, to generate a heap > profile, or a computational trace, or a coverage log, or something. The > results may well be different for every different implementation, and I > am perfectly happy with that. I may actually want to see the > differences. But do you really want to say "The Haskell language > provides the programmer no mechanism to observe this"? "Use some other > language, or some compiler-specific hack"? To me, it is unacceptable to > be prevented from write an observational tool for a language in the > language itself. Yes, I'm saying you have to do something compiler-specific in order to observe the operational behaviour. Now that may well be unsafePerformIO+seq on compiler X, but the point is that this isn't guaranteed to do what you want on all implementations, precisely because we want to admit different evaluation strategies. What does it even *mean* to "evaluate x before y"? For example, we might have an evaluation strategy that uses spare CPUs to search for unevaluated objects in the heap and speculatively evaluate them for a while; we might thereby evaluate y (or some of y's free variables) at any time, and even revert y from an evaluated to an unevaluated state. By even saying that there's a concept of "evaluation order" you've already nailed too many doors shut, IMO. > Especially since we already have a couple of features in the language > that _do_ affect the operational behaviour. what are you referring to specifically? hGetContents is the only one I'm aware of. Cheers, Simon From simonmarhaskell at gmail.com Wed Nov 8 08:29:04 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Nov 8 08:28:35 2006 Subject: seq vs. pseq In-Reply-To: <20061106185743.GA17783@soi.city.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061106135352.05334e48.Malcolm.Wallace@cs.york.ac.uk> <20061106172104.GA8989@soi.city.ac.uk> <20061106182548.4a894a98.Malcolm.Wallace@cs.york.ac.uk> <20061106185743.GA17783@soi.city.ac.uk> Message-ID: <4551DBA0.80109@microsoft.com> Ross Paterson wrote: > On Mon, Nov 06, 2006 at 06:25:48PM +0000, Malcolm Wallace wrote: > >>When I use `seq`, it is sometimes in a construction like >> >> unsafePerformIO (emit "squawk!) `seq` x >> >>where I am trying to force the impure side-effect to happen, exactly and >>immediately before x is evaluated. Whilst this is not good style in a >>general sense, I argue that it is perfectly safe inside certain kinds of >>library (e.g. for calculating coverage information, or for emitting >>tracing information). But if the language itself cannot guarantee this >>exact placement of side-effects, then it becomes impossible to write >>computation-reflective tools like Hat and hpc for Haskell, in Haskell. >>That would surely be a sad state of affairs. > > > Without admitting the existence of "unsafePerformIO", I submit > > unsafePerformIO (emit "squawk! >> return x) > > where >> really does imply sequencing. Does it? What's stopping a Haskell implementation from evaluating x early? As far as I know, the only time it wouldn't be valid is if x refers to a stream created by hGetContents, and even then you could evaluate it early as long as you don't move it past some I/O operation that could "tell the difference" (although the report doesn't really say this explicitly, it's just the accepted behaviour of lazy input streams). Cheers, Simon From simonmarhaskell at gmail.com Wed Nov 8 08:30:03 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Nov 8 08:29:35 2006 Subject: seq vs. pseq In-Reply-To: <20061107091637.GB3191@soi.city.ac.uk> References: <454207FF.60900@microsoft.com> <20061027162748.6d2820e9.Malcolm.Wallace@cs.york.ac.uk> <454F3063.2070609@microsoft.com> <20061107091637.GB3191@soi.city.ac.uk> Message-ID: <4551DBDB.6090502@microsoft.com> Ross Paterson wrote: > On Mon, Nov 06, 2006 at 12:53:55PM +0000, Simon Marlow wrote: > >>Incedentally, this is also one reason I think lazy I/O is a wart (despite >>its obvious usefulness): because it necessarily requires talking about >>evaluation order. > > > What is lazy output? Buffering? Well ok, "lazy I" then :-) Cheers, Simon From maeder at tzi.de Wed Nov 8 09:09:31 2006 From: maeder at tzi.de (Christian Maeder) Date: Wed Nov 8 09:08:59 2006 Subject: Link error under solaris 8 In-Reply-To: <45407025.7030508@tzi.de> References: <45407025.7030508@tzi.de> Message-ID: <4551E51B.20807@tzi.de> Christian Maeder schrieb: > Hi, > > I get a link error under sparc sun Solaris 8, when linking my stage2 > compiler. I have "undefined reference to" a couple of mathematical > function like powf, tanhf, coshf, sinhf, atanf, acosf, asinf, tanf, > cosf, sinf, sqrtf, logf, and expf > > Is libm version 2 needed? The stage1 compiler was content with libm > version 1. The stage2 compiler could only be linked with libm.so.2 (although "nm" listed the above functions also in libm.so.1.) Christian From simonpj at microsoft.com Wed Nov 8 12:21:59 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 8 12:22:10 2006 Subject: Desugaring overloaded functions In-Reply-To: <200611081357.12612.basvandijk@home.nl> References: <200611062137.59437.basvandijk@home.nl> <200611080221.44586.basvandijk@home.nl> <200611081357.12612.basvandijk@home.nl> Message-ID: | This is almost exactly what I want. There is one thing I don't understand | though. Namely the __letrec defining: | | incL_akO = incL_akH | incL_akH = ... incL_ak0 ... | | Why this indirection? Is this also because the desugarer tries to do the most | simple thing? Yes, that's why. | And is there a preprocess function that translates this into: | | incL_akH = ... incL_akH ... ? Sure! Just run the simplifier. It has plenty of knobs to tell it how hard to try. In particular, simplifyPgm has this type simplifyPgm :: SimplifierMode -> [SimplifierSwitch] -> HscEnv -> UniqSupply -> RuleBase -> ModGuts -> IO (SimplCount, ModGuts) -- New bindings Setting the SimplifierMode to SimplGently makes the simplifier just do the bare minimum. It's probably what you want. Simon From simonpj at microsoft.com Wed Nov 8 12:41:51 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 8 12:41:32 2006 Subject: subtle inlining problem In-Reply-To: <484242054.20061108100347@gmail.com> References: <484242054.20061108100347@gmail.com> Message-ID: | > {-# INLINE getInteger #-} | > getInteger = ... -- large definition that will be not inlined | > -- without pragma | > | > instance Binary Integer where | > get = getInteger A simpler version is > {-# INLINE getInteger #-} > getInteger = ... -- large definition that will be not inlined > -- without pragma > > get = getInteger Here, getInteger will be inlined in the RHS of get, but GHC doesn't see any reason that 'get' should be inlined. If you want that, add an INLINE pragma on get. The same thing should work in an instance decl, for the same reason, but I have not tried it recently. And, assuming it does work, it ought to be documented. If you check, and send me draft words, I'll add them to the user manual Simon From bulat.ziganshin at gmail.com Thu Nov 9 02:14:57 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 9 02:25:09 2006 Subject: subtle inlining problem In-Reply-To: References: <484242054.20061108100347@gmail.com> Message-ID: <1791671787.20061109101457@gmail.com> Hello Simon, Wednesday, November 8, 2006, 8:41:51 PM, you wrote: >> {-# INLINE getInteger #-} >> getInteger = ... -- large definition that will be not inlined >> -- without pragma >> >> get = getInteger > Here, getInteger will be inlined in the RHS of get, but GHC doesn't > see any reason that 'get' should be inlined. > If you want that, add an INLINE pragma on get. > The same thing should work in an instance decl, for the same > reason, but I have not tried it recently. And, assuming it does > work, it ought to be documented. If you check, and send me draft > words, I'll add them to the user manual ok, but i don't undertsand what you mean by "it does work"? should i check that without INLINE pragma it's not inlined and with pragma it's inlined? also, that you think about changing implementation to that i implied - any function equivalent to inlined function, should be also inlined? in terms of implementation complexity and whether it will be good or bad change? for my particular program (AltBinary lib) it will allow to remove a couple of INLINE pragmas. and if someone want to create not inlined version of some inlined function, he can easily write get=getInteger {-# NOINLINE get #-} -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Thu Nov 9 03:29:18 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 9 03:29:34 2006 Subject: subtle inlining problem In-Reply-To: <1791671787.20061109101457@gmail.com> References: <484242054.20061108100347@gmail.com> <1791671787.20061109101457@gmail.com> Message-ID: | > The same thing should work in an instance decl, for the same | > reason, but I have not tried it recently. And, assuming it does | > work, it ought to be documented. If you check, and send me draft | > words, I'll add them to the user manual | | ok, but i don't undertsand what you mean by "it does work"? should i | check that without INLINE pragma it's not inlined and with pragma it's | inlined? I meant that I'm not 100% sure that an INLINE pragma in an *instance declaration* will cause the method to be inlined. I think it works, but it'd be worth checking. | also, that you think about changing implementation to that i implied - | any function equivalent to inlined function, should be also inlined? Definitely not. It'd be a strange special case. What about get = id getInteger or get = id (id getInteger) Initially these don't look like "equivalent to inlined function" but they are. What about get = [getInteger] !! 1 Perhaps you could say that something magic happens when you, the programmer write x=y, and y has an INLINE pragma... but my instinct is to keep GHC's simple, rule. Simon From bulat.ziganshin at gmail.com Thu Nov 9 06:50:47 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 9 07:02:03 2006 Subject: subtle inlining problem In-Reply-To: References: <484242054.20061108100347@gmail.com> <1791671787.20061109101457@gmail.com> Message-ID: <10791451.20061109145047@gmail.com> Hello Simon, Thursday, November 9, 2006, 11:29:18 AM, you wrote: > I meant that I'm not 100% sure that an INLINE pragma in an > *instance declaration* will cause the method to be inlined. I think > it works, but it'd be worth checking. you may be sure - without this my deeply-classified Streams library will be never such fast :) once i lost INLINE pragma in the middle-level definition and found that execution becomes 200x slower :) altough really there are a several traps and i will try to document them - may be it will be even possible to fix them. but basically it works and it makes possible to write fast polymorhic code. believe it or not, we already widely use this feature: instance Monad IO where {-# INLINE return #-} {-# INLINE (>>) #-} {-# INLINE (>>=) #-} m >> k = m >>= \ _ -> k return x = returnIO x m >>= k = bindIO m k fail s = failIO s > Perhaps you could say that something magic happens when you, the > programmer write x=y, and y has an INLINE pragma... but my instinct is to keep GHC's simple, rule. my intuition says different but this is not very important, after all. i can include this as one more caveat in the above-mentioned list -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From maeder at tzi.de Thu Nov 9 08:28:36 2006 From: maeder at tzi.de (Christian Maeder) Date: Thu Nov 9 08:28:00 2006 Subject: ghc threaded1 test-cases under Solaris In-Reply-To: <20061108152157.GC32344@matrix.chaos.earth.li> References: <4546226F.3050504@tzi.de> <20061108152157.GC32344@matrix.chaos.earth.li> Message-ID: <45532D04.9010708@tzi.de> Hi, when running the test-suite I get plenty of the link errors (below). In order to resolve the missing symbols in Printer.thr_debug_o I was able to add -optl-L/usr/local/lib -optl-lbfd -optl-liberty to the ghc-6.6 command line. Note that "-L/usr/local/lib" is necessary, because otherwise the wrong libiberty.a file is found (namely that of gcc with a missing symbol "unlink_if_ordinary"). I don't know how to build this properly into the compiler (or a configure script). Cheers Christian /home/maeder/haskell/solaris/ghc-6.6/rts/libHSrts_thr_debug.a(Printer.thr_debug_ o): In function `DEBUG_LoadSymbols': /home/maeder/haskell/solaris/ghc-6.6/rts/Printer.c:997:0: undefined reference to `bfd_init' /home/maeder/haskell/solaris/ghc-6.6/rts/Printer.c:998:0: undefined reference to `bfd_openr' /home/maeder/haskell/solaris/ghc-6.6/rts/Printer.c:1002:0: undefined reference to `bfd_check_format_matches' collect2: ld returned 1 exit status From simonpj at microsoft.com Fri Nov 10 09:29:53 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 10 09:29:18 2006 Subject: [Haskell] Deferred instance declarations (serialization of existential boxes) In-Reply-To: <451ADA25.8070001@hot.ee> References: <4511D065.8050601@hot.ee><036EAC76E7F5EC4996A3B3C3657D411606A06D19@EUR-MSG-21.europe.corp.microsoft.com> <451ADA25.8070001@hot.ee> Message-ID: Misha I'm happy to tell you that your wish has been granted. I was able to implement the change you wanted (you called it deferred instance declarations) as part of an overhaul of the type-class machinery in GHC. I'll send out a more detailed message about this to ghc-users. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] | On Behalf Of Misha Aizatulin | Sent: 27 September 2006 21:08 | To: GHC Users Mailing List | Subject: Re: [Haskell] Deferred instance declarations (serialization of existential boxes) | | Simon Peyton-Jones wrote: | > Concerning your application | > | > | I am having a box like | > | > data Box = forall a. Cxt a => Box a | > | and want to write a Read instances for it. | > | > I don?t see how it helps to defer the Read instance. | | I would defer the instance declaration till the point where I know all | types that will ever go into the box (for instance in my Main module). | The Show instance of Box would write the representation of a together | with it's type (this means Cxt should contain at least Show and | Typeable). The Read instance will then contain something like | | ======================================================== | String aType <- lexP | | result <- case aType of | "[Int]" -> | (readPrec :: ReadPrec [Int]) >>= (return . Box) | "SomeOtherType" -> | (readPrec :: ReadPrec SomeOtherType) >>= (return . Box) | | -- | | _ -> error (aType ++ " cannot be read inside of Box") | ======================================================== | | Not very elegant of course, but it seems to be the only way to Read | existentials. | | > But I think the case is stronger for top-level constraints, and I will bear it in mind. | > If you would like to open a Trac feature request, please do so. | | Ok, I will. | | Cheers, | Misha | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Fri Nov 10 09:34:15 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 10 09:33:42 2006 Subject: Major type-class overhaul Message-ID: Dear GHC users, For some time I have been promising an overhaul of GHC's type inference machinery to fix the interactions between type classes and GADTs. I've just completed it (or at least I hope so). This message is just to summarise the programmer-visible changes, and to encourage you to give them a whirl. Of course, you'll need to compile the HEAD to do this; or get a nightly-build snapshot in a day or two's time. Needless to say, if you are using the HEAD for mission-critical stuff, proceed with caution. I don't guaranteed bug-free-ness. Simon This major patch adds implication constraints to GHC's type inference mechanism. (The name "implication constraint" is due to Martin Sulzmann.) >From a programmer point of view, there are several improvements 1. Complete(r) type inference ~~~~~~~~~~~~~~~~~~ GHC's type inference becomes complete (or perhaps more complete!) Particularly, Karl-Filip Faxen's famous example in "Haskell and principal types" (Haskell workshop 2003) would type check when the program text was written in one order, and then fail when the text was re-ordered. Now it works regardless. The test is tc218. 2. Lifting the "quantified-here" restriction ~~~~~~~~~~~~~~~~~~~~~~~~~ The restriction that every constraint in a type signature must mention at least one of the quantified type variables is lifted. So you can write f :: C Int => ... or g :: forall b. Eq a => ... This may seem odd, but the former was recently requested by a Haskell user; see this message: http://www.haskell.org/pipermail/glasgow-haskell-users/2006-September/011137.html 3. Dictionaries are packaged in data constructors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A very useful new feature is this. When a data type is declared in in GADT syntax, the context of the constructor is *required* when constructing *available* when matching For example data T a where T1 :: Num a => a -> T a T2 :: Bounded a => T a f :: T a -> a f (T1 x) = x+1 f T2 = maxBound Notice that f is not overloaded. The Num needed in the first branch is satisfied by the T1 pattern match; and similarly for the T2 pattern match. This feature has been often requested, becuase it allows you to package a dictionary into an ordinary (non-existential) data type, and be able to use it. NOTE: the Haskell 98 syntax for data type declarations data Num a => T a = T1 a behaves exactly as specified in H98, and *not* in the new way. The Num dictionary is *required* when constructing, and *required* when matching I think this is stupid, but it's what H98 says. To get the new behaviour, use GADT-style syntax, even though the data type being defined is does not use the GADT-ness. 4. Type classes and GADTs ~~~~~~~~~~~~~~~~~ The proper interaction between GADTs and type classes is now respected. For example: data GADT a where MkG :: Num a => a -> GADT [a] g :: forall b. Read b => GADT b -> String -> b g (MkG n) s = n : read s Inside the branch we know that b=[a], so the (Read b) dictionary is a (Read [a]) dictionary, which is why we can use the result of read in the tail of a cons. Functional dependencies and equality predicates ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~