Comments

// domain equation untyped lambda calculus delegate D D(D d);

With the help from the people in #haskell, here's an example:

data D = D {unD :: D -> D} omega = (\x -> unD x x) (D $ \x -> unD x x)

From what I've heard in talks given by Simon Peyton-Jones (MS Research, GHC developer), projects to build graph reduction processors in the past were not very successful.

However, The Reduceron (a current project) might be interesting.

Edit: some slides (pdf)

Is this the paper referenced in the conversation?   When are two algorithms the same?

Hmm, there is some sound clipping when Erik's a bit too enthusiastic?

Edit:

There is also this question for Brian I have since the first co/contravariance C9 video: Is there any literature that uses the same improved ∂ notation?

Ah yes, searching for "MathType font installer" on the web and then install the found installer solves the problem.

The docx file opens and displays fine, but a few characters in the pptx file show up as boxes. Could you upload a PDF version of the slides?

The list type is generally used for parser combinators to return multiple possible parses.

I don't own Hutton's book, but I can think of a few reasons for not using Maybe. It would require introducing a new datatype to the reader, while the reader is already familiar with the list type. Also, it takes more characters to write when pattern matching on a Maybe value .

Now, in a real project you'd use the appropiate data type. If you know that at most only a single answer will be produced, use Maybe.

"Also you might define functions with time-guarantees, that forcefully stop prematurely if they cannot complete within some time;"

Hmm, that's not an easy task. You'd need to encode values as types or you need type constructors that also accept values instead of only types. For example, you'd love to write code like this then:

-- an Int to Int function that takes at most 5 time units someComputation :: Int -> RealTime 5 Int

But now you might also want to do arithmetic at the type level:

-- an example, the type of a function that adds two real-time int results: add :: RealTime t1 Int -> RealTime t2 Int -> RealTime (t1+t2) Int

I think this is getting quite tricky real fast.

(There is a nice way however to pass values around at the type level, see this paper: Functional Pearl: Implicit Configurations —or, Type Classes Reflect the Values of Types)

"The question is: for infinite time, you have bottom, i.e. non-termination. But how much time is bottom? Is it always sufficient to say infinite time or wouldn't it make sense to define more soft times?"

Bottom is the result of anything that fails to produce an answer. I wouldn't overload bottom for computations that do not finish in time, but use the type system instead to tag your values:

-- pseudo-Haskell (no support for values at the type level) data RealTime <Int> a = Result a -- the result of a successful RealTime computation | Aborted -- the result of a computation that took too long

Edit:

Just found this, might also be an interesting read: Pausable IO actions for better GUI responsiveness.

It seems that the animation got lost in the full screen slides.

Anyway, if anyone gets stuck on implementing a more efficient reverse function, here's a hint:

• Define reverse in terms of an auxiliary function.
• The auxiliary function uses an accumulator.

 About the presented Haskell zip function, its definition can be shorter if you reorder the clauses:

zip (x:xs) (y:ys) = (x,y) : zip xs ys zip _ _ = []

Well, ask yourself this: is time always an effect? For example, does the result of sqrt(9) depend on the current time?

But when time does have an effect on the result, the type system should track it. For example, getCurrentTime in Haskell has type IO UTCTime.