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
On Mon, Aug 19, 2013 at 9:48 PM, jabolo...@google.com 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
On Mon, Aug 19, 2013 at 1:48 PM, jabolo...@google.com 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
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
On Mon, Aug 19, 2013 at 2:09 PM, Brandon Allbery allber...@gmail.comwrote:
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
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
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 best
On Mon, Aug 19, 2013 at 2:59 PM, jabolo...@google.com 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
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 allber...@gmail.com wrote:
On Mon, Aug 19, 2013 at 2:59 PM, jabolo...@google.com wrote:
I'd say that if you were in the context
jabolo...@google.com,
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
In-Reply-To:
CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com
References: CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com
quoth Brandon Allbery,
Even in IO, exceptions should be
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
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 the
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 defined for the
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
against
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 what
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
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 handler.
17 matches
Mail list logo
