> [snip: parser and interpreter for a little expression language]
>
> however an experienced haskell programmer might realize the data
> structure is not needed and just write
>
> [snip: combined parser/interpreter for same language]
>
> by getting rid of these needless intermediate data structures
Graham Klyne writes:
> Another approach that occurs to me is to introduce an error Monad
> along the lines of that described by Philip Wadler as "E" in his
> "Essence of functional programming" paper [1]. (Or just use Either
> as an error monad?, which is part of what I've been doing with my XML
Another problem is that people learning haskell, especially those coming
from a OO background or language like java, tend to write code that
needlessly exasperates the naming conflict problem.
I think this is because of the initial steps one usually takes in other
languages, the first thing one t
On 12/06/2004, at 9:52 AM, [EMAIL PROTECTED] wrote:
Hi, when writing haskell code. It is so annoying that name clashes keep
happening.
I have to be careful about the data constructor names, about the class
names, about the class member names.
I understand that we can use class to achieve some overl
On Mon, Jun 14, 2004 at 05:41:03PM +0100, Keith Wansbrough wrote:
> > Philippa Cowderoy wrote:
> >
> > > The ability to fail doesn't need the do notation, just use of
> > > return for success - similar for propagating failure.
> >
> > I'm not sure I understand. Do you mean writing functions
> >
On Fri, 2004-03-26 at 14:39, Sean E. Russell wrote:
> On Friday 26 March 2004 17:04, Carl Witty wrote:
> > Are you aware of this:
> >
> > 2001-12-12
> > * Due to wanting to get on with other things, I'm freezing the
> > shootout as is, with no further updates planned. It isn't
> >
> I assume the suggested mapException function [sect 5.4] remains
> unproblematic ... is it (or some equivalent) actually implemented?
http://etudiants.insia.org/~jbobbio/pafp/docs/base/Control.Exception.html#v%
3AmapException
The same page has a host of other useful operations.
Two useful cap
Keith Wansbrough wrote:
> s/fail/error/
> s/return//
>
> Then you can easily write
>
> > I can't (easily) write
> >
> > text c = sqr x + sqr (x+1)
>
> You just can't *catch* this outside the IO monad.
Of course... that was my second alternative error
strategy. I'm interest in how/when peo
> Philippa Cowderoy wrote:
>
> > The ability to fail doesn't need the do notation, just use of
> > return for success - similar for propagating failure.
>
> I'm not sure I understand. Do you mean writing functions
> like:
>
> sqr x | x < 0 = fail "less than zero"
> | otherwise
Philippa Cowderoy wrote:
> The ability to fail doesn't need the do notation, just use of
> return for success - similar for propagating failure.
I'm not sure I understand. Do you mean writing functions
like:
sqr x | x < 0 = fail "less than zero"
| otherwise = return (sqrt x)
Now I see it. Thanks.
Thanks also for the reference. Nice paper!
So now where do I stand?
I still think that being forced to handle exceptions in the IO monad is
(sometimes) inconvenient, but I can now see why it is required for a
rigorous language semantics. My problem relates to wanting to b
On Mon, 14 Jun 2004, Tim Docker wrote:
> Both of these approaches seem fairly "invasive" in their
> effect on the code. Are people using haskell for real world
> tasks happy with having to choose from these? The former is
> more general, but any function that needs to be able to
> fail or propagat
On Mon, 14 Jun 2004, Keith Wansbrough wrote:
(snip)
> to lose referential transparency. What is the value of
>
> catchExcept (show (makeExcept "E1" + makeExcept "E2")) (\x -> x)
>
> ? Haskell wouldn't be "purely functional" any more.
(snip)
We've already had these issues raised on haskell-cafe w
===
6th International Workshop on
Soft Constraints and Preferences
September 27th, 2004
Toronto, Canada
Held in conjunction with
10th International Conference on
Keith Wansbrough wrote:
> Read the paper _A Semantics for Imprecise Exceptions_. The
> problem is that the evaluation order of Haskell would have to
> be fixed for this not to lose referential transparency. What
> is the value of
>
> catchExcept (show (makeExcept "E1" + makeExcept "E2"))
>
Tom,
Then what will you do when naming operations in a class? Is it right that
care has to be taken in order not to conflict with other classes?
Say, I have a Person class where I want to define an operation "getName".
Is it wise to name it "getPersonName" instead?
I notice that FiniteMap alw
On Mon, 2004-06-14 at 14:34, Graham Klyne wrote:
> I'm finding that a recurring theme in my work with Haskell libraries (and
> in particular the XML libraries) is the awkwardness of handling errors
> outside the IO monad.
With GHC You can throw exceptions in pure code but may only catch them
in
> I can't see any fundamental reason why exception handling has to occur in
> the IO monad.
Read the paper _A Semantics for Imprecise Exceptions_. The problem is that the
evaluation order of Haskell would have to be fixed for this not to lose referential
transparency. What is the value of
ca
I'm finding that a recurring theme in my work with Haskell libraries (and
in particular the XML libraries) is the awkwardness of handling errors
outside the IO monad.
While it's often very easy to write some code that performs some function,
assuming that the inputs are valid, as soon as code i
19 matches
Mail list logo
