[Haskell-cafe] Re: Re: Debugging partial functions by the rules

2006-11-18 Thread Benjamin Franksen
Daniel,

you wrote:
 I suspect I would be classified as a newbie relative to most posters on
 this list but here's my thoughts anyway...
 [...]
 One of my initial responses to haskell was disappointment upon seeing
 head,
 fromJust and the like.  'Those look nasty', I sez to meself.
 From day one I've tried to avoid using them.  Very occasionally I do use
 them in the heat of the moment, but it makes me feel unclean and I end up
 having to take my keyboard into the bathroom for a good scrubbing with the
 sandsoap.

I completely agree and couldn't have said it in any better way (including
the relative newbie part).

Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Re: Debugging partial functions by the rules

2006-11-15 Thread Benjamin Franksen
John Hughes wrote:
 From: Robert Dockins [EMAIL PROTECTED]
 
 It seems to me that every possible use of a partial function has some
 (possibly imagined) program invariant that prevents it from failing.
 Otherwise it is downright wrong.  'head', 'fromJust' and friends
 don't do anything to put that invariant in the program text.
 
 Well, not really. For example, I often write programs with command line
 arguments, that contain code of the form
 
 do ...
[a,b] - getArgs
...
 
 Of course the pattern match is partial, but if it fails, then the standard
 error message is good enough.
 
 This applies to throw away code, of course, and if I decide to keep the
 code then I sooner or later extend it to fix the partiality and give a
 more sensible error message. But it's still an advantage to be ABLE to
 write the more concise, but cruder version initially.
 
 This isn't a trivial point. We know that error handling code is a major
 part of software cost--it can even dominate the cost of the correct case
 code (by a large factor). Erlang's program for the correct case
 strategy, coupled with good fault tolerance mechanisms, is one reason for
 its commercial success--the cost of including error handling code
 *everywhere* is avoided. But this means accepting that code *may* very
 well fail--the failure is just going to be handled somewhere else.
 
 Haskell (or at least GHC) has good exception handling mechanisms too. We
 should be prepared to use them, and let it fail when things go wrong.
 The savings of doing so are too large to ignore.

But note that Erlang will give you a stack trace for unhandled exceptions
which Haskell (currently?) doesn't/can't.

Also, I remember an Erlang expert (Ulf Wiger?) stating recently
that 'catching and re-throwing expections in most cases tends to hide
program errors rather than avoid them' (quoted non-verbatim from memory, I
can't recall the name of the paper). 

Lastly, Erlang's program for the correct case is not meant for things like
input of data from sources outside the program's control, but only applies
to not-checking for program internal invariants. I would be very surprised
if there were Erlang experts encouraging throwaway code such as your
example above.

Cheers,
Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe