headers
MR K P SCHUPKE | 1 Aug 2004 06:40
Picon

Re: Multiprocessor compiling.

>want to fork 3 threads to compute "a*b + c*d"

of course this depends on what a b c and d are ... if they are 1000x1000
matricies then you may well want the '*' operations in separate threads...

Keean.
Permalink | Reply | 0 comments |
headers
Ketil Malde | 1 Aug 2004 08:35
Picon
Picon

Re: Hello and help request

Graham Klyne <GK <at> ninebynine.org> writes:

> I made some notes about this, but they're in no sense authoritative:
> http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#type-class-misuse

I think it's easy for the OO-programmer to start designing programs
using Haskell classes as if they were OO classes.  Not necessarily
bad, but I agree it is better to build your program first, and add
classes later when and where it makes sense.

-kzm
--

-- 
If I haven't seen further, it is by standing in the footprints of giants
Permalink | Reply | 0 comments |
headers
S. Alexander Jacobson | 1 Aug 2004 18:55

Re: Multiprocessor compiling.

On Sat, 31 Jul 2004, Alastair Reid wrote:
> On Saturday 31 July 2004 09:11, Matthew Roberts wrote:
> > tell us the fundamental reason it is hard to compile Haskell
> > for multiple processor machines - in broad strokes.
>
> Unpredictability, heavy use of heap and overly fine granularity of inherent
> parallelism.

How well does GPH solve the first two of these
problems (I think it solves the third by asking
the programmer for parallel annotations)?

Also, if you use forkOS, doesn't your app
inevitably distribute itself accross multiple
processors if the OS runs threads that way?
If the OS does run threads that way, are you
saying that forkOS is *very* inefficient (or does
the forkOS implementation in e.g. GHC solve the
problems you describe)?

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
Permalink | Reply | 1 comment |
headers
S. Alexander Jacobson | 1 Aug 2004 19:25

Modifying Running Programs

eBay modifies 30k lines of code per week while
maintaining 99.92% uptime.

Is there a way to force ghc (or some other Haskell
implementation) to load new implementations of
functions without restarting the program?

Alternatively, is there a way of restarting a
program with new code without having to
reconstruct all its in memory state?

-Alex-


______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
Permalink | Reply | 2 comments |
headers
MR K P SCHUPKE | 2 Aug 2004 01:10
Picon

Re: Modifying Running Programs

>Is there a way to force ghc (or some other Haskell
>implementation) to load new implementations of
>functions without restarting the program?

Yes, if you use the dynamic loading interface fron ghci.
Code can be loaded and unloaded at runtime (however I
believe the actual memory is never recovered)

Keean.
Permalink | Reply | 0 comments |
headers
Donald Bruce Stewart | 2 Aug 2004 02:25
Picon
Picon
Favicon
Gravatar

Re: Modifying Running Programs

alex:
> eBay modifies 30k lines of code per week while
> maintaining 99.92% uptime.
> 
> Is there a way to force ghc (or some other Haskell
> implementation) to load new implementations of
> functions without restarting the program?
> 
> Alternatively, is there a way of restarting a
> program with new code without having to
> reconstruct all its in memory state?

You could consider using hs-plugins:
  http://www.cse.unsw.edu.au/~dons/hs-plugins/

the example at the bottom of 
  http://www.cse.unsw.edu.au/~dons/hs-plugins/hs-plugins-Z-H-7.html#node_sec_6.2

shows how to load a new object into a running program, changing an
already existing function on the fly. This uses GHC's dynamic linker
underneath.

-- Don
Permalink | Reply | 1 comment |
headers
Evan LaForge | 2 Aug 2004 22:09

exceptions vs. Either


Exceptions are convenient in that you can rely on libraries throwing them
instead of prechecking for valid values yourself (for instance, why check
that the argument to Char.digitToInt is valid if digitToInt does so already),
and you don't have to modify a lot of function signatures.  Unfortunately, in
the face of lazy evaluation, they can get thrown in unexpected places.  Even
with Exception.evaluate, or code which is already explicitly sequenced in the
IO monad, like "t <- Exception.evaluate (map Char.digitToInt ['a'..'g'])" an
exception will only be thrown when you inspect the last element of 't'.
(digitToInt confusingly accepts hex "digits"---shouldn't it be "higitToInt"
then?).

So it seems to me that if you are, say, checking input, the options are
to handle exceptions from the checking code but expect them to come from the
processing code, or decorate all checking code with Rights and Lefts.
Problems with the first option are that checking code could also trigger some
exceptions, and Prelude functions throw undescriptive errors like "user
error" or low level ones like "refuted pattern match" and catching them over
the entire program means you could stifle a lot of real errors. This implies
that you have to make specific exceptions and convert Prelude and library
exceptions into yours as low down as possible, which is cluttering but maybe
not as cluttering as Either.  Problems with the second option are many of the
problems that lead to us wanting exceptions in the first place.

Using Either seems much simpler and functional-friendly.  So then, in what
contexts are exceptions appropriate in haskell?
Permalink | Reply | 12 comments |
headers
Alastair Reid | 2 Aug 2004 22:58
Picon

Re: exceptions vs. Either

On Monday 02 August 2004 21:09, Evan LaForge wrote:
> Exceptions are convenient [...] 
> [but] an exception will only be thrown when you evaluate t.
>
> So it seems to me that if you are, say, checking input, the options are
> to handle exceptions from the checking code but expect them to come from
> the processing code, or [not use eceptions]
> [...]
> So then, in what contexts are exceptions appropriate in haskell?

I think you're right that exceptions aren't useful for input checking.  You 
really need something that will check all the input at once.  i.e., 
evaluating any part of the checked input causes all input checks to be 
performed.  The easiest way to do this is with a monad or some such - which 
provides you with a more flexible, more controllable error-reporting 
mechanism anyway.

I usually use exceptions when dealing with the outside world where I want to 
protect the outside world from any misbehaviour of the Haskell code.  For 
example, if opening and closing windows or files, controlling a robot, etc., 
I might use the exception catching/propagating to make sure that things are 
shutdown properly when the Haskell program crashes.

In general, if there's a way to make your program bombproof using a 
conventional mechanism (monads, Either, Maybe, etc.), then you should use it 
since it will be easier to reason about and can be more flexible.  But, if 
your program really has to be bombproof and you can't convince yourself that 
it is (e.g., it depends on a library you didn't write), exception handling 
can help a lot.
(Continue reading)

Permalink | Reply | 0 comments |
headers
MR K P SCHUPKE | 3 Aug 2004 10:41
Picon

Re: exceptions vs. Either

A lot of programming errors come from failure to correctly validate.
I remember being taught to validate on input _and_ validate when
you use a value. So I would say do both - use maybe for input
functions, and exceptions for when you use a value. You can use
the type system to make this more efficient. Imagine you want an
integer between 10 and 20, you have a function like:

newtype ValidInt = Valid Int

validateInt :: Int -> Maybe ValidInt
validateInt x | x>=10 && x<=20 = Just (Valid x)
validateInt _ = Nothing

Now when you validate on input - you produce an error if
you get "Nothing" and in all the functions you use the
value you use ValidInt instead of Int. This way you
use the type system to differentiate between a valid
int (does not need to be rechecked) and a normal int
(which would need to be validated).

Of course you must make sure you don't write more than
one constructor function for ValidInt. This suggests a
form of constrained constructor would be useful... Whilst
this can be done in Haskell,
it is not easy and involves reifying the value to a type,
and using a type class to constrain the data statement.

Really here we are dealing with dependant types, and this
is much easier in a dependantly typed language like
Epigram.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Graham Klyne | 3 Aug 2004 11:19

Re: exceptions vs. Either

Two observations:

1. When I recently modified the HaXml XML parser, this is one of the 
significant changes I made:  providing (alterantive) return values based on 
Either, so that input errors could be handled by the invoking function, 
without forcing it into the IO monad.  I guess that's a vote of agreement.

2. I like to distinguish between "expected errors" and "unexpected 
errors".  Having been burned in the past by using exceptions (not FP), I 
try to use them only for conditions that are truly unexpected; i.e. 
_exceptional_.  Bad input, IMO, is something that is not unexpected, so I 
don't really like to handle that via exceptions.

#g
--

At 13:09 02/08/04 -0700, Evan LaForge wrote:

>Exceptions are convenient in that you can rely on libraries throwing them
>instead of prechecking for valid values yourself (for instance, why check
>that the argument to Char.digitToInt is valid if digitToInt does so already),
>and you don't have to modify a lot of function signatures.  Unfortunately, in
>the face of lazy evaluation, they can get thrown in unexpected places.  Even
>with Exception.evaluate, or code which is already explicitly sequenced in the
>IO monad, like "t <- Exception.evaluate (map Char.digitToInt ['a'..'g'])" an
>exception will only be thrown when you inspect the last element of 't'.
>(digitToInt confusingly accepts hex "digits"---shouldn't it be "higitToInt"
>then?).
>
>So it seems to me that if you are, say, checking input, the options are
(Continue reading)

Permalink | Reply | 10 comments |

Gmane