John, I'm sorry if I've been silly or have caused you frustration. That was
certainly not my intention.
Please note that I've never mentioned showFun functions. All I suggested
was that implementations might display final function values. We seem to
agree that this is theoretically acceptable.
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
John says we can't go from a function to its concrete representation
ie E - [E] - OK. He hints that implementations are from concrete
representations to real functions ie [E] - E. I disagree profoundly.
I'm not surprised you disagree. I hinted no such thing. Implementations
manipulate
John says we can't go from a function to its concrete representation
ie E - [E] - OK. He hints that implementations are from concrete
representations to real functions ie [E] - E. I disagree profoundly.
Implementations are from concrete representations to concrete
representations. Suppose E1 is
Mark's suggestion for declaring the selector functions
within the datatype already exists in the language OPAL
(developed at TU Berlin). Besides selectors, you also get the
test predicates there.
Example: the declaration
DATA list == empty
:: (first:char, rest:
Here's an idea, going back a few years, for a small extension to
Haskell that would make it a little easier to define datatype
selector functions. I'm curious to see what other people think
about it, but I'm not sure that I want to put this forward as
a proper proposal for 1.3 or 2.0 or ...
Mark Jones writes:
...
The proposal I have outlined above avoids these problems by allowing the
programmer to write:
data Date = Date (day::Int) (month::Int) (year::Int)
Of course, programmers can already include definitions of these functions
in their code, but the fact that the
