On 28/02/06, John Meacham [EMAIL PROTECTED] wrote:
On Tue, Feb 28, 2006 at 01:09:03AM -0500, Cale Gibbard wrote:
Well, the benefit of the Identity monad is so that the user of a routine
can choose to recover gracefully by using a different monad, you only
use the Identity monad when you
On Tue, Feb 28, 2006 at 04:52:40AM -0500, Cale Gibbard wrote:
-- collect error messages from all failing parsers
[ err | Left err - map parse xs]
I don't see how you lose this one at all.
because somewhere else, you might want to use 'parse' as a maybe.
somewhere else, you might want it to
On 24/02/06, John Meacham [EMAIL PROTECTED] wrote:
On Fri, Feb 24, 2006 at 12:39:27PM -0500, Cale Gibbard wrote:
I look at the above as generating a proof obligation for me as the
programmer that the lookup will never fail, or at least the ability to
convince myself. :) If you want to
On Mon, Feb 27, 2006 at 10:57:17PM -0500, Cale Gibbard wrote:
Well, this is an issue. Perhaps a version of error which makes the
line/column number available to its parameter would help... something
along the lines of
type SourcePos = (Integer, Integer)
-- possibly a data/newtype with a
On 27/02/06, John Meacham [EMAIL PROTECTED] wrote:
On Mon, Feb 27, 2006 at 10:57:17PM -0500, Cale Gibbard wrote:
Well, this is an issue. Perhaps a version of error which makes the
line/column number available to its parameter would help... something
along the lines of
type SourcePos =
On Tue, Feb 28, 2006 at 01:09:03AM -0500, Cale Gibbard wrote:
Well, the benefit of the Identity monad is so that the user of a routine
can choose to recover gracefully by using a different monad, you only
use the Identity monad when you are making a choice to bottom out on
errors. using
On 20/02/06, John Meacham [EMAIL PROTECTED] wrote:
There is a more straightforward way to get localized error messages
rather than using 'maybe' and hand-writing an appropriate error, and
that is to rely on irrefutable bindings.
f x = ... y ... where
Just y = Map.lookup x theMap
On Fri, Feb 24, 2006 at 12:39:27PM -0500, Cale Gibbard wrote:
I look at the above as generating a proof obligation for me as the
programmer that the lookup will never fail, or at least the ability to
convince myself. :) If you want to handle errors, you should actually
handle them, not let
Hi,
haskell admits many programming styles and I find it important that
several developers of a prject agree on a certain style to ease code review.
I've set up guidelines (still as plain text) for our (hets) project in
On Mon, 20 Feb 2006, Christian Maeder wrote:
I've set up guidelines (still as plain text) for our (hets) project in
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/versions/HetCATS/docs/Programming-Guidelines.txt
It seems we share the preference
On Feb 20, 2006, at 12:48 PM, Christian Maeder wrote:
Hi,
haskell admits many programming styles and I find it important that
several developers of a prject agree on a certain style to ease
code review.
I've set up guidelines (still as plain text) for our (hets) project in
On Feb 20, 2006, at 2:26 PM, Henning Thielemann wrote:
On Mon, 20 Feb 2006, Robert Dockins wrote:
I personally disagree with your preference for custom datatypes
with a value representing failure to lifting types with Maybe.
I understood that part of the guidelines as a pleading for Maybe.
maeder:
Hi,
haskell admits many programming styles and I find it important that
several developers of a prject agree on a certain style to ease code review.
I've set up guidelines (still as plain text) for our (hets) project in
Perhas you'd like to put up a Style page on thew new Haskell
There is a more straightforward way to get localized error messages
rather than using 'maybe' and hand-writing an appropriate error, and
that is to rely on irrefutable bindings.
f x = ... y ... where
Just y = Map.lookup x theMap
now if the lookup fails you automatically get an error
14 matches
Mail list logo
