Am Freitag, 16. September 2005 16:46 schrieben Sie:

. . .

...

In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them. But you can use your do expressions etc. to construct action descriptions with a more general type like MonadIO m => m a. Then you can instantiate m with a monad whose values store part of the action's structure so that this information can be used later. Or you use a monad which doesn't keep structural information to use it for later processing but which does the processing upon construction.

But, isn't this like saying that Java or C++ supports first-class function types because you can define a class with one method, the function of interest, and then create, pass, and return instances of the class? Yeah, you can do that, but it's awfully clumsy.

But I could imagine that doing what I described in Haskell is not awfully clumsy. In fact, I don't like the idea of dealing with code at run-time, except when it is absolutely necessary.

Also, it seems to me that the heart of Haskell is functional, not imperative. Can you create function definitions from data and evaluate them at runtime?

Of course! Just define a function which takes an expression as an argument and returns the corresponding function, i.e., some kind of function parser.

[...]

-- Bill Wood bill.wood@acm.org

Best wishes, Wolfgang