Either the partial answers you start to get will differ at some point (in which case you are done), or you will get to the end of both without encountering a difference (in which case you are done), or you will keep evaluating forever (in which case the answer was \bot anyway).

(Is this the gist of it? Or am I missing a different reason?)

]]>`if-then-else`

and `either`

. Just fixed module name.
Thanks to Luke Palmer for the suggestion, via Twitter.

]]>luqui: “@conal, lazier? Not laxer?”.

conal: @luqui For the module name? “Laxer” would be more fitting than “Lazier”, wouldn’t it?

luqui: @conal, well according to the motivating blog posts, yes. I’m wondering why you went to the trouble to find a good term then didn’t use it.

conal: @luqui simple reason: i forgot. just fixed. thanks!

Suppose you define `h = eitherL f g`

(for some functions `f`

and `g`

), and then apply `h`

to several `Either`

-valued arguments.
Then under GHC or GHCi, the work of computing `f ⊥ ⊓ g ⊥`

will be done just once, not repeatedly.

Now suppose instead that `eitherL`

were defined as

eitherL f g x = (f ⊥ ⊓ g ⊥) ⊔ either f g x

and again, define `h = eitherL f g`

(for some functions `f`

and `g`

).
In this case `f ⊥ ⊓ g ⊥`

will get redundantly computed every time h is applied, because it is expressed within the scope of the “`λ x → ...`

” (after desugaring).

The same sort of operational difference holds between the two following denotationally-equivalent expressions:

const (nthPrime 100000) _ -> nthPrime 100000

Couldn’t an evaluator easily detect ( f ⊥ ⊓ g ⊥ ) as a common subexpression in two different applications of eitherL’ f g?

What do you mean by an “evaluator” in this question? Something that structurally analyzes and transforms thunks at run time?

If you’re asking about compilers, then my understanding is a compiler could perform the same code transformation that I applied, and that GHC intentionally does not, so as to avoid space leaks.

]]>```
eitherL' f g x = ( f ⊥ ⊓ g ⊥ ) ⊔ either f g x
```

, seems to generally have the same properties as your implementation.

On the other hand, I’m not certain if it “allows computing ( f ⊥ ⊓ g ⊥ ) just once and reusing the result for different values of the third argument”. Couldn’t an evaluator easily detect ( f ⊥ ⊓ g ⊥ ) as a common subexpression in two different applications of `eitherL' f g`

?