Control.Exception

Mark Wotton

28 Aug 2009 28 Aug '09

8:12 a.m.

Is there something inherent in JHC which prohibits using exceptions? I noticed the Control.Exception module is a bit anaemic - my use case here is to catch pattern match failures. (Yeah, I know it's an ugly idiom, but if I'm calling from Ruby, I just want an automatic exception that packages the error back up into the ruby runtime.) cheers Mark

Show replies by date

John Meacham

29 Aug 29 Aug

5:52 a.m.

On Fri, Aug 28, 2009 at 12:42:00PM +1000, Mark Wotton wrote:

...

Is there something inherent in JHC which prohibits using exceptions? I noticed the Control.Exception module is a bit anaemic - my use case here is to catch pattern match failures. (Yeah, I know it's an ugly idiom, but if I'm calling from Ruby, I just want an automatic exception that packages the error back up into the ruby runtime.)

There is no particular issue with normal IO exceptions in jhc, they used to be implemented in terms of Jhc.JumpPoint and Jhc.Hole. At some point I disabled them because they made debugging more difficult and cluttered the main IO libraries and never got around to reimplementing them. however, Grin now has a 'continuation' primitive, which should be used. That said, I am still undecided about imprecise exceptions. (catching pattern match failures and error calls). They inhibit the optimizer and signal bugs, not catchable exceptions. I may introduce a flag to control this behavior though.. imprecise exceptions are occasionally useful for things like writing an interpreter... John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

Taral

30 Aug 30 Aug

12:37 a.m.

On Fri, Aug 28, 2009 at 5:22 PM, John Meacham wrote:

...

That said, I am still undecided about imprecise exceptions. (catching pattern match failures and error calls). They inhibit the optimizer and signal bugs, not catchable exceptions. I may introduce a flag to control this behavior though.. imprecise exceptions are occasionally useful for things like writing an interpreter...

Perhaps a flag to ignore impossible-to-reach _ cases at the end of a match block? Then one can simply add: _ -> throw xyz to the end of blocks where one wants these exceptions. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown

John Meacham

6:19 a.m.

On Sat, Aug 29, 2009 at 12:07:51PM -0700, Taral wrote:

...

On Fri, Aug 28, 2009 at 5:22 PM, John Meacham wrote:

...
That said, I am still undecided about imprecise exceptions. (catching pattern match failures and error calls). They inhibit the optimizer and signal bugs, not catchable exceptions. I may introduce a flag to control this behavior though.. imprecise exceptions are occasionally useful for things like writing an interpreter...

Perhaps a flag to ignore impossible-to-reach _ cases at the end of a match block? Then one can simply add:

_ -> throw xyz

to the end of blocks where one wants these exceptions.

You can do this anyway, or could if jhc's throw support worked :), for every case expression: case ... of Foo -> y Bar -> z jhc adds an alternate at the end _ -> error "Unmatched case at file:line-number" then the simplifier will delete any unreachable alternatives. So no need for a switch, impossible to reach alternatives of any form are always deleted. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

Taral

12:09 p.m.

On Sat, Aug 29, 2009 at 5:49 PM, John Meacham wrote:

...

then the simplifier will delete any unreachable alternatives. So no need for a switch, impossible to reach alternatives of any form are always deleted.

I think ghc has a (useful) warning about unreachable alternatives. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown

5974

Age (days ago)

5976

Last active (days ago)

List overview

Download

4 comments

3 participants

participants (3)

John Meacham
Mark Wotton
Taral