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 fail. But hind sight is 20/20, I suppose (or perhaps there exist
>> cogent arguments that I haven't heard).
>
> 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 constructor to Foo will suddenly change the type of do
> notations involving it non locally. said constructor may not even be
> exported from the module defining Foo, its existence being an
> implementation detail.
>
> All in all, it is very hacky one way or another. Much more so than
> having 'fail' in Monad.
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 $ some_compuation
This is more flexible than the current situation (you can easily adapt
it to throw custom exceptions in ErrorT), but gets cumbersome when
you're doing nested patterns. Also, it does the match twice, but
presumably the optimizer can be improved to catch that if the idiom
became popular.
--
Dave Menendez <d...@zednenem.com>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
