Brandon S. Allbery KF8NH wrote:
It's not a call, it's a definition as shown above. The simpler
translation is:
x - y
becomes
y = \x -
(note incomplete expression; the next line must complete it) and the
refutable pattern match takes place in the lambda binding. But because
of the
On Sun, May 9, 2010 at 7:27 AM, wren ng thornton w...@freegeek.org wrote:
The only examples I can think of where we'd want 'fail'-able patterns are
entirely pedagogical (and are insignificantly altered by not using
'fail'-able patterns). I can't think of any real code where it would
actually
On May 9, 2010, at 06:18 , Ben Millwood wrote:
On Sun, May 9, 2010 at 7:27 AM, wren ng thornton w...@freegeek.org
wrote:
The only examples I can think of where we'd want 'fail'-able
patterns are
entirely pedagogical (and are insignificantly altered by not using
'fail'-able patterns). I
Brandon S. Allbery KF8NH allb...@ece.cmu.edu writes:
I've always had the feeling that if I need catMaybes, I haven't
thought through the data representation (or possibly manipulation)
fully.
I've used catMaybes in several places: for example, in SourceGraph only
interesting analyses are
On Sat, May 8, 2010 at 1:16 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
David Menendez d...@zednenem.com writes:
On Sat, May 8, 2010 at 12:15 AM, Ivan Lazar Miljenovic
Well, any time you have a do-block like this you're using failable
patterns:
maybeAdd :: Maybe Int -
David Menendez d...@zednenem.com writes:
That does not invoke fail.
Let's take a simpler example: do { x - Nothing; stmt }. This translates to
let
ok x = do { stmt }
ok _ = fail ...
in Nothing = ok
By the definition of (=) for Maybe, 'ok' is never called.
As I said in another
On May 8, 2010, at 02:16 , Ivan Lazar Miljenovic wrote:
David Menendez d...@zednenem.com writes:
That does not invoke fail.
Let's take a simpler example: do { x - Nothing; stmt }. This
translates to
let
ok x = do { stmt }
ok _ = fail ...
in Nothing = ok
By the definition of (=) for
On Sat, May 8, 2010 at 3:26 AM, John Meacham j...@repetae.net wrote:
What counts as unfailable?
(x,y) probably, but what about
data Foo = Foo x y
If we don't allow it, we add 'magic' to tuples, which is a bad thing, if
we do allow it, there are some odd consequences.
adding another
Yes, I wonder why mtl is not updated so as to remove this restriction.
2010/5/1 John Millikin jmilli...@gmail.com
You might want to make a local version of ErrorT in your library, to
avoid the silly 'Error' class restriction. This is pretty easy; just
copy it from the 'transformers' or 'mtl'
Limestraël limestr...@gmail.com writes:
2010/5/1 John Millikin jmilli...@gmail.com
You might want to make a local version of ErrorT in your library, to
avoid the silly 'Error' class restriction. This is pretty easy; just
copy it from the 'transformers' or 'mtl' package.
Yes, I wonder why
On Sat, May 08, 2010 at 07:49:57AM +1000, Ivan Lazar Miljenovic wrote:
Limestraël limestr...@gmail.com writes:
2010/5/1 John Millikin jmilli...@gmail.com
You might want to make a local version of ErrorT in your library, to
avoid the silly 'Error' class restriction. This is pretty easy;
Personally I think fail is a terrible wart, and should be shunned.
So do I.
I can't understand its purpose since monads which can fail can be
implemented through MonadPlus.
2010/5/8 Ross Paterson r...@soi.city.ac.uk
On Sat, May 08, 2010 at 07:49:57AM +1000, Ivan Lazar Miljenovic wrote:
On May 7, 2010, at 4:54 PM, Limestraël wrote:
Personally I think fail is a terrible wart, and should be shunned.
So do I.
I can't understand its purpose since monads which can fail can be implemented
through MonadPlus.
As far as I can tell, its purpose is to essentially allow you to
On Sat, May 08, 2010 at 01:54:21AM +0200, Limestraël wrote:
Personally I think fail is a terrible wart, and should be shunned.
So do I.
I can't understand its purpose since monads which can fail can be implemented
through MonadPlus.
It was introduced to implement pattern match failure in
On May 7, 2010, at 19:54 , Limestraël wrote:
Personally I think fail is a terrible wart, and should be shunned.
So do I.
I can't understand its purpose since monads which can fail can be
implemented through MonadPlus.
The translation of do syntax involves pattern matching (do
{ [x,y,z]
On Friday 07 May 2010 7:54:21 pm Limestraël wrote:
Personally I think fail is a terrible wart, and should be shunned.
So do I.
I can't understand its purpose since monads which can fail can be
implemented through MonadPlus.
Understanding why fail exists requires going back to before
On Fri, May 07, 2010 at 08:27:04PM -0400, Dan Doel wrote:
Personally, I don't really understand why unfailable patterns were canned
(they don't seem that complicated to me), so I'd vote to bring them back, and
get rid of fail. But hind sight is 20/20, I suppose (or perhaps there exist
cogent
On Fri, May 7, 2010 at 10:26 PM, John Meacham j...@repetae.net wrote:
On Fri, May 07, 2010 at 08:27:04PM -0400, Dan Doel wrote:
Personally, I don't really understand why unfailable patterns were canned
(they don't seem that complicated to me), so I'd vote to bring them back, and
get rid of
Limestraël limestr...@gmail.com writes:
Personally I think fail is a terrible wart, and should be shunned.
So do I.
I can't understand its purpose since monads which can fail can be
implemented through MonadPlus.
Polyparse uses it, and I believe Parsec does as well...
--
Ivan Lazar
David Menendez d...@zednenem.com writes:
I wonder how often people rely on the use of fail in pattern matching.
Could we get by without fail or unfailable patterns?
ensureCons :: MonadPlus m = [a] - m [a]
ensureCons x@(_:_) = return x
ensureCons _ = mzero
do ...
x:xs - ensureCons $
On Sat, May 8, 2010 at 12:15 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
David Menendez d...@zednenem.com writes:
I wonder how often people rely on the use of fail in pattern matching.
Could we get by without fail or unfailable patterns?
ensureCons :: MonadPlus m = [a] - m [a]
David Menendez d...@zednenem.com writes:
On Sat, May 8, 2010 at 12:15 AM, Ivan Lazar Miljenovic
Well, any time you have a do-block like this you're using failable
patterns:
maybeAdd :: Maybe Int - Maybe Int - Maybe Int
maybeAdd mx my = do x - mx
y - my
On May 8, 2010, at 01:16 , Ivan Lazar Miljenovic wrote:
David Menendez d...@zednenem.com writes:
On Sat, May 8, 2010 at 12:15 AM, Ivan Lazar Miljenovic
Well, any time you have a do-block like this you're using failable
patterns:
maybeAdd :: Maybe Int - Maybe Int - Maybe Int
maybeAdd mx
Brandon S. Allbery KF8NH allb...@ece.cmu.edu writes:
On May 8, 2010, at 01:16 , Ivan Lazar Miljenovic wrote:
Huh? What about maybeAdd (Just 2) Nothing ?
Isn't that handled by the definition of (=) in Maybe, as opposed to
by invoking fail?
instance Monad Maybe where
-- ...
Nothing =
On Wed, May 05, 2010 at 02:54:27PM -0700, Ryan Ingram wrote:
ErrorT is just a newtype wrapper, changing the order/application of
the type variables.
newtype ErrorT e m a = ErrorT (m (Either e a))
runErrorT (ErrorT action) = action
This gives the bijection:
ErrorT :: m (Either e a) -
On Thu, May 6, 2010 at 9:56 AM, Eugene Dzhurinsky b...@redwerk.com wrote:
On Wed, May 05, 2010 at 02:54:27PM -0700, Ryan Ingram wrote:
ErrorT is just a newtype wrapper, changing the order/application of
the type variables.
newtype ErrorT e m a = ErrorT (m (Either e a))
runErrorT (ErrorT
On Thu, May 06, 2010 at 10:05:05AM +0200, David Virebayre wrote:
A constructor can be seen as a function that takes some parameters and
produces a value
for example with the type Maybe a, which has 2 constructors ; Just and
Nothing :
Prelude :t Just
Just :: a - Maybe a
the
By the way, I didn't exactly reply your question :
[...] Basically, i don't understand what does ErrorT :: means - it
should name the function - but it starts with capital letter?
It's a type signature, it describes the type of ErrorT:
Prelude import Control.Monad.Error
Prelude
ErrorT is just a newtype wrapper, changing the order/application of
the type variables.
newtype ErrorT e m a = ErrorT (m (Either e a))
runErrorT (ErrorT action) = action
This gives the bijection:
ErrorT :: m (Either e a) - ErrorT e m a
runErrorT :: ErrorT e m a - m (Either e a)
We can now
On Sat, May 01, 2010 at 02:42:26PM -0700, Ryan Ingram wrote:
Check out ErrorT in Control.Monad.Error
:t ErrorT
ErrorT :: m (Either e a) - ErrorT e m a
At this point I am lost. I'm not sure that I do understand this type
transformation correctly. So we have some sort of monadic type m, error
ErrorT :: IO (Either Error String) - ErrorT Error IO String
I can think that can be written as
ErrorT :: IO (Either Error String) - ErrorT Error (IO String)
Am I correct?
No, you're not. Similar to function application, type application is
also left-associative, so it can (but shouldn't)
Hello!
I have some sort of strange question:
assume that there are 2 functions
func1 :: Int - IO (Either Error String)
func2 :: String - IO (Either Error [String])
in case if there will be no IO involved, I could use
Control.Monad.Either and write something like
runCalc :: Int - IO (Either
Check out ErrorT in Control.Monad.Error
:t ErrorT
ErrorT :: m (Either e a) - ErrorT e m a
:info ErrorT
instance (Monad m, Error e) = Monad (ErrorT e m)
:info Error
class Error e where
noMsg :: e
strMsg :: String - e
So, if you can make your Error type an instance of this class, you
You might want to make a local version of ErrorT in your library, to
avoid the silly 'Error' class restriction. This is pretty easy; just
copy it from the 'transformers' or 'mtl' package.
On Sat, May 1, 2010 at 14:42, Ryan Ingram ryani.s...@gmail.com wrote:
Check out ErrorT in
It's called monad transformers
func1' :: Int - EitherT Error IO String
func1' n = EitherT $ func1 n
func2' :: Int - EitherT Error IO String
func2' s = EitherT $ func2 n
runCalc' :: Int - EitherT Error IO [String]
runCalc' param = func1' param = func2'
runCalc :: Int - IO (Either Error [String])
35 matches
Mail list logo
