Re: [Haskell-cafe] [Alternative] change some/many semantics

On Wed, Dec 21, 2011 at 12:37 PM, wren ng thornton wrote:

On 12/19/11 10:20 PM, David Menendez wrote:

...

On Mon, Dec 19, 2011 at 6:37 PM, wren ng thornton  wrote:

...

On 12/14/11 10:58 PM, Gregory Crosswhite wrote:

...

Of course, this is not a simple change at all because it would have to be done in such a way as to respect the ordering of actions --- that is, we can't have each action executed only when the corresponding element of the list demanded is forced, or else actions would undesirably interleave.

Therein lies the issue. To put this in a monadic context, this is the same reason why we can't just say:

   evalState (repeatM getNext) init

e.g., to generate an infinite list of pseudorandom numbers and then discard the final seed because we have all the numbers we'll ever need.

Sure you can. Just make sure you're using a non-strict state monad.

Fair enough. I over-simplified the example I had in mind, which cannot be evaded so easily.

Though it's worth pointing out that your solution relies on the specific property I mentioned (later in the same email), namely that it is safe to perform the evaluation of lazy state at any point we desire, because it will not interact with other side-effects[1]. Thus, this happens to be one of the monads which has the property necessary for being able to perform the reordering desired by the OP. However, if we try using your 'repeatM' for other monads it is unlikely to work--- and for the same reasons that 'many' and 'some' are problematic for Maybe and lists.

Yes, sequence . repeat is only sensible for non-strict monads, which are fairly uncommon. (Identity, State, Reader, Writer, infinite search, and various combinations thereof are the only ones I'm aware of.) The situation is exactly analogous to many and some, which are only meaningful for certain values in certain types, as well as to functions like fix and folder, which can diverge if given inappropriate arguments. If there were a lot of code that was (1) meaningfully generic over non-strict monads and (2) diverged for strict monads, it might make sense to declare a subclass and restrict those functions to non-strict monads. That won't stop someone from trying to call sequence on an infinite list, but it does express an important precondition of the code in the type. -- Dave Menendez http://www.eyrie.org/~zednenem/