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 > [EMAIL PROTECTED] Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe