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.
>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 repr
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: lis
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
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 i
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 t
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 ...
I'l
