On Wed, May 21, 2014 at 1:38 AM, Evan Laforge wrote:

So perhaps the way forward is to find the old proposal (or make a new one, if it's gone), and see if Idris's solution applies to haskell.

Is Idris's solution written up anywhere? Mind sharing the link? -- Kim-Ee

I heard Idris' author saying during a talk saying that he had once a branch which work even without the `!`. That never got in because it scare users (according to Edwin for no rational reason). I don't know enough the details, but I think dependent typing (and the Eff system) have probably a big role to play here... I mean Idris can go as far as "inferring implementation" so the type system allow the compiler to "understand" more and probably workaround ambiguity that Haskell might not be able to solve now (or even never). That's just a very naive view of the problem, which might be as well erroneous so please correct me if I'm wrong. On 20 May 2014 20:20, Evan Laforge wrote:

On Tue, May 20, 2014 at 12:09 PM, Kim-Ee Yeoh wrote:

...

On Wed, May 21, 2014 at 1:38 AM, Evan Laforge wrote:

...

So perhaps the way forward is to find the old proposal (or make a new one, if it's gone), and see if Idris's solution applies to haskell.

Is Idris's solution written up anywhere? Mind sharing the link?

It's briefly documented in the tutorial, see do notation:

http://eb.host.cs.st-andrews.ac.uk/writings/idris-tutorial.pdf

Looks like the key bit is "will lift expr as high as possible within the current scope". _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- *A\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

I just noticed that the (<-exp) notation would collide with pattern guards. So maybe the Bang ! would be a better notation.

On 05/20/2014 11:19 PM, Brandon Allbery wrote:

I have to admit, I thought that was deliberate; that is, that the proposal was a generalization of pattern guards.

The idea was to extend the "do" notation. So you will never be able to use it for a toplevel declaration, and I originally used a different notation. Hmm the new notation is also ambiguous in a statement. What's supposed to be the difference between. exp <- exp === exp === stmt and pat <- exp === stmt I guess the "<-" in patten guards is a bit miss leading too, as it has nothing to do with monads. It should be a "=" (doesn't work of course) or a "~". I guess the problem is that <- does two things which can be useful individually 1. (>>=) i.e. extract value from monad (what the new <- or ! should do) 2. Assign/Pattern match it. same as("=" in let, "<-" in Pattern guards) too much chaos! silvio

... And I gather that the recent (to me, anyway) lambda-case and lambda-if have abated the incromulence:

https://ghc.haskell.org/trac/ghc/ticket/4359

I thought so too, even though I have no idea what incromulence means, but I can't find anything about lambda-if in the 7.6.3 documentation, and the discussion seems to discount it. It's true (I think) that the use cases are relatively few. The multi-way-if that appears in the trac discussion is apparently, supported but it's a mystery to me if this has anything to do with lambda-if. Donn

On Wed, May 21, 2014 at 2:17 AM, Donn Cave wrote:

The multi-way-if that appears in the trac discussion is apparently, supported but it's a mystery to me if this has anything to do with lambda-if.

Good catch: there's no lambda-if, only multiway-if. Which isn't the same. Lambda-if might look something like this: do ... checkCondition >>= \if then doReportSuccess else doReportFailure Compare to the originally proposed: do ... if <- checkCondition then doReportSuccess else doReportFailure -- Kim-Ee