There are two general schools of thought as to how to deal with exceptions: * ExceptT/MonadError from transformers/mtl: http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.htm... * The exceptions package (which is a lifted variant of Control.Exception in base): https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell On 20 June 2017 at 15:53, Dennis Raddle wrote:

Just want to bump this request as I have not gotten a reply.

On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle wrote:

...

I am wondering what exception/error and random classes I should use for my application.

The application will be doing Monte Carlo backtracking search. I want it to be multithreaded and run on all four cores on my MacBook.

I need detailed error messages in order to investigate errors. So I will throw errors or exceptions, then catch them in lower functions and annotate them with the parameters or computations within the lower function, then re-throw until finally the exception pops into the terminal.

Because it's multi-threaded, at least some parts will needs to be in IO. Also, because it's a Monte Carlo algorithm it will need to make pseudorandom choices.

Perhaps I should put everything in the IO monad? This will give me access to threads and the standard generator seed. But how about throwing, catching/rethrowing exceptions in IO? I have done this in pure code before: not sure if it's better to do it that way, in which case I could put some kind of state monad to hold the random seed together with an error monad and IO at the core of the monad stack.

Any advice welcome. D

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On 21 June 2017 at 03:19, Dennis Raddle wrote:

Looking at my application needs, such as access to pseudorandom numbers and threads, does this suggest a particular course of action?

For randomness, probably mwc-random, carrying the seed around in a StateT with IO on the bottom of the stack. For multi-threaded: parallelism or concurrency? Simon Marlow's Parallel and Concurrent Programming in Haskell is an excellent book on the topic: http://shop.oreilly.com/product/0636920026365.do

D

On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic wrote:

...

There are two general schools of thought as to how to deal with exceptions:

* ExceptT/MonadError from transformers/mtl:

http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.htm...

* The exceptions package (which is a lifted variant of Control.Exception in base): https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell

On 20 June 2017 at 15:53, Dennis Raddle wrote:

...

Just want to bump this request as I have not gotten a reply.

On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle wrote:

...

I am wondering what exception/error and random classes I should use for my application.

The application will be doing Monte Carlo backtracking search. I want it to be multithreaded and run on all four cores on my MacBook.

I need detailed error messages in order to investigate errors. So I will throw errors or exceptions, then catch them in lower functions and annotate them with the parameters or computations within the lower function, then re-throw until finally the exception pops into the terminal.

Because it's multi-threaded, at least some parts will needs to be in IO. Also, because it's a Monte Carlo algorithm it will need to make pseudorandom choices.

Perhaps I should put everything in the IO monad? This will give me access to threads and the standard generator seed. But how about throwing, catching/rethrowing exceptions in IO? I have done this in pure code before: not sure if it's better to do it that way, in which case I could put some kind of state monad to hold the random seed together with an error monad and IO at the core of the monad stack.

Any advice welcome. D

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On 23 June 2017 at 14:54, Dennis Raddle wrote:

Thanks for pointing me to mwc-random. I like that they provide a normal distribution; that is handy.

I think by asking me parallelism or concurrency, you mean do I have algorithms that interact as they run in separate threads?

This is a backtracking search algorithm, so each thread can explore a subset of the search space with no need to communicate with other threads. Does that mean "concurrency"?

This is a pretty simple task. I hope that I don't have to delve deeply into concurrency/parallelism.

Parallelism: split data set up, run the same operation on each sub-set. Concurrency: do multiple things at once, possibly unrelated. Many languages use concurrency to implement parallelism; Haskell doesn't: see https://wiki.haskell.org/Parallelism_vs._Concurrency and https://wiki.haskell.org/Parallel For a start, have a look at the parallel package: http://hackage.haskell.org/package/parallel ; in particular, par can be used to fork off a new thread, and pseq can be used to ensure a thread finishes before you continue.

D

On Tue, Jun 20, 2017 at 3:59 PM, Ivan Lazar Miljenovic wrote:

...

On 21 June 2017 at 03:19, Dennis Raddle wrote:

...

Looking at my application needs, such as access to pseudorandom numbers and threads, does this suggest a particular course of action?

For randomness, probably mwc-random, carrying the seed around in a StateT with IO on the bottom of the stack.

For multi-threaded: parallelism or concurrency? Simon Marlow's Parallel and Concurrent Programming in Haskell is an excellent book on the topic: http://shop.oreilly.com/product/0636920026365.do

...

D

On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic wrote:

...

There are two general schools of thought as to how to deal with exceptions:

* ExceptT/MonadError from transformers/mtl:

http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.htm...

* The exceptions package (which is a lifted variant of Control.Exception in base):

https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell

On 20 June 2017 at 15:53, Dennis Raddle wrote:

...

Just want to bump this request as I have not gotten a reply.

On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle wrote:

...

I am wondering what exception/error and random classes I should use for my application.

The application will be doing Monte Carlo backtracking search. I want it to be multithreaded and run on all four cores on my MacBook.

I need detailed error messages in order to investigate errors. So I will throw errors or exceptions, then catch them in lower functions and annotate them with the parameters or computations within the lower function, then re-throw until finally the exception pops into the terminal.

Because it's multi-threaded, at least some parts will needs to be in IO. Also, because it's a Monte Carlo algorithm it will need to make pseudorandom choices.

Perhaps I should put everything in the IO monad? This will give me access to threads and the standard generator seed. But how about throwing, catching/rethrowing exceptions in IO? I have done this in pure code before: not sure if it's better to do it that way, in which case I could put some kind of state monad to hold the random seed together with an error monad and IO at the core of the monad stack.

Any advice welcome. D

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On 23 June 2017 at 16:10, Dennis Raddle wrote:

Thanks! Quick question, if I can split my task into 4 completely independent subtasks, what if I code a single program, then invoke this program on each of the 4 subtasks and let the OS give each program a CPU core (there are 4 cores on my MacBook)? Would that be a simple way to take advantage of parallelism?

Not a very efficient method, but in essence yes.

Note that it's always a good idea to start with a simpler prototype anyway ("solve a simpler problem first" in the words of Poyla) so it's a good idea for me to write a prototype that does not use parallelism. If I can then make it parallel just by invoking it four times and let the OS do its thing, that would be nice.

My take would be "build a non-threaded/serial solution, then try and parallelise different parts".

D

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com