[ ghc-Bugs-766386 ] Error in compile deletes the sourcefile
Bugs item #766386, was opened at 2003-07-05 16:20 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=766386group_id=8032 Category: Compiler Group: 6.0 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Error in compile deletes the sourcefile Initial Comment: If I try to compile a source file (any .hs file) and the compiler returns an error (any error), the source file gets deleted. The compiler however, returns me to the Prelude cursor and still accepts commands To recompile, I have to save the file again from my editor. When the compilation is successful, the sourcefile is still there. I'm using the latest GHCi 6.0 on a WinXP sp 1 machine. best regards Jon Malmquist [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2003-07-21 09:50 Message: Logged In: YES user_id=48280 Will be fixed in 6.0.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=766386group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -fno-implicit-prelude -prof bug on x86
In article [EMAIL PROTECTED], I wrote: $ ghc -fno-implicit-prelude -prof -c M.hs /tmp/ghc4124.hc:5: `NULL' undeclared here (not in a function) /tmp/ghc4124.hc:5: initializer element is not constant /tmp/ghc4124.hc:5: (near initialization for `M_CAFs_cc_ccs[0].prevStack') /tmp/ghc4124.hc:5: `NULL' undeclared here (not in a function) /tmp/ghc4124.hc:5: initializer element is not constant /tmp/ghc4124.hc:5: (near initialization for `M_CAFs_cc_ccs[0].indexTable') Workaround: pass -optc-DNULL=0 to GHC. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -frules-off
Trouble is, GHC does not distinguish specialisation rules in any way. -fno-specialisation says not to *generate* any specialisation rules; -frules-off says not to *apply* any rules. I suppose you are distinguishing specialisation rules by their name -- whether they start SPEC That'll work, but I'm disinclined to change the compiler unless more people yell. I'll document -frules-off a bit more though Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Kirsten Chevalier | Sent: 17 July 2003 07:29 | To: [EMAIL PROTECTED] | Subject: -frules-off | | Not exactly a bug, but -frules-off doesn't do exactly what I would expect -- | it effectively disables specialization, whereas it would be useful (to me, | anyway) for it to disable user-defined rules while still applying rules | generated by the compiler, such as specialization rules. Since there's | another option that disables specialization (I think), it would seem | sensible for -frules-off to work that way. I have a fix that involves | changing activeRule (in simplify/SimplMonad.lhs) back to the way it was | before and changing lookupRule (in specialise/Rules.lhs) to check whether | opt_RulesOff is true, and, if so, only return the matching rule if it's a | SPEC rule, but undoubtedly there's a better way. | | -- | Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC 6 for Mac OS X: fix for package util/readline
On Mac OS X GHCi 6.0 complains about a missing symbol when trying to load package util. Wolgang Thaller told me the cause of this bug: The problem was that there was a file called HsReadline.c. The corresponding object file, HsReadline.o, replaced HSreadline.o on the Mac's case-insensitive file system. So the actual problem is a broken readline package, which is used by util. The bug is fixed in the next release (6.0.1) and in CVS. For those who don't feel like compiling CVS-sources, or waiting for the next release; below is a quick fix. A working HSreadline.o is created from the libHSreadline.a file using the -g option of ghc-pkg. 1) set environment variable libdir to ghc-6's directory: setenv libdir /usr/local/lib/ghc-6.0/ 2) cp $libdir/libHSreadline.a $libdir/libHSreadline_p.a /tmp/ 3) create a config file for package readline: ghc-pkg -s readline /tmp/readline.conf 4) cd /tmp 5) remove the package readline from ghc: ghc-pkg -r readline 6) add package again and let ghc-pkg create the ghci library: ghc-pkg -g -a -i /tmp/readline.conf For step 5/6 you may need root-access, use su or sudo Arthur ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -fno-implicit-prelude -prof bug on x86
In article [EMAIL PROTECTED], I wrote: $ ghc -fno-implicit-prelude -prof -c M.hs /tmp/ghc4124.hc:5: `NULL' undeclared here (not in a function) /tmp/ghc4124.hc:5: initializer element is not constant /tmp/ghc4124.hc:5: (near initialization for `M_CAFs_cc_ccs[0].prevStack') /tmp/ghc4124.hc:5: `NULL' undeclared here (not in a function) /tmp/ghc4124.hc:5: initializer element is not constant /tmp/ghc4124.hc:5: (near initialization for `M_CAFs_cc_ccs[0].indexTable') Workaround: pass -optc-DNULL=0 to GHC. Fixed, thanks. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: case-eta-expansion
Not quite sure what you mean by case eta expansion. Eta expansion is certainly still done, but only on 'let' right-hand-sides, by SimplUtils.tryEtaExpansion. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of David Sabel | Sent: 18 July 2003 14:02 | To: [EMAIL PROTECTED] | Subject: case-eta-expansion | | Hi, | | Can someone tell me, where exactly (in the code of ghc5.04.3) | the case-eta-expansion is performed, I searched | the modules of the simplifier, but didn't find this transformation. | | Or is it no longer performed in ghc5.04.3? | | Thanks, | | David | | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: URGENT: INFORMATION ABOUT WASH, GHC, CGI AND HSP
(Your caps-lock key seems to be stuck :-) You should give more information, like the error messages you received. Did the installation of Wash etc complete successfully? Did the example programs compile? (They will produce exes.) I recently (2-3 weeks ago) downloaded Wash and installed it on a W2K box, with GHC6. I followed the (brief) instructions on the website (including editing quite a few makefiles) and also: -- commented a reference to a non-existent Haskell source file in the makefile -- added some depedencies (I forget for exactly which files) to a makefile I determined what makefiles needed editing from the make error messages. If you're not familiar with make then you will struggle. Note that you need cygwin (or something that gives you make). You don't need hmake (unless you plan to use the CGIGraphics module, apparently). So after fixing some of these minor build issues, the whole thing built, and compiled the example programs. These worked perfectly when installed in my Apache cgi-bin. -Original Message- From: Gerardo Valeri [mailto:[EMAIL PROTECTED] Sent: 20 July 2003 21:40 To: [EMAIL PROTECTED] Subject: URGENT: INFORMATION ABOUT WASH, GHC, CGI AND HSP HI! WE ARE A GROUP OF STUDENTS TRYING TO MAKE A WEB APPLICATTION USING HSP, CGI AND WASH (WEB AUTHORING SYSTEM HASKELL). WE DOWNLOADED WASH, AND GHC COMPILER. WE COMPILED THE WHOLE APPLICATION WITH GHC BUT WE NEED TO GENERATE A .EXE FROM WASH AND WE HAVE BEEN UNSUCCESSFUL. WE ARE WORKING ON A WINDOWS PLATFORM. WE COMPILED THE FOUR MODULES FROM WASH: UTILITY, WASHHTML, WASHCGI AND WASHMAIL, WITHOUT BEING ABLE TO CREATE A .EXE FROM THEM. WE REALLY APPRECIATE ANY SUGGESTION. THANK YOU GERARDO * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: case-eta-expansion
- Original Message -
From: Simon Peyton-Jones [EMAIL PROTECTED]
To: David Sabel [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, July 21, 2003 9:53 AM
Subject: RE: case-eta-expansion
Not quite sure what you mean by case eta expansion.
I mean this transformation:
case e of {p1 - e1,...,pn - en}
=== \y - case e of {p1 - e1 y, ..., pn - en y}
which is described in Santos' PhD thesis as a special
form of eta-expansion which is done in 'special' situations.
Eta expansion is certainly still done, but only on 'let'
right-hand-sides, by SimplUtils.tryEtaExpansion.
Ok, thanks
David
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
| On Behalf Of David Sabel
| Sent: 18 July 2003 14:02
| To: [EMAIL PROTECTED]
| Subject: case-eta-expansion
|
| Hi,
|
| Can someone tell me, where exactly (in the code of ghc5.04.3)
| the case-eta-expansion is performed, I searched
| the modules of the simplifier, but didn't find this transformation.
|
| Or is it no longer performed in ghc5.04.3?
|
| Thanks,
|
| David
|
|
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building on Mac OS X
Sean Seefried [EMAIL PROTECTED] wrote: Dear GHC users on the Mac, I'm addressing this primarily to Wolfgang but also to anyone who has built GHC HEAD successfully on Mac OS X. I'm having difficulty doing it myself and I was just wondering if someone could put together a small set of instructions for building it. If you have a set of build scripts that would be even better. I'll be getting my Powerbook back from repairs tomorrow, and I'll have to install everything from scratch anyway; that's a perfect occasion to write up accurate instructions. Stay tuned! Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: User-Defined Operators (ad-hoc overloading)
Mere overload resolution (over monomorphic types) is not NP-hard. (This is only a common misconception.) I can only repeat my above sentence. No, but as you note below, the interesting cases are. Most of the more interesting number-like types are polymorphic (e.g. Complex, Ratio). This kind of overloading is no cause for exponentiell behaviour, if it's either solved by type class overloading or by monomorphic overload resolution. (Only let-polymorphism is hard.) The question is not is it theoretically slow? The question is are you ever likely to see the worst-case behaviour if you're not actively looking for it, or otherwise doing something dubious? I agree with this statement, in fact this argument was used to employ an exponentiell algorithm (I think Cormacks's algorithm in ADA, below) that is fast in practice. Remember that the situation we're looking at is that there are a small number of operators (e.g. those which work on number-like types) which people want to heavily overload. A program which used a mixture of these types could easily tickle exponential behaviour quite quickly if the programmer is not careful. Plus, what would cause this behaviour is not their _use_ as such, but rather the number of modules imported which have these overloaded operators defined. Again, this standard case is no problem for overload resolution (unless implemented too naively.) Cormack's algorithm will solve such cases fast by feeding in the expected result type. Some books on compilers explain overload resolution by (two, set-valued) attributes. Such an algorithm is also not exponentiell! I admit the combination of overload resolution and polymorphism is not simple, but Haskell has solved it in a certain way with type classes! Cheers Christian See: T.Pennello, F.DeRemer, and R.Meyers: A simplified Operator Identification Scheme for ADA, 1980 (ACM SIGPLAN Notices 15(7-8):82-87 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Superclass Defaults
This seems to be a frequently requested feature of Haskell: the ability to declare default members in a superclass for a particular class. Here's an example: class Functor f where fmap :: (a - b) - f a - f b class (Functor f) = Monad f where ... The idea is that it should be possible to declare a type an instance of both Monad and Functor without having to provide a definition for 'fmap'. Instead, a default would be used: fmap ab fa = fa = (return . ab) Well I don't doubt this would be a very useful extension to the Haskell language: indeed it would eliminate code in all my Haskell projects. But before we can propose this, we have to work out what the syntax would look like. Here are some properties I think such a mechanism should have: 1. It should be possible to declare types as instances of Monad and Functor with a different definition of fmap overriding the default. 2. It should be possible to declare another subclass of Functor that also has a default for fmap. 3. The members of any existing class should be subclass-defaultable in another module; i.e., no special syntax should be involved in the class declaration of the superclass. 4. It should be possible to distinguish between different appearances of the same class in the superclass context. For instance: class C a where c :: Int - a class (C a,C b,C (a - b)) = D a b where ... Any ideas? -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Superclass Defaults
On Mon, Jul 21, 2003 at 06:21:33AM -0700, Ashley Yakeley wrote: Well I don't doubt this would be a very useful extension to the Haskell language: indeed it would eliminate code in all my Haskell projects. But before we can propose this, we have to work out what the syntax would look like. Here are some properties I think such a mechanism should have: 1. It should be possible to declare types as instances of Monad and Functor with a different definition of fmap overriding the default. 2. It should be possible to declare another subclass of Functor that also has a default for fmap. 3. The members of any existing class should be subclass-defaultable in another module; i.e., no special syntax should be involved in the class declaration of the superclass. 4. It should be possible to distinguish between different appearances of the same class in the superclass context. For instance: class C a where c :: Int - a class (C a,C b,C (a - b)) = D a b where ... I agree with all these desiderata. I don't think any new syntax is necessarily needed. With regards to point 4, note that just giving a type signature is guaranteed to be enough to tell you _which_ instance of class C you are referring to. I think there are likely to be subtle semantic issues, however. Also, it seems strange to have default methods in class declarations if you don't also allow such declarations in instance declarations. Peace, Dylan pgp0.pgp Description: PGP signature
Announce: wxHaskell, a portable GUI library.
Announcement: wxHaskell 0.1 --- http://wxhaskell.sourceforge.net wxHaskell is a new portable GUI library for Haskell. The goal of the project is to provide an industrial strength portable GUI library, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore build on top of wxWindows -- a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge). Since most of the interface is automatically generated from the wxEiffel binding, the current release of wxHaskell already supports about 75% of the wxWindows functionality -- about 2500 methods in 500 classes with 1200 constant definitions. wxHaskell has been build with GHC 6.0 on Windows, MacOS X and Unix systems with GTK. A binary distribution is available for Windows (and we are working on a binary release for MacOS X). And even if you don't intend to write GUI's yourself, it will be fun to check out the screenshots at http://wxhaskell.sourceforge.net. All the best, Daan Leijen. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators (ad-hoc overloading)
G'day all. On Mon, Jul 21, 2003 at 01:07:39PM +0200, Christian Maeder wrote: Mere overload resolution (over monomorphic types) is not NP-hard. (This is only a common misconception.) I can only repeat my above sentence. I'm a firm believer in the maxim that the best way to find information on the net is to post wrong information. :-) As a matter of interest, is there a known worst-case complexity for the precomputation required by Earley's algorithm to handle arbitrary CFGs? This kind of overloading is no cause for exponentiell behaviour, if it's either solved by type class overloading or by monomorphic overload resolution. (Only let-polymorphism is hard.) I don't believe that expected-case O(N^3) behaviour counts as not hard, even if it's not exponential. These things have a way of biting you when you least expect it. From an economic point of view, programmer time is very expensive. Much more so than machine time. A few seconds spent resolving overloading on a large program is a few seconds that the programmer is effectively stalled. Plus, these things add up. A short time plus a short time is not necessarily a short time. Another economic issue to consider is that the time spent compiling a program over its life is often quadratic in the final size of the program. One necessary requirement for tractible software development is low constant factors. (This, of course, assumes that the program grows linearly over its life and the machines used to compile on are not upgraded over that time. In commercial development, it's generally considered good practice to freeze the hardware/compiler/OS combination throughout the maintenance period of a specific software release. This assumption may not hold in some development environments, such as in open source development.) I admit the combination of overload resolution and polymorphism is not simple, but Haskell has solved it in a certain way with type classes! I think we agree that Haskell's type class scheme is an extremely good mechanism for the problem of overloading. However, mechanism is not the same as policy. The issue that we have before us is that the current numeric type class hierarchy is too coarse-grained for people developing richer varieties of numeric types. There are problems with making it too fine-grained, as well. Until we find the sweet spot, the problem is not solved. Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Help with propositional formulas
There's a 'powerset' thread on this list [1][2] starting 4th June which I
think contains some of the answers you seek. Read and you shall learn!
#g
--
[1] List archive: http://www.haskell.org/pipermail/haskell-cafe/
[2] Powerset thread
starts: http://www.haskell.org/pipermail/haskell-cafe/2003-June/004463.html
(Read into the thread, because there are some problems with the code that
appears earlier in the thread.)
At 22:55 19/07/03 -0300, Douglas O. Matoso wrote:
Hi,
I have an school assignment that asks to implement an truth table of
propositional formulas. I'm having difficulties in the following part:
data Prop = Var Char | Not Prop | And Prop Prop | Or Prop Prop
type Subst = [(Char,Bool)]
- Define a function
bools :: Int - [[Bool]]
that calculates all possible lists of logical values of a specific length.
For
example, bools 2 should give the following list:
[[False,False],
[False,True ],
[True ,False],
[True ,True ]]
- Define a function
substs :: Prop - [Subst]
that calculates all possible substitutions for the variables of a
proposition.
For example, substs p2 should give the following list:
[[('A',False),('B',False)],
[('A',False),('B',True) ],
[('A',True) ,('B',False)],
[('A',True) ,('B',True) ]]
I would be thankful for any help.
Douglas Matoso
**
** Este email foi scaneado contra virus e conteudo malicioso **
**
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
---
Graham Klyne
[EMAIL PROTECTED]
PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
lazy Printing question
Hi everyone, I have written the following program to find magic numbers i.e. integers 'n' such that both (n+1) and (n/2+1) are perfect squares. -- Program to find magic numbers Import IO main :: IO () main = do print (filter magicP sqs) sqs :: [Int] sqs = [x*x | x - [1,3..mAX]] magicP :: Int - Bool magicP x | ((x-1) `mod` /= 0 = False | otherwise = (((x-1) `div` 2) + 1) `elem` sqs) mAX :: Int mAX = 2 -- End of listing If I try to run the program (compiled using GHC 6), it calculates all members of the list and then prints the whole list in the end. Since Haskell is 'lazy' I was expecting behaviour similar to HUGS where it prints the numbers as it finds them. Does this behaviour have something to do with the monadic IO in Haskell? I am a Haskell newbie and can't even claim having understood the gentle introduction properly. Now my question is - How do I reproduce such lazy printing behaviour in GHC? Wait... I thought of another one :-), how do I speed up this program? - AJ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
segfault in haskell!
I've managed to get a segfault in haskell! And without even using the FFI... actually my code uses the FFI, but the changes that triggered the segfault don't involve that, they just use Text.Regex. The code that triggers the segfault is the function produced by: filetype_function :: IO (FilePath - FileType) filetype_function = do binsfile - def_prefval binariesfile _darcs/prefs/binaries bins - (liftM lines $ readFile binsfile) `catch` (\e- if isDoesNotExistError e then return [] else ioError e) let rs = map (mkRegex.fixregex) bins isbin f = or $ map (\r- matchRegex r f /= Nothing) rs ftf f = if isbin f then BinaryFile else TextFile in return ftf and the valgrind report on the segfault is: ==8705== Invalid free() / delete / delete[] ==8705==at 0x4015D6A4: free (vg_clientfuncs.c:185) ==8705==by 0x40399A34: (within /lib/libc-2.3.1.so) ==8705==by 0x40399C13: regfree (in /lib/libc-2.3.1.so) ==8705==by 0x8117683: s67U_entry (in /home/droundy/darcs/darcs) ==8705==Address 0x1 is not stack'd, malloc'd or free'd ==8705== ==8705== Invalid read of size 4 ==8705==at 0x40399A58: (within /lib/libc-2.3.1.so) ==8705==by 0x40399C13: regfree (in /lib/libc-2.3.1.so) ==8705==by 0x8117683: s67U_entry (in /home/droundy/darcs/darcs) ==8705==Address 0x22 is not stack'd, malloc'd or free'd Unfortunately inserting a trace f $ before the isbin f shows that it is segfaulting on the string Patch.lhs. This looks to me like a bug in either Text.Regex or glibc (with my bet being on Text.Regex. Any ideas how to track it down and/or work around it? Oh yeah, and I'm running ghc 6.0. Maybe this is fixed in CVS? -- David Roundy http://www.abridgegame.org ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
How to catch an exception
Trying to get the hang of exceptions... I would expect this program: module Main where import Control.Exception hiding (GHC.Prelude.catch) temp :: IO () temp = do putStrLn line 1 ioError (AssertionFailed my temp) handler :: Exception - IO () handler e = putStrLn (exception: ++ (show e)) main :: IO () main = catch temp handler .. to output: line 1 exception: AssertionFailed: my temp (or whatever show produces for the AssertionFailed exception) ... but all I get is: line 1 Fail: my temp This implies that the handler is not called. So what am I doing wrong? * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: How to catch an exception
On Mon, Jul 21, 2003 at 02:12:02PM +0100, Bayley, Alistair wrote: module Main where import Control.Exception hiding (GHC.Prelude.catch) This hiding clause is illegal. But anyway what you want is import Prelude hiding (catch) import Control.Exception Prelude.catch only catches Haskell 98 exceptions; Control.Exception.catch catches everything. temp :: IO () temp = do putStrLn line 1 ioError (AssertionFailed my temp) From GHC 6.0, Exception is not the same as IOError: say throwIO instead of ioError here. (So GHC 6.0 flags your error as a type error.) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: lazy Printing question
If I try to run the program (compiled using GHC 6), it calculates all members of the list and then prints the whole list in the end. Since Haskell is 'lazy' I was expecting behaviour similar to HUGS where it prints the numbers as it finds them. Does this behaviour have something to do with the monadic IO in Haskell? I am a Haskell newbie and can't even claim having understood the gentle introduction properly. My guess would be that you're seeing buffering behaviour where GHC fills up a buffer of characters for output and flushes it every 1000, 4000 or whatever characters. IIRC correctly, buffering is off by default in Hugs but on by default in GHC. You can turn this off with the Haskell 98 function hSetBuffering described in section 11.4.2 of the library report. -- Alastair ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Ignoring ExitExceptions
I'm looking for a way to return an arbitrary exit code to the OS. The standard `exitWith' function does the job, but unfortunately it also has the side-effect of reporting an exception (I'm using GHC 6.0, with Control.Exception imported for other purposes). When a fatal error occurs, my program will already have issued a meaningful error message, and the added *** Exception: exit: ExitFailure 2 will serve only to confuse users. Unfortunately it appears that the only way to return an exit code is to let an ExitException pass unhandled. All I'm really asking for is a way to use the exitWith function as defined in Haskell 98, along with the exception extensions provided in Control.Exception. Is there perhaps some way to prevent ExitExceptions from being reported, or a way to exclude certain types of exception from the handling in Control.Exception? Or can anyone suggest an alternative approach? -- TJ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
