On Sun, Feb 17, 2013 at 9:45 AM, Boyko Bantchev <[email protected]> wrote: > 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.
You did indeed mention J in the message I was responding to. But I was asking for a reference for your definition of "functional programming", and this was not a useful mechanism for me to understand what definition you were using. I am already familiar with J, For example, a dictionary search (using http://www.google.com/cse/home?cx=016147560673599814097:rk5jmigdjse) for the phrase "functional programming" finds me zero results. >> 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. I wish you would provide specific references, instead of vague references. The only message I see from him in this thread is: http://jsoftware.com/pipermail/programming/2013-February/031579.html where he suggests it might be more useful to use the word "function" to describe non-deterministic verbs than it would be to restrict it to the deterministic cases. I am not sure I agree with him, but I trust that he may eventually go into this more clearly (or maybe he already has and I have simply forgotten). That said, I will agree with you that "function application" is an abstraction, and in some contexts it's not a useful abstraction. That said, we can represent "maps between sets" using almost any arbitrary computer programming language - we cannot actually implement infinite sets, but that does not prevent us from using symbols which represent them. And, there are mathematical difficulties here -- for example, we might implement something that is trivial while thinking it is not -- but again that does not prevent implementation. That said, computers are woefully inadequate for implementing undefined tasks, so we can only use them to address a more restricted set of tasks. Anyways, I do not see enough material here to think that I have a valid basis for submitting a change to the wikipedia page describing functional programming. > 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: Here we have several linguistic ambiguities. To resolve ambiguities, we can call some of these things "collections of functions", For example a sine which computes an approximate result can be thought of as a different function from a sine which computes more precise results. For example, a square root function which finds positive square roots can be thought of as being a different function from a square root which finds negative results. Another variation here would be a function which returns a collection of results - a square root function which returns a pair of numbers would be a different function from a square root function which returns only the positive square root. Of course, it's trivial to find the negative square root when we have the positive square root. But that does not mean that these cases are not distinct. Similarly, when we talk about sine being a function we are typically limiting ourselves to considering the principal value case - if we are treating a wider range of cases we typically either spell out exactly what the case is, or we do not bother using "function" to label that case. > 99999.9 + 0.6 > 100000 > 99999.9 + 0.7 > 100001 > > none of which is correct. Equality, like numbers themselves, is contextual. And, here, I'd classify the relevant issue as "precision" rather than as having anything to do with the definition of the word "function". > 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. Here, the phrase I have problems with is "not those of". In the context of "functional programming" in current culture I think we typically deal with a subset of mathematics (a constructive subset) . >> 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. I think we can have multiple discussions of closures, and I see nothing wrong with some of them focusing on J. > 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. I think I agree with your words, here. > 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. In a language which I would call a purely functional programming language, there's no distinction between closures and currying. In Paul Graham's examples (http://www.paulgraham.com/icad.html) currying can not be used where he has specified closures. This suggests, to me, that there is a definition of closure which is not purely functional, and that that is an appropriate definition to be using when discussing Paul Graham's challenge. Alternatively, we can ignore this distinction and use a definition of "closure" which matches that of "currying" - but if we do that we need to find another word to describe the kind of complexity Paul Graham was advocating for. > 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. Ok. In J, we might implement that like this: f=:verb define x&g`'' ) though other implementations might be preferable, once more is known about the surrounding context. On the other hand, there's not enough code, here, to implement Paul Graham's challenge -- the existence of lambdas alone does not give you the persistent state changes that he was asking for. > 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. Certainly. And we can use f. to fix this (for example) or we can simply not redefine words. A similar issue arises with Haskell when you edit the file and recompile, or when you copy and paste and expression into some other program (perhaps involving multiple programmers with blog posts or email messages as a transport for the code snippets). > (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.) I understand that issue, and at the moment have no problems with that issue. I had brought monads into the discussion because of their potential relevance for discussing Paul Graham's challenge, not because I thought that they were needed for what I might label "purely functional closures" or "currying". Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
