Comments on: Merging partial values

By: Conal Elliott » Blog Archive » Lazier functional programming, part 1

Conal Elliott » Blog Archive » Lazier functional programming, part 1 — Mon, 13 Sep 2010 22:23:31 +0000

[...] In a strict language, where there are only two boolean values, these two clauses have a straightforward reading. (The reading is less straightforward when patterns overlap, as mentioned in Lazier function definitions by merging partial values.) In a non-strict language like Haskell, there are three distinct boolean values, not two. Besides True and False, Bool also has a value ⊥, pronounced “bottom” for being at the bottom of the information ordering. For an illustration and explanation of information ordering, see Merging partial values. [...]

By: Conal Elliott » Blog Archive » Nonstrict memoization

Conal Elliott » Blog Archive » Nonstrict memoization — Wed, 14 Jul 2010 02:47:34 +0000

[...] “⊑” means has less (or equal) information content, as explained in Merging partial values. In other words, if you tell f more about an argument, it will tell you more about the result, [...]

By: conal

conal — Mon, 12 Jul 2010 04:14:16 +0000

Hi Luke. Thanks for another insightful comment.

Your use of unamb in defining if' does not meet the required precondition (of information-compatible arguments). From a conversation on #haskell, I know you've come up with a really beautiful correct definition. I'd love to see you post the correct version for all to admire.

By: Conal Elliott » Blog Archive » Exact numeric integration

Conal Elliott » Blog Archive » Exact numeric integration — Mon, 28 Dec 2009 18:25:53 +0000

[...] is perfect for the job because its meaning is exactly to combine two pieces of information. See Merging partial values and Lazier function definitions by merging partial [...]

By: Conal Elliott » Blog Archive » Another angle on functional future values

Mon, 05 Jan 2009 05:49:34 +0000

[...] It took me several days of doodling, pacing outside, and talking to myself before the idea for unamb broke through. Like many of my favorite ideas, it’s simple and obvious in retrospect: to remove the ambiguity of nondeterministic choice (as in the amb operator), restrict its use to values that are equal when non-bottom. Whenever we have two different methods of answering the same question (or possibly failing), we can use unamb to try them both. Failures (errors or non-termination) are no problem in this context. A more powerful variation on unamb is the least upper bound operator lub, as described in Merging partial values. [...]

By: Luke Palmer

Luke Palmer — Sat, 22 Nov 2008 09:42:09 +0000

I played with almost exactly the same thing quite a while ago. I always felt that this should work in Haskell:

if _|_ then [1..] else [1..] = [1..]

Semantically, I wanted if with these properties:

if True  then a else b = a
if False then a else b = b
if _|_   then a else b = a `lub` b

So I made a Lub class just like this and implemented it:

if' :: Bool -> a -> a -> a
if' c x y = (if c then x else y) `lub` x `lub` y

Which was pretty cool. Unfortunately on my motivating example, it did work, but it crawled like a snail; using 100% cpu and outputting about 2 elements per second.

I wonder if there is some runtime support that would make this speedier.

And I cannot get your alleged markdown support to work...