Hi again,
I was silent for some time but in this time I created QuickCheck tests
for Data.Tree.Zipper which achieve 100% coverage with HPC. I also
created a ticket for it: Ticket #2324
http://hackage.haskell.org/trac/ghc/ticket/2324
The attached file is the current implementation and it contains
Hello,
I think that the modified API (no state monad, and using Maybe) is
quite nice! I implemented a version of the the suggested API using a
slightly different data structure, which makes the code a bit simpler,
I think. I put the code in the Haskell wiki:
http://www.haskell.org/sitewiki/image
Hi,
> It doesn't use State monad anymore and it returns Maybe. This seems to
> be the common preference, is it? Feel free to vote against. Should we
> change Data.Map also? There is another proposal for changes in
> findMin/findMax so it is better to make this two breaking changes
> together rathe
An updated Zipper version is uploaded here:
http://www.haskell.org/haskellwiki/User_talk:Kr.angelov
It doesn't use State monad anymore and it returns Maybe. This seems to
be the common preference, is it? Feel free to vote against. Should we
change Data.Map also? There is another proposal for chan
G'day all.
Quoting Don Stewart <[EMAIL PROTECTED]>:
This is Haskell, we should use Maybe.
This is Haskell, more abstract is good.
I do agree, though, that Monad is arguably the wrong abstraction. Something
like this would arguably be better:
class (Functor f) => Fail f where
return ::
Using 'monad' here makes it easier to make a mistake with the code, as
it permits new kinds of unexpected failure.
This is Haskell, we should use Maybe.
And users that want it can lift Maybe a -> m a
-- Don
(-1) for new uses of fail in place of Nothing.
kr.angelov:
> The monads design is used
On 2008 May 23, at 13:34, Luke Palmer wrote:
On Fri, May 23, 2008 at 10:55 AM, Jules Bean <[EMAIL PROTECTED]>
wrote:
Krasimir Angelov wrote:
The monads design is used in Data.Map i.e.
lookup :: (Monad m, Ord k) => k -> Map k a -> m a
which is widely considered a poor design decision and
On Fri, May 23, 2008 at 10:55 AM, Jules Bean <[EMAIL PROTECTED]> wrote:
> Krasimir Angelov wrote:
>>
>> The monads design is used in Data.Map i.e.
>>
>> lookup :: (Monad m, Ord k) => k -> Map k a -> m a
>
> which is widely considered a poor design decision and a wart on Data.Map.
It is? Can you p
Miguel Mitrofanov wrote:
I think that MonadZero m => ... is better than just Maybe. If you can
have more general solution for free, why fight it?
Because Maybe exists and MonadZero doesn't?
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
I think that MonadZero m => ... is better than just Maybe. If you can
have more general solution for free, why fight it?
On 23 May 2008, at 14:55, Jules Bean wrote:
Krasimir Angelov wrote:
The monads design is used in Data.Map i.e.
lookup :: (Monad m, Ord k) => k -> Map k a -> m a
which is
That is annoying. I remember that there were people arguing that Monad
should be used instead of Maybe but I don't remember the reasons.
Personaly I feel quite happy with Maybe and I am using it in my own
code. There should be a consistent approach in the different libraries
or at least in a single
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jules Bean
>
> Krasimir Angelov wrote:
> > The monads design is used in Data.Map i.e.
> >
> > lookup :: (Monad m, Ord k) => k -> Map k a -> m a
>
> which is widely considered a poor design decision and a wart
> on Data.Map.
>
Krasimir Angelov wrote:
The monads design is used in Data.Map i.e.
lookup :: (Monad m, Ord k) => k -> Map k a -> m a
which is widely considered a poor design decision and a wart on Data.Map.
:-)
Seriously, if you don't return a useful error message, then Maybe is as
good as it gets, why not
The monads design is used in Data.Map i.e.
lookup :: (Monad m, Ord k) => k -> Map k a -> m a
and I think that this will be more consistent.
On 5/23/08, Ross Paterson <[EMAIL PROTECTED]> wrote:
> On Fri, May 23, 2008 at 09:03:29AM +0200, Krasimir Angelov wrote:
> > Alternatively I can use monad
On Fri, May 23, 2008 at 09:03:29AM +0200, Krasimir Angelov wrote:
> Alternatively I can use monad with failure. In other words, there are
> two possibilities:
>
> 1. Use error ".." and types like: TreeLoc a -> TreeLoc a
> 2. Use monad and type like: Monad m => TreeLoc a -> m (TreeLoc a)
I
On Fri, May 23, 2008 at 9:03 AM, Krasimir Angelov <[EMAIL PROTECTED]> wrote:
> if isFirst loc
> then do_something (left loc)
> else i_cannot_go_left
I meant:
if isFirst loc
then i_cannot_go_left
else do_something (left loc)
___
Haskell-Cafe mailin
Aha. I see the point. The current design was influenced from some
other implementation that I spot somewhere in the net. I will change
it but this reminds me of another problem. Most movement functions
raise error if they can't do the movement. This is convenient if you
somehow know that the direct
>
> * Every definition of tp
I meant "of type", forgetting that my emacs abbrevs don't expand in gmail.
On Thu, May 22, 2008 at 2:13 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
> Hi Krasimir,
>
> I had a long exchange with chessguy about this interface, suggesting a
> significant change in sty
Hi Krasimir,
I had a long exchange with chessguy about this interface, suggesting a
significant change in style, simplifying the type. (Incidentally, the
change removed the State and hence mtl dependence.)
The conversation is on http://tunes.org/~nef/logs/haskell/08.05.17, starting
with "12:08:1
Hello Guys,
We have Data.Tree in the standard libraries for a long time but for
some reason we still don't have standard implementation for Zipper. I
wrote recently one implementation for Yi but there are many other
versions hanging around. At least I know for some. I propose to add
one in the sta
20 matches
Mail list logo
