Talk:Purely functional

message: Since the title of this page is an adjective rather than a noun, it violates Wikipedia: Naming conventions. Of course, this may be justified in this case, but if it is I think we should be explicit about it here before someone decides to proactively move it. Deco 21:13, 15 July 2005 (UTC)
replies: text: The article actually spends most of its time discussing purely functional data structures. I vote we rename the page accordingly. Neilc 09:05, 2 December 2005 (UTC)
replies: text: I agree, if the unrelated material is moved out to somewhere suitable. Deco 23:20, 3 December 2005 (UTC)
thread_title:  Name convention breaking 

message: This article should be deleted or heavily reworded based on the following premises: (1) Programmers create novel solutions to problems all the time; this does not make every workable idiosyncrasy eligible to be promoted as a new paradigm, unless it is extremely novel and widely applicable. (2) The actual use of a data structure that can only be modified by duplication and reference is 'extremely" limited in practice. Even in the thesaurus example, what happens if the website updates the master red-black tree? It potentially invalidates every functional reference of the master tree. Thus, all functional references would have to be rebuilt. You might try and argue that modifying the original tree also updates the user's trees, but this is not true, as the referenced trees duplicate some entries in order to maintain the structure of the new tree. There is no way around the fact that this paradigm requires the master tree to be immutable. (3) This example should be merged into a larger concept involving many themes related to the same concept; which is the trade off between memory and processing time--an age old problem. (4) Any programming system that takes input is inherently not a purely functional language. By taking input from the user over the internet, the programming system has read from I/O, which is a side effect; an imperative concept. The example fails to illustrate this point and inaccurately gives an impression of the validity and value of this immutable concept of a static data-structure. In other words, the thesaurus example is not a purely functional one, as the user generated versions of the master red-black tree are not immutable themselves. Which leads to the 5th point. (5) This is a process and not a data structure, yet it is presenting examples of data structures that are purely functional and also giving an example of a purely functional process. This article needs to decide which it is: a treatise on purely functional data structures (which is an misnomer, because data is not functional, logic is), or if it is a treatise on pure functions--which is already covered. --98.208.209.78 (talk) 20:57, 1 February 2009 (UTC)
replies: text: Then how do you explain the purely functional concept of I/O monads? Diego (talk) 16:19, 4 February 2009 (UTC)
replies: text:  I/O is not purely functional that's why it is in a monad and not the main language.  jbolden1517Talk 12:29, 6 June 2009 (UTC)
replies: text:  Monads are a part of the main language in Haskell, they are purely functional, and they handle input/output thanks to the pure concept of a State. So no, I don't think I/O is an inherently imperative concept. You say "By taking input from the user over the internet, the programming system has read from I/O, which is a side effect", but in Haskell it is not a side effect, it's a function evaluation. Diego (talk) 15:30, 6 June 2009 (UTC)
replies: text:   The idea of the I/O monad came from Imperative Functional Programming by Wadler.  Yes they are imperative and no they are not purely functional.  For a more modern treatment, specific to Haskell Handling the awkward squad , "We begin with an apparently fundamental conﬂict. A purely functional program implements a function; it has no side effect.... Well, if the side effect can’t be in the functional program, it will have to be outside it." jbolden1517Talk 15:43, 6 June 2009 (UTC)
replies: text:  This is partially a confusion of concepts. Monads are not "imperative"; they are purely functional constructs, which you can easily see by desugaring them to regular, run-of-the-mill Haskell functions. The implementation of the IO monad by Haskell, when being evaluated, does perform I/O, which is of course a side-effect. This is completely unrelated to its being a monad (which, again, is a purely functional concept), but is instead related to the implementation of this particular monad, the IO monad. 200.0.230.235 (talk) 17:49, 30 September 2014 (UTC)

text: I totally agree. The Red-Black tree example is bad for a number of reasons, another of which is that Red-Black Trees are defined as such because of the algorithm they use to remain balanced through changes, but the tree is defined as immutable, so it cannot change. The proper term should be 'balanced binary tree', and it should be explicitly explained what the purely functional approach does that is different, its too vague.  —Preceding unsigned comment added by 70.57.74.3 (talk) 02:14, 11 June 2009 (UTC)
thread_title:  Scope 

message: Just as a point, the tree diagram is wrong the f in blue should be an f' not f.  jbolden1517Talk 12:21, 6 Jun
:It is.  The prime symbol is just difficult to see in the font that Wikipedia uses to rasterize the SVG. — Xaonon (Talk) 20:17, 10 August 2009 (UTC)
thread_title:  tree diagram 

message: I propose moving the discussion of purely functional data structures to Persistent data structure, since purely functional data structures are persistent data structures.  The current data structure explanation is confusingly fragmented between the two pages, and I think it would be much clearer in one place.  The Purely functional page would remain, but without over-weighting the data structure content.  This structure would avoid the previous objections to entirely merging Purely Functional into Persistent Data Structures.  Thoughts? Billgordon1099 (talk) 02:17, 5 April 2011 (UTC)
thread_title:  Move data structures part of page to Persistent data structure

message: The article starts with the sentence that  Purely Functional is a term in computing used to describe algorithms, data structures, or programming languages that exclude destructive modifications (updates) of entities in the program's running environment. It then justifies this claim by referencing the Haskell language.  However, Haskell *can* do 'destructive' updates.  It simply guarantees that all functions will be referentially transparent (and therefore side effect free), not that they won't perform destructive updates.  An example of this is the ST Monad which can (among many things) be used to operate on a mutable array.  Therefore, I suggest the definition of "Purely Functional" be changed to "Purely Functional is a term in computing used to describe algorithms, data structures, or programming languages that guarantee referential transparency, often by excluding destructive modifications (updates) of entities in the program's running environment".   — Preceding unsigned comment added by 98.189.26.19 (talk) 02:40, 15 October 2013 (UTC)
thread_title:  Core definition is wrong 

message: An old version of the article was deleted and substituted by a Disambiguation page with this edit. Diego (talk) 11:42, 2 August 2016 (UTC)
thread_title:  PRESERVE