On Tue, Aug 20, 2013 at 12:25:44AM +0200, Jerzy Karczmarczuk wrote:
> Le 20/08/2013 00:19, jabolo...@google.com a écrit :
> >If I understand correctly, by "escaping continuations" you mean that
> >you can easily transfer control between the point where the exception
> >is raised and the exception h
Le 20/08/2013 00:19, jabolo...@google.com a écrit :
If I understand correctly, by "escaping continuations" you mean that
you can easily transfer control between the point where the exception
is raised and the exception handler.
If this is what you mean, you can achieve the same effect with monad
> Some exceptions, e.g. in the traversal of deep structures may be and
> ARE used as escaping continuations.
If I understand correctly, by "escaping continuations" you mean that
you can easily transfer control between the point where the exception
is raised and the exception handler.
If this is w
jabolo...@google.com :
I would like to see more code move away from exceptions and into
types like "Maybe" or "Either" or other types defined for the
particular situation (as some people were suggesting in the beginning
of the thread). And the reason for this it is because when you program
agains
On Mon, Aug 19, 2013 at 5:24 PM, Tom Ellis <
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk> wrote:
> On Mon, Aug 19, 2013 at 05:15:39PM -0400, jabolo...@google.com wrote:
> > But I would like to see more code move away from exceptions and into
> > types like "Maybe" or "Either" or other types define
On Mon, Aug 19, 2013 at 05:15:39PM -0400, jabolo...@google.com wrote:
> But I would like to see more code move away from exceptions and into
> types like "Maybe" or "Either" or other types defined for the
> particular situation (as some people were suggesting in the beginning
> of the thread). And
I agree that whether to use exceptions or not is a very debatable
subject and it is a grey area.
Still, in your Python example, I would like to point out that just
because something is common, it does not mean it is the right thing to
do. For example, something that some Java programmers were doi
jabolo...@google.com,
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
In-Reply-To:
References:
quoth Brandon Allbery,
> Even in IO, exceptions should be reserved for truly exceptional conditions
> (of the "program cannot safely continue" variety), not merely for error
> checking when
Except that people generally don't seem to agree what constitutes
'exceptional', even when disregarding the python world...
On Aug 19, 2013 9:24 PM, "Brandon Allbery" wrote:
> On Mon, Aug 19, 2013 at 2:59 PM, wrote:
>
>> I'd say that if you were in the context of the IO monad, maybe you'd
>> pre
On Mon, Aug 19, 2013 at 2:59 PM, wrote:
> I'd say that if you were in the context of the IO monad, maybe you'd
> prefer to use exceptions instead of 'Either' or 'Maybe'.
>
Even in IO, exceptions should be reserved for truly exceptional conditions
(of the "program cannot safely continue" variety)
I'd say that if you were in the context of the IO monad, maybe you'd
prefer to use exceptions instead of 'Either' or 'Maybe'.
Jose
On Mon, Aug 19, 2013 at 07:41:48PM +0100, Tom Ellis wrote:
> On Mon, Aug 19, 2013 at 02:20:23PM -0400, jabolo...@google.com wrote:
> > Yeah, non-monadic is not the be
On Mon, Aug 19, 2013 at 02:20:23PM -0400, jabolo...@google.com wrote:
> Yeah, non-monadic is not the best term... The problem is that it's
> always so hard to communicate when you want to say a total function
> that is not in the context of the IO monad. There should be a simple,
> short name for t
On Mon, Aug 19, 2013 at 2:09 PM, Brandon Allbery wrote:
> Alternatively, have you considered using your own ADT? `data Validity =
> Success | Failure String` would give you more readable / comprehensible
> code without needing to worry about assumptions or common usage.
Or possibly Valid and Inv
Yeah, non-monadic is not the best term... The problem is that it's
always so hard to communicate when you want to say a total function
that is not in the context of the IO monad. There should be a simple,
short name for these functions, so we can easily talk about them.
What ends up happening a lo
On Mon, Aug 19, 2013 at 9:48 PM, wrote:
> Hi,
>
>
Hello!
> What is the proper way to implement a non-monadic function that checks
> whether a given value is correct and gives a proper error message
> otherwise ? What is the recommended option ?
>
I am not sure, what do you mean by non-monadic.
On Mon, Aug 19, 2013 at 1:48 PM, wrote:
> What is the proper way to implement a non-monadic function that checks
> whether a given value is correct and gives a proper error message
> otherwise ? What is the recommended option ?
>
> * Either String a
>
Preferred, usually, since Nothing is regarde
Hi,
What is the proper way to implement a non-monadic function that checks
whether a given value is correct and gives a proper error message
otherwise ? What is the recommended option ?
* Either String a
check val
| valid val = Right val
| otherwise = Left errorMsg
* Maybe String
check va
17 matches
Mail list logo
