Greg Michaelson writes:
Incidentally, my point about not bothering to evaluate functional
programs whose final values are functions was serious. Presumably,
people don't generally write programs that return functions as
final values?
I suppose it depends on what you call a "function" from the point of
view of the implementation; however, given any answer that I can think
of, I disagree with this statement. If a function is seen as a piece
of text, think of Mathematica as an example of something that produces
a function as an answer. If a function is seen as an executable
representation, then a compiler is a trivial counter-example. As
another, consider a circuit analyzer that produces a function from
time to voltage that represents a signal at a node in the circuit.
This might be passed to (for example) a graphical display program that
displays it as a trace on the screen.
Even if you think of a function as purely a Haskell-understandable
object, I think this is short sighted. For example, a Haskell program
might produce a function that is stored away and used by a later
Haskell program as data. The Mathematica example is of interest here,
as is the compiler.
Therefore, I disagree strongly with the above statement.
Dave Barton
[EMAIL PROTECTED]
