[Haskell-cafe] Do you recognize this type?

[Corentin Dupont]

On Fri, Jun 20, 2014 at 4:55 PM, Chris Warburton <chriswarbo at googlemail.com>
wrote:

> Corentin Dupont <corentin.dupont at gmail.com> writes:
>
> > Nobody on that?
> > What I really want is: a computation that can be interrupted if enough
> > result is already there.
> > I would be surprise if that concept doesn't exist already somewhere :)
>
> I'd be surprised if this can be done with Applicative without some
> hackery.
>
> Very roughly, we can think of Functors as one-shot actions. For example,
> the IO instance of Functor lets us perform exactly 1 side-effect; all we
> can do with the result is map pure functions over it.
>
> Applicatives are a static chain of actions. For example, the IO instance
> of Applicative lets us chain together any number of side-effecting
> actions, but those actions can't alter the chain itself.
>
> Monads are a dynamic chain of actions. They're like Applicatives, but
> each action can choose which action to perform next based on the
> previous results.
>

wow, I *love* this summary! Thanks for that!


>
> From this perspective, the "shortcut" you're looking for requires the
> ability to choose the next action (count another vote or finish
> prematurely) based on the previous results (the running total). That's
> what Monads are good for, but Applicatives can't do it by themselves.
>

Indeed I could make my DSL a monad instance with some changes, that would
be easy to do. But even not a Monad cannot do the trick: imagine if in a
country, you were asking
the people to vote one by one, only to interrupt them when the result is
known. In fact they have to vote altogether,
in whatever order, and we count the votes as they arrive.

So I think what I need is a sort of Applicative++: not a chain of actions
but a set of actions, all independent from each other (so no monad) and
with no particular order.




>
> There's probably an unsafe* way to do this, which will in fact be safe
> due to your voting invariant ("if there aren't enough uncounted votes
> to change the outcome, the outcome cannot change"). Maybe someone who's
> performed similar optimisations can help.
>
> Good luck!
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140620/fb618639/attachment.html>