On 16 February 2013 16:35, Raul Miller <[email protected]> wrote:
> I would be happy to doubt the credibility of wikipedia in the context
> of that sentence, if you would supply a more credible reference which
> contradicts it.
I did refer you to real functional programming languages.
> Can you describe some examples
> of your statement "their functions are not at all 'mathematical
> functions'. The latter holds even of those several languages
> conventionally described as 'purely functional'."?
Some of the reasons that the functions of real programming are not
those of mathematics have already been referred to by Roger, up in
this thread. More generally, in programming, function computation
is inevitably associated with resource consumption, some obvious
examples of resources being time and space. This is very much unlike
functions as usually understood in mathematics, i.e. maps between
sets. E.g. a function computation may need an amount of time or
space greater than the available within our universe, albeit finite.
Computationally, such a function is indistinguishable from a
non-computable one, although it is computable in the formal sense.
Furthermore, programmer's functions not only consume but also create
resources; those sets that functions in mathematics only map to must
actually be brought into existence by functions that are computed
for real. Significant differences also arise from the distinction
between the same function -- and even more importantly, a set of
functions -- being evaluated eagerly or lazily.
Square root, sine, and many other well-known functions compute
approximate rather than mathematically correct results. Moreover,
the deviation varies with the argument. The result can be even
further distorted due to representational specifics. E.g., in J,
under the default settings:
99999.9 + 0.6
100000
99999.9 + 0.7
100001
none of which is correct.
On the other hand, there are mathematically definable functions of
which we have no idea at all how to represent computationally.
So no, functions in programming are not those of mathematics.
> To relate this back to the original context (of "closures" as
> discussed in the context of J): I think that I would restate the
> original statement as "closures are not purely functional, so cannot
> be represented in a purely functional subset of J".
Now there are three things mistaken in this statement. First of all,
closures need not -- in fact, should not -- be discussed solely 'in
the context of J'. They are a general concept, and whether they
contradict functional purity or not does not depend on a specific
language. In my initial post I talked of closures regardless of any
language.
Second, closures may indeed be not representable in a purely
functional subset of some language, J or another, but that is not
necessarily because closures themselves are impure. It might well
be due to the said language providing no adequate means for that.
Third, closures *are* purely functional. In my initial post I
explained that impurity can be injected by allowing to change state
(through assignment or indirect changing of data objects), but it
is not inherent to closures. Closures are but a mechanism for
effectuating the binding of non-local names. I also pointed out
that, by eliminating the variables needing to be closed over, a
closure can be represented as a λ-expression with only explicitly
bound variables.
To illustrate the latter, consider the following example (in Haskell):
f x = \y -> g x y
f is a function of argument x which returns a function of y returning
g x y (assuming g is defined somewhere else). Since g and x are not
defined in the latter function, the value returned by f is actually a
closure of the function \y -> g x y over g and x: a function that
has the values of g and x stored in itself. To emphasize that there
is nothing special or 'non-functional' in the closure, we can
transform the definition of f into one that, instead of implicitly
closing over g and x, explicitly applies a function to g and x to
produce the function eventually returned by f. Thus we obtain f',
which in every respect is equivalent to f:
f' x = (\gg xx -> (\y -> gg xx y)) g x
Note that the only variables in a closure (or in its 'manually'
created equivalent) are its parameters. Therefore a closure is a
'hand-made' combinator, preserving the context where it was created,
and as a combinator it can be used in an argument-free (tacit) style.
Also note that J's dynamic binding of adverbs/conjunctions to their
arguments potentially creates, unlike closures, stateful functions.
Not only are they stateful, but their state is controlled from
outside. E.g. what the verb f/ does depends on what the current
value of f is, including f/ is no verb at all when f has no value.
(I used Haskell above for no other reason but compact expression.
There is nothing specific in this example or in Haskell concerning
closures. In particular, closures have no relation to the monad
mechanism of Haskell.)
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
