April 2004 - Glasgow-haskell-users

RE: sizeFM type
by Simon Marlow 26 Apr '04

26 Apr '04

On 26 April 2004 02:49, S. Alexander Jacobson wrote: > Sun and Dell both sell 64-bit boxes. But the core > question is why have two different types at all? > > This issue is timely because I just got an error > in code that looks vaguely like: > > h<-openFile "foo" AppendMode > pos <- hFileSize h > hPutStr $ show something > hClose h > content <- readFile "foo" > return $ take pos content > > This code produces an error because (madness!): > > hFileSize::Handle -> IO Integer > take::forall a. Int -> [a]->[a] > > I have to assume conversion between files and > lists is not all that rare even in beginner code. > > Note: I don't really care whether everything is > 64bit Int or Integer. I just find having to care > about this point in such trivial code ridiculous. Probably if the take function were being designed today, there would be no question about whether it should take Int or Integer. Back then, the Integer overhead was high enough to worry about, and lots of benchmark programs used take/drop. Nowadays, we can't really change the type of take without breaking just about every Haskell program. Cheers, Simon

2 1

RE: Safe use of unsafeCoerce?
by Simon Marlow 26 Apr '04

26 Apr '04

On 24 April 2004 17:38, Duncan Coutts wrote: > All, > > I'm after advice on whether the following example is a safe use of > unsafeCoerce, and if it is safe, if it's worth it. > > In summary, if the following is ok: > > castFooToBar :: Ptr Foo -> Ptr Bar > castFooToBar = castPtr > > then is the following ok? > > newtype Foo' = Foo' (Ptr Foo) > newtype Bar' = Bar' (Ptr Bar) > > castFooToBar' :: Foo' -> Bar' > castFooToBar' = unsafeCoerce If the runtime representation of Foo' and Bar' is the same, then this is safe. In this case the runtime representation is the same, so you're ok. However, it might not always be a good idea, because the compiler's optimiser gets a bit stuck when it sees an unsafeCoerce. I'd like to be a bit more specific, but I'm not sure I can remember the specific example. On the other hand, Happy makes extensive use of unsafeCoerce in its generated code (when you use -c), so in some cases the benefits can definitely outweigh the costs. > Here's the context/motivation: [ snip ] > toGObject :: GObjectClass o => o -> GObject > toGObject = unsafeCoerce > > fromGObject :: GObjectClass o => GObject -> o > fromGObject = unsafeCoerce > > So, the point is we can remove entirely the class dictionary that > otherwise has to be carried round for every object and the upcasting & > downcasting functions no longer need to do slow dictionary lookups > when all they are really doing is casting C pointers. > > So is it a) safe? b) kosher? I think so. On the other hand, you might want to look at using the trick that wxHaskell uses for encoding the widget hierarchy, which also has zero runtime cost. Cheers, Simon

1 0

Re: ghc by ftp
by Serge D. Mechveliani 25 Apr '04

25 Apr '04

Thank you, ghc/dist/ works. ----------------- Serge Mechveliani mechvel(a)botik.ru On Sun, Apr 25, 2004 at 09:26:23PM +1000, Donald Bruce Stewart wrote: ... > > I need to download fresh GHC, > > and my (old) netscape brouser fails to read the WWW page > > http://www.haskell.org/ghc > > > > ("bus error", probably, this page has changed something). > > ... > Your browser mightn't crash on this URL: > > http://www.haskell.org/ghc/dist/ > ...

1 0

ghc by ftp
by Serge D. Mechveliani 25 Apr '04

25 Apr '04

Dear GHC providers, I need to download fresh GHC, and my (old) netscape brouser fails to read the WWW page http://www.haskell.org/ghc ("bus error", probably, this page has changed something). If possible, where and how can one inspect the GHC place via anonymous ftp ? For I was able to see by ftp only old GHC versions. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Typeable and 'forall' in data constructors
by Simon Peyton-Jones 22 Apr '04

22 Apr '04

PS: You can use deriving( Typeable )even when there's an existential. It's just deriving( Data ) you have to do by hand. | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Akos Korosmezey | Sent: 21 April 2004 13:23 | To: glasgow-haskell-users(a)haskell.org | Subject: Typeable and 'forall' in data constructors | | I am tying to write a Term class with function application: | | data (Typeable a) => Term a = | Const a | | LVar Int | | forall b. Typeable b => App (Term (b -> a)) (Term b) | | Lam (Term a) | | Because 'forall' is present, ghc refuses to derive Typeable and Data for | Term. I tried to implement them: | | instance (Typeable a) => Typeable (Term a) where | typeOf w = mkAppTy (mkTyCon "Term.Term") [typeOf (undefined :: a)] | | instance (Typeable a) => Data (Term a) where | toConstr (Const _) = mkConstr 1 "Const" Prefix | toConstr (LVar _) = mkConstr 3 "LVar" Prefix | toConstr (App _ _) = mkConstr 4 "App" Prefix | toConstr (Lam _) = mkConstr 5 "Lam" Prefix | | But ghc 6.2.1 returns with error on the line 'toConstr (App _ _)...': | parse error on input `b'. How can this be fixed? | Thank you | | Akos Korosmezey | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Typeable and 'forall' in data constructors
by Simon Peyton-Jones 22 Apr '04

22 Apr '04

The code you gave looks fine to me, and indeed compiled. But to fill out the instance declaration you'll need to a) make Data the context in the App constructor b) make Data the context in the instance Data (Term a) declaration Also there is absolutely no point in the (Typeable a) context for the data declaration, so I dropped it. Here's a filled-out version that works: Simon module Foo where import Data.Typeable import Data.Generics data Term a = Const a | LVar Int | forall b. Data b => App (Term (b -> a)) (Term b) | Lam (Term a) instance (Typeable a) => Typeable (Term a) where typeOf w = mkAppTy (mkTyCon "Term.Term") [typeOf (undefined :: a)] instance (Data a) => Data (Term a) where toConstr (Const _) = mkConstr 1 "Const" Prefix toConstr (LVar _) = mkConstr 3 "LVar" Prefix toConstr (App _ _) = mkConstr 4 "App" Prefix toConstr (Lam _) = mkConstr 5 "Lam" Prefix gmapT f (Const a) = Const (f a) gmapT f (LVar i) = LVar (f i) gmapT f (App t1 t2) = App (f t1) (f t2) gmapT f (Lam t) = Lam (f t) | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Akos Korosmezey | Sent: 21 April 2004 13:23 | To: glasgow-haskell-users(a)haskell.org | Subject: Typeable and 'forall' in data constructors | | I am tying to write a Term class with function application: | | data (Typeable a) => Term a = | Const a | | LVar Int | | forall b. Typeable b => App (Term (b -> a)) (Term b) | | Lam (Term a) | | Because 'forall' is present, ghc refuses to derive Typeable and Data for | Term. I tried to implement them: | | instance (Typeable a) => Typeable (Term a) where | typeOf w = mkAppTy (mkTyCon "Term.Term") [typeOf (undefined :: a)] | | instance (Typeable a) => Data (Term a) where | toConstr (Const _) = mkConstr 1 "Const" Prefix | toConstr (LVar _) = mkConstr 3 "LVar" Prefix | toConstr (App _ _) = mkConstr 4 "App" Prefix | toConstr (Lam _) = mkConstr 5 "Lam" Prefix | | But ghc 6.2.1 returns with error on the line 'toConstr (App _ _)...': | parse error on input `b'. How can this be fixed? | Thank you | | Akos Korosmezey | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: GHC 6.2.1 compilation fails when compiling FFI code with -pro f or -O2
by Bayley, Alistair 21 Apr '04

21 Apr '04

Sorry for the stupidity... just found the -I<dir> option... Although it is a bit frustrating when an FFI program that used to compile stops when you add supposedly "harmless" options such as -O or -prof. Might be worth adding a section to the FFI section of the manual about using the -I<dir> flag when compiling via C, as -I<dir> is not needed when you compile with native code generation. And a mention in the FFI section that -prof and -O will change the compilation strategy from native to via-C (thus possibly requiring the addition of the -I<dir> flag) would be nice, although I realise that's duplicating information available elsewhere. (Actually, compiling via C has been valuable for me because the C compiler moaned about a foreign function being called with too few args, which was the result of an incorrect "foreign import" declaration i.e. the C compiler found a bug in my Haskell code, which the GHC native code-generator wouldn't have picked up. Plus it gives warnings on other dodgy things I'm doing. Better fix 'em...) Alistair. > -----Original Message----- > From: Bayley, Alistair [mailto:Alistair_Bayley@ldn.invesco.com] > > > The "oci.h" file in question is located in > c:\orant817\oci\include, and > oci.dll is located in c:\orant817\bin. When I compiled with > -prof I tried > adding -#include c:\orant817\oci\include\oci.h, but this > produces the output > below, where files included by oci.h can't be found. The > oci.h file is at > the root of quite a large .h include tree; do I have to > specify every .h > file in this tree with -#include? ----------------------------------------- ***************************************************************** 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. *****************************************************************

1 0

Typeable and 'forall' in data constructors
by Akos Korosmezey 21 Apr '04

21 Apr '04

I am tying to write a Term class with function application: data (Typeable a) => Term a = Const a | LVar Int | forall b. Typeable b => App (Term (b -> a)) (Term b) | Lam (Term a) Because 'forall' is present, ghc refuses to derive Typeable and Data for Term. I tried to implement them: instance (Typeable a) => Typeable (Term a) where typeOf w = mkAppTy (mkTyCon "Term.Term") [typeOf (undefined :: a)] instance (Typeable a) => Data (Term a) where toConstr (Const _) = mkConstr 1 "Const" Prefix toConstr (LVar _) = mkConstr 3 "LVar" Prefix toConstr (App _ _) = mkConstr 4 "App" Prefix toConstr (Lam _) = mkConstr 5 "Lam" Prefix But ghc 6.2.1 returns with error on the line 'toConstr (App _ _)...': parse error on input `b'. How can this be fixed? Thank you Akos Korosmezey

1 0

GHC 6.2.1 compilation fails when compiling FFI code with -prof or -O2
by Bayley, Alistair 21 Apr '04

21 Apr '04

I have an FFI program which compiles fine with GHC 6.2.1 under standard compilation options (i.e. no optimisation etc), but not with -O2 or -prof. With -prof/-O2 GHC compiles via C, and this seems to be causing the problem. With -prof I get these error messages: Compiling Database.Oracle.OCIFunctions ( ./Database/Oracle/OCIFunctions.lhs, ./Database/Oracle/OCIFunctions.o ) C:/TEMP/ghc202.hc:5:17: oci.h: No such file or directory C:/TEMP/ghc202.hc: In function `r2Zg_entry': C:/TEMP/ghc202.hc:133: warning: implicit declaration of function `OCIStmtFetch' C:/TEMP/ghc202.hc: In function `r2Zi_entry': C:/TEMP/ghc202.hc:337: warning: implicit declaration of function `OCIStmtExecute' ...etc... With -O2 I get these: Compiling Database.Oracle.OCIFunctions ( ./Database/Oracle/OCIFunctions.lhs, ./Database/Oracle/OCIFunctions.o ) C:/TEMP/ghc311.hc:5:17: oci.h: No such file or directory C:/TEMP/ghc311.hc: In function `DatabaseziOracleziOCIFunctions_zdwccall_entry': C:/TEMP/ghc311.hc:1295: warning: implicit declaration of function `OCIStmtFetch' C:/TEMP/ghc311.hc: In function `DatabaseziOracleziOCIFunctions_zdwccall1_entry': C:/TEMP/ghc311.hc:1480: warning: implicit declaration of function `OCIStmtExecute' ...etc... I've used these command line options for normal (no -prof or -O) compilation: -Lc:\orant817\bin -loci The "oci.h" file in question is located in c:\orant817\oci\include, and oci.dll is located in c:\orant817\bin. When I compiled with -prof I tried adding -#include c:\orant817\oci\include\oci.h, but this produces the output below, where files included by oci.h can't be found. The oci.h file is at the root of quite a large .h include tree; do I have to specify every .h file in this tree with -#include? My ghc command: ghc -v -Wall -ddump-hi -prof -Lc:\orant817\bin -loci -#include c:\orant817\oci\include\oci.h -fasm -o ociffi --make Main.lhs Output: <snipped> *** CodeOutput: *** C Compiler c:\ghc\ghc-6.2.1\gcc -Bc:\ghc\ghc-6.2.1\gcc-lib/ -x c C:\TEMP\ghc319.hc -o C:\TEMP\ghc319.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -mno-omit-leaf-frame-pointer -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=602 -DPROFILING -ffloat-store -I . -I c:/ghc/ghc-6.2.1/include -I c:/ghc/ghc-6.2.1/include/mingw Reading specs from c:/ghc/ghc-6.2.1/gcc-lib/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=f77,c++,objc,ada --disable-win32-registry --disable-shared Thread model: win32 gcc version 3.2 (mingw special 20020817-1) c:\ghc\ghc-6.2.1\gcc-lib\cc1.exe -lang-c -v -I . -I c:/ghc/ghc-6.2.1/include -I c:/ghc/ghc-6.2.1/include/mingw -iprefix c:\ghc\ghc-6.2.1\../lib/gcc-lib/mingw32/3.2/ -isystem c:/ghc/ghc-6.2.1/gcc-lib/include -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -D_WIN32 -D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ -DWINNT -D_X86_=1 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__WIN32 -D__WINNT -Asystem=winnt -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__fastcall=__attribute__((__fastcall__)) -D_stdcall=__attribute__((__stdcall__)) -D_cdecl=__attribute__((__cdecl__)) -D_fastcall=__attribute__((__fastcall__)) -D__declspec(x)=__attribute__((x)) -DDONT_WANT_WIN32_DLL_SUPPORT -DSTOLEN_X86_REGS=4 -D__GLASGOW_HASKELL__=602 -DPROFILING C:\TEMP\ghc319.hc -quiet -dumpbase ghc319.hc -mno-omit-leaf-frame-pointer -O -Wimplicit -version -fno-defer-pop -fomit-frame-pointer -fno-builtin -ffloat-store -o C:\TEMP\ghc319.raw_s GNU CPP version 3.2 (mingw special 20020817-1) (cpplib) (80386, BSD syntax) GNU C version 3.2 (mingw special 20020817-1) (mingw32) compiled by GNU C version 3.2. ignoring nonexistent directory "c:/ghc/lib/gcc-lib/mingw32/3.2/../../../../include" ignoring nonexistent directory "c:/ghc/lib/gcc-lib/mingw32/3.2/include" ignoring nonexistent directory "c:/ghc/lib/gcc-lib/mingw32/3.2/../../../../mingw32/include" ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2/../../../../include" ignoring nonexistent directory "/mingw/include" ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2/include" ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/include" ignoring nonexistent directory "/usr/local/mingw32/include" #include "..." search starts here: #include <...> search starts here: . c:/ghc/ghc-6.2.1/include c:/ghc/ghc-6.2.1/include/mingw c:/ghc/ghc-6.2.1/gcc-lib/include End of search list. In file included from C:/TEMP/ghc319.hc:5: c:/orant817/oci/include/oci.h:261:23: oratypes.h: No such file or directory c:/orant817/oci/include/oci.h:265:20: ocidfn.h: No such file or directory In file included from C:/TEMP/ghc319.hc:5: c:/orant817/oci/include/oci.h:1419: parse error before "OCILobOffset" c:/orant817/oci/include/oci.h:1419: warning: type defaults to `int' in declaration of `OCILobOffset' c:/orant817/oci/include/oci.h:1419: warning: data definition has no type or storage class c:/orant817/oci/include/oci.h:1429: parse error before "OCILobLength" c:/orant817/oci/include/oci.h:1429: warning: type defaults to `int' in declaration of `OCILobLength' c:/orant817/oci/include/oci.h:1429: warning: data definition has no type or storage class c:/orant817/oci/include/oci.h:1539: parse error before "OCIPicklerTdsElement" c:/orant817/oci/include/oci.h:1539: warning: type defaults to `int' in declaration of `OCIPicklerTdsElement' c:/orant817/oci/include/oci.h:1539: warning: data definition has no type or storage class c:/orant817/oci/include/oci.h:1620: parse error before "OCIWchar" c:/orant817/oci/include/oci.h:1620: warning: type defaults to `int' in declaration of `OCIWchar' c:/orant817/oci/include/oci.h:1620: warning: data definition has no type or storage class c:/orant817/oci/include/oci.h:1648:18: oci1.h: No such file or directory c:/orant817/oci/include/oci.h:1652:17: oro.h: No such file or directory c:/orant817/oci/include/oci.h:1656:17: ori.h: No such file or directory c:/orant817/oci/include/oci.h:1660:17: orl.h: No such file or directory c:/orant817/oci/include/oci.h:1664:17: ort.h: No such file or directory c:/orant817/oci/include/oci.h:1668:21: ociextp.h: No such file or directory c:/orant817/oci/include/oci.h:1672:20: ociapr.h: No such file or directory c:/orant817/oci/include/oci.h:1673:19: ociap.h: No such file or directory c:/orant817/oci/include/oci.h:1680:80: oci8dp.h: No such file or directory c:/orant817/oci/include/oci.h:1684:21: ociextp.h: No such file or directory C:/TEMP/ghc319.hc:6:17: oci.h: No such file or directory C:/TEMP/ghc319.hc: In function `r2Zg_entry': C:/TEMP/ghc319.hc:64: warning: implicit declaration of function `OCIStmtFetch' <snipped> 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. *****************************************************************

1 0

RE: turn off let floating
by Simon Marlow 21 Apr '04

21 Apr '04

> So I have code like: > > {-# NOINLINE count #-} > count :: IORef Int > count = unsafePerformIO $ newIORef 0 > > {-# NOINLINE getCount #-} > getCount :: (Int -> a) -> a > getCount f > = let nextCount > = (unsafePerformIO $ > do oldCount <- readIORef count > let newCount = oldCount + 1 > writeIORef count newCount > return oldCount) > in seq nextCount (f nextCount) > > It seems to work okay. > > However, if you have any suggestions about how to make a FAST > global counter > I would be very glad to hear it. From profiling it seems like > this code > is a little expensive (also it is called quite frequently). You could try the FastMutInt module from GHC (ghc/compiler/utils/FastMutInt.hs) to speed things up. Unfortunately unsafePerformIO has some unavoidable overhead: it can't be inlined because we don't want the compiler to see its definition. Cheers, Simon

7 8