Evil code

Thomas Davie

3 Oct 2006 3 Oct '06

8:50 a.m.

Hello list, I am in the process of testing a debugger, and need some examples to throw at it. It's based on hat, so the normal rules about nothing that uses glasgow extensions or ffi apply. But I'm hitting a bit of a wall. Do any of you have some examples of nasty uses of higher order code. For example CPS, or non-IO monads. TIA Bob

Show replies by date

Tony Morris

3 Oct 3 Oct

10:09 p.m.

[Tangent] Please excuse my ignorance, but it seems there is assumption of general acceptance that CPS incorporates "Evil code". Are you able to support this or refer to a document that does? Thanks for any pointers. Tony Morris http://tmorris.net/ Thomas Davie wrote:

...

Hello list, I am in the process of testing a debugger, and need some examples to throw at it. It's based on hat, so the normal rules about nothing that uses glasgow extensions or ffi apply. But I'm hitting a bit of a wall. Do any of you have some examples of nasty uses of higher order code. For example CPS, or non-IO monads.

TIA

Bob_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Thomas Davie

10:13 p.m.

On 3 Oct 2006, at 23:09, Tony Morris wrote:

...

[Tangent] Please excuse my ignorance, but it seems there is assumption of general acceptance that CPS incorporates "Evil code". Are you able to support this or refer to a document that does? Thanks for any pointers.

Tony Morris http://tmorris.net/

The evil code and CPSness were actually intended to be completely separate entities. I needed (and to a lesser extent now still need), examples that are (a) very higher order, and (b) evil and hard to understand the runtime behaviour of. Thanks Tom Davie

Albert Lai

4 Oct 4 Oct

2:36 a.m.

Thomas Davie <tom.davie@gmail.com> writes:

...

The evil code and CPSness were actually intended to be completely separate entities. I needed (and to a lesser extent now still need), examples that are (a) very higher order, and (b) evil and hard to understand the runtime behaviour of.

Generally code that produces and consumes lots of tuples, e.g., common implementations of splitAt, span, mapAccumL (these are list functions), the State monad (Control.Monad.State; you can strip out the "instance Monad" thing and package the code as ordinary functions). Also Phil Wadler's "Monads for Functional Programming" http://homepages.inf.ed.ac.uk/wadler/topics/monads.html#marktoberdorf contains a monadic parser. In section 5.11 "improving laziness" two different ways of coding and their respective laziness effects are shown. This can be further exemplified by debugger traces, methinks.