Re: [Haskell] Better Exception Handling
John Goerzen wrote: Python can work that way, but also adds another feature: try: blah moreblah finally: foo And in Haskell we have catch(Dyn), bracket, and finally. Are these not enough? I hadn't been aware of finally. That does seem to help. One of the things I like about exceptions in haskell is that there's relatively little magic, if a function like finally isn't there, you can implement it yourself. m `finally` f = do r - m `catch` (\e - f throw e) f return r (I'm ignoring asynchronous exceptions for now, see the code for Control.Exception for details) And I find bracket quite useful, it nicely captures a concept you have to code by hand in many other languages. And bracket is also a function you could have implemented yourself, if it hadn't been available. /Peter ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Release Candidate for 6.2.1 available
Sigbjorn Finne wrote: An installer for Windows users can now also be found in that directory. - Original Message - From: Simon Marlow [EMAIL PROTECTED] Subject: RE: Release Candidate for 6.2.1 available ghc-6.2.20040304 and later are release candidates for 6.2.1 Get them from here: http://www.haskell.org/ghc/dist/stable/dist/ This is your last chance to test... I'm going to freeze the release on Monday (15 March). If installed under a directory with spaces, it fails to produce object files. 6.2 has the same problem, 6.0.1 works. End of output from ghc -v --make t.hs: ... ... C:\ghc\ghc 6.2.1\gcc -BC:\ghc\ghc 6.2.1\gcc-lib/ -I. -I. -c C:\DOCUME~1\peter\ LOCALS~1\Temp\ghc536.s -o t.o Failed: C:\ghc\ghc 6.2.1\gcc -BC:\ghc\ghc 6.2.1\gcc-lib/ -I. -I. -c C:\DOCUME~ 1\peter\LOCALS~1\Temp\ghc536.s -o t.orawSystem: does not exist (No such file or directory) *** Deleting temp files Deleting: C:/DOCUME~1/peter/LOCALS~1/Temp/ghc536.s /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Per-type function namespaces
[EMAIL PROTECTED] wrote: I've had an idea stewing in my head to do with per-type function namespaces, . The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. So, in the above example, instead of writing addToFM fm ..., we could instead associate an 'add' function with the FiniteMap type, so we could write fm.add ... instead. Provided that fm's type is monomorphic, it should be possible to call the 'correct' add function; if we defined another 'add' function that's associated with the Set type, that will only get called if the 'x' in x.add is of type :: Set. So, like OO languages which inherently give separate namespaces to their different objects, here we give separate namespaces to different (monomorphic) types. In this case, if one simply writes add instead of x.add, the compiler throws an error, because there is no 'add' function defined in the default namespace; add is only defined when a programmer writes x.add where x :: FiniteMap or x :: Set[1]. Wouldn't something like Koenig Lookup in C++ solve this problem as well, without the need for a new (strange) syntax? That is, a function is looked up in the namespaces of its arguments as well as in the normal places. So add fm k v where fm :: FiniteMap, x :: Int, v :: String would look for add in the modules where FiniteMap, Int and String was defined. However, both of these methods means that we have to know the types of the arguments to be able to resolve names, probably forcing us to write a lot more type signatures than otherwise. It feels a bit like we're just trading one problem for another.. (lots of qualified names vs. lots of type signatures). But it might be worth it.. Would Koenig lookup (or something similar) be feasable in Haskell? Or would it just lead to unnecessary complexity? Name lookup in C++ is not exactly simple, so it might be a bad place to borrow ideas from.. ;) /Peter ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Threaded foreign functions calling back.
Hi, I'd like to use a C-library which calls back into the haskell program, potentially from different threads at the same time. That is, the following calling sequence takes place: (haskell) Calls C via foreign import. (c) Creates threads, which in turn calls back into haskell via foreign exported functions. Is this supported in ghc? Some simple tests suggests that it does work, at least I don't get any crashes, if ghc is compiled with --enable-threaded-rts. But is this intended to work or am I just lucky? /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.0: warning!
On Mon, Jul 07, 2003 at 03:49:38PM +0100, Simon Peyton-Jones wrote: Some of you have already discovered that GHC 6.0 has a nasty bug: if you go ghci foo\Baz.hs and there is any error at all in Baz.hs, then GHC deletes the source file! This seems like excessive punishment for a type error. And it doesn't even require a type error as an excuse for punishment! .. if the source file is specified as ./file.hs Example: $ echo module T where T.hs ghc --make ./T.hs -v ... Deleting: ./T.hs This is on linux, don't know about windows.. /Peter ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.0: warning!
On Mon, Jul 07, 2003 at 03:49:38PM +0100, Simon Peyton-Jones wrote: Some of you have already discovered that GHC 6.0 has a nasty bug: if you go ghci foo\Baz.hs and there is any error at all in Baz.hs, then GHC deletes the source file! This seems like excessive punishment for a type error. And it doesn't even require a type error as an excuse for punishment! .. if the source file is specified as ./file.hs Example: $ echo module T where T.hs ghc --make ./T.hs -v ... Deleting: ./T.hs This is on linux, don't know about windows.. /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc on alpha-linux?
Hi, I've made a number of rather unsuccessful attempts at compiling ghc on an alpha machine (running linux).. The best i got was a segfaulting compiler by compiling (and hacking) the unregisterised hc-files for 4.08.2 found on haskell.org. (I probably did something stupid when I tried to get it to compile) Which version is the best starting point? Generating unregisterised files from 6.0 or trying to get 4.08.2 to work? Or something else? Or does anyone have working binaries? That would be wonderful ;) /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: state of ghc6 on sparc
On Wed, Jun 18, 2003 at 06:09:14PM +0200, Josef Svenningsson wrote: The only thing that I don't like is that the dist isn't compiled with readline. It makes working in ghci a nightmare (I need to use backspace often...). A nice workaround for programs not supporting readline is to use a line-editing wrapper such as ledit, which can be found here: ftp://ftp.inria.fr/INRIA/Projects/cristal/Daniel.de_Rauglaudre/Tools/ It also has the additional feature that you can save the history between sessions (which would be a nice addition to ghci..) /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
isEmptyChan blocks?
Hi, I noticed that isEmptyChan blocks if the channel is already waited on by readChan, is this the intended behaviour? At least I was a bit surprised by a blocking predicate.. Example program: import Control.Concurrent main = do ch - newChan let loop = do threadDelay 100 -- make sure readChan executes isEmptyChan ch print not reached loop forkIO loop readChan ch This happens both with 5.04.2 and 6.0, on linux. When compiled, Fail: thread blocked indefinitely is printed, ghci just blocks. The corresponding program with MVars doesn't block. /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network/Notwork?
Hi, On Mon, Mar 17, 2003 at 07:01:20PM +, C.Reinke wrote: Windows only, of course!-) On Solaris, I never even noticed there might be a problem (it seems to work even without acknowledgment or hFlush..). One explanation could be that hClose ends up calling close instead of closesocket under windows. I tried your example, and got the same error (under win2k). But by using a slightly modified hClose, everything seemed to work well. In base/GHC/Handle.hs there is a preprocessor conditional on mingw32_TARGET_OS which seems to be undefined in the distributed compilation (I used 5.04.3). By explicitly calling closeFd there instead of c_close it works for me. Perhaps it should trigger on WITH_WINSOCK instead? /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI C++ Cygwin
On Fri, Jan 10, 2003 at 02:11:35PM +0100, Koen Claessen wrote: The C++ stuff compiles fine (using Cygwin's g++). The Haskell stuff compiles just fine (using Win Ghc). However, at linking time I get the following error: - undefined reference to '_impure_ptr' - undefined reference to 'operator delete(void*)' - undefined reference to 'vtable for ___cxxabiv1::__blahblah' These are all things that C++ uses internally. I think the problem is that I used Cygwin's g++ compiler and that Ghc uses Mingwin's gcc compiler to compile and link. It is possible to trick ghc into using cygwin's gcc in mingw-mode, the following steps works for me to do that: * compile the c++-stuff with g++ -mno-cygwin * copy /usr/bin/gcc.exe to c:/ghc/ghc-5.04.2/gcc.exe * rename c:/ghc/ghc-5.04.2/gcc-lib to something else (ghc feeds a -B option to gcc, which we cannot(?) override) * compile with ghc -optl -mno-cygwin -lstdc++ (add -optc -mno-cygwin if -fvia-C is used) (i.e. we would like to use /usr/bin/gcc -mno-cygwin as the linker) I think it should be possible to use -pgml instead of replacing the binary, but that didn't work for me.. However, I have tried to recompile the C++ libraries using the Mingwin C++ compiler but it starts throwing pages of error messages at me. However, the method above doesn't help if you really need cygwin for your c++-library, which you seem to do? /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: small problem with ghc(i) on Windows
On Mon, Dec 16, 2002 at 01:26:31PM +0100, Jerzy Karczmarczuk wrote: Apparently the form (#) is considered illegal. It works on my Linux. On Win2000: parse error on input ')' You don't happen to use -fglasgow-exts on windows? That gives parse error on the sequence (# I guess it's related to unboxed tuples using that notation.. I've also found this a bit annoying, is it fixable? /Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
