On Fri, Apr 07, 2006 at 10:00:21AM -0500, John Goerzen wrote:
> But here's my concern. Let's say that I wanted to, for some reason,
> create a MultiplyByZero exception. It should be broadly considered an
> ArithException, and any code that catches an ArithException should be
> able to catch my Mu
On Fri, Apr 07, 2006 at 02:58:01PM +0100, Simon Marlow wrote:
> Of course you could implement some global flag to say that an exit is in
> progress, but that implies explicit checking of the flag all over the
> place, which is what asynchronous exceptions are designed to avoid.
>
> When *do* we ex
On Apr 7, 2006, at 3:59 AM, Rene de Visser wrote:
Hello,
As deepSeq has a non local effect, I think it requires a non-local
source transformation to implement it. One option would be for the
compiler to create a second deepSeq version of every function
definition.
e.g.
If the user def
On Fri, Apr 07, 2006 at 03:49:40PM +0100, Simon Marlow wrote:
> John, have you seen this?
>
> http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Extensible
> Exceptions
Yes, and maybe I'm missing something, but I don't think it quite helps.
I followed the link to the example page at:
John, have you seen this?
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Extensible
Exceptions
Cheers,
Simon
On 07 April 2006 15:34, John Goerzen wrote:
> Hello,
>
> One thing that bugs me about Haskell is that exceptions are not
> extensible.
>
> I don't know how to cr
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> BTW, I just realised a better way to express block. If block is
> supposed to count nesting, then we have a problem that you can still
> unblock exceptions even within a block by using sufficient number of
> unblocks, so the right way is to give block
Hello,
One thing that bugs me about Haskell is that exceptions are not
extensible.
I don't know how to craft a good solution, but perhaps if I explain the
problem well, someone would come up with one.
In a language such as Python or Java, and exception is an object.
Let's consider Python for a
On 07 April 2006 13:58, John Meacham wrote:
> all threads keep running while the exit handers are running, all
> blockExit would do is grab and release an MVar. exit itself takes
> that MVar on starting to get rid of races to exit as well as protect
> itsesf from 'blockExit' (but won't ever put th
On Fri, Apr 07, 2006 at 01:29:05PM +0100, Simon Marlow wrote:
> > in addition, an exit_ routine should be added that bypasses the exit
> > handlers, quiting the program immediatly.
>
> I'm not sure I like using exit handlers instead of real exceptions.
>
> If the exit handler needs access to some
On 07 April 2006 13:24, David Roundy wrote:
> The catch to this [no pun intended]
> is that when the main thread exits all other threads are silently
> terminated, without the chance to clean up...
This is a mistake in GHC, I think. When someone calls exit, or when the
main thread exits, all the
On 06 April 2006 23:20, John Meacham wrote:
> == on exit ==
>
> implementations also provide an onExit functionality, for registering
> handlers that can be run when the program exits, as this is the most
> common use of signals as exceptions, to clean up after oneself.
>
> -- | temporarily regi
On Thu, Apr 06, 2006 at 03:19:30PM -0700, John Meacham wrote:
> = minimal proposal =
>
> I think a good minimal solution will be the following, it neatly avoids
> turning signals into exceptions, which may be problematic, but provides
> for the common cases of signal usages while being compatible
On Fri, Apr 07, 2006 at 12:36:11PM +0100, Simon Marlow wrote:
> > You should be able to handle the SIGINT imediatly no matter whether
> > foregin code is running if your handler is in its own thread right?
>
> Yes, but if the signal handler wants to send an exception to the main
> thread, as it of
On 06 April 2006 23:20, John Meacham wrote:
>> I'm not proposing that we ignore signals, just that we should clearly
>> delimit the platform-specific bits, perhaps by putting signal support
>> into an addendum.
>
> yeah, I was thinking a separate environment addendum should be in the
> report, wh
On 07 April 2006 00:36, Marcin 'Qrczak' Kowalczyk wrote:
> "Simon Marlow" <[EMAIL PROTECTED]> writes:
>> I agree with your assessment of the problems with interruptible
>> operations in GHC: that it is impossible to completely block async
>> exceptions across a computation. We could certainly add
Hello,
As deepSeq has a non local effect, I think it requires a non-local source
transformation to implement it. One option would be for the compiler to
create a second deepSeq version of every function definition.
e.g.
If the user defines a function f
f x = g h x
then the compile creates
16 matches
Mail list logo
