>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 representations.
>So to manipulate concrete representations of functions in a functional
>language we have to implement functions all over again? But don't we already
>have concrete representations of functions in the original functional language
>implementation? All (all?) I'm proposing is to print them out.
Yes we do, and it's fine for the *implementation* to print such things out.
But it is NOT fine to cross the dividing line of (1) the implementation, and
(2) the language it implements. As I believe I have made abundantly clear
a showFun function which exists *within* the language destroys many of our
reasoning properties.
>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? Maybe functions are the only types in functional languages
>which are not 1st class objects - full orthogonality doesn't
>stretch to printing functions. And we call this functional programming?
This is silly (excuse my frustration). There are lots of things you can't
do with all sort of types. You can't apply a list to a value and hope it
makes sense, for example. I don't see it as surprising that there are
things you cannot do with functions as a consequence of their nature.
Let's go back to the lambda calculus again. Here are some lambda terms
which we may hope exist within the calculus. I state their defining
property and whether
such a term exists or not. The properties are universally quantified over
ALL lambda terms E.
a E = E Yes
b [E] = [E] Yes
c [E] = E Yes
d E = [E] NO
It's not that I am being restrictive, or hooked on semantics, or anything
like that. It is simply a matter that no such lambda term exists. Try to
write one if you like.
Now of course, when we look on the calculus *from the outside* then we can
see into the internal structure of terms. So looking from the outside gives
a richer
view than looking in. So as I said before, it *is* ok for an implementation
to provide information about the structure of closures etc., but it must
not be done via a showFun function within the language.
John.
