This article was nominated for deletion on 20 July 2016. The result of the discussion was no consensus. |
This disambiguation page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||
|
The contents of the Purely functional page were merged into Purely functional data structure. For the contribution history and old versions of the merged article please see its history. |
The contents of the Purely functional page were merged into Purely functional programming. For the contribution history and old versions of the merged article please see its history. |
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)
Okasaki doesn't give the routine for deletion of Red-Black Trees. Since this encyclopedia article is basically a selection from his book and you mention that one specifically I think we should do the deletion case. Anyone else agree? — Preceding unsigned comment added by Jbolden1517 (talk • contribs) 2006-04-27T05:33:02 (UTC)
I think lazyness and data structures deserves more explanation. Its one of the areas where functional languages differ and thus efficiency computations give different results. — Preceding unsigned comment added by Jbolden1517 (talk • contribs) 2006-04-27T05:33:02 (UTC)
It's artificial, the simpler solution is to keep one common thesaurus and one private for each user and search in both than to impose additional requirements on the data structure.
--78.0.85.5 02:55, 12 September 2007 (UTC)
User:Brianski added XML comments to the article body. They should be discussed here on talk. LotLE×talk 23:36, 31 December 2007 (UTC)
Somebody please post the definition of "T" in the code snippet below:
fun insert (x, E) = T (E, x, E) | insert (x, s as T (a, y, b)) = if x < y then T (insert (x, a), y, b) else if x > y then T (a, y, insert (x, b)) else s
—Preceding unsigned comment added by 71.72.235.91 (talk) 08:21, 24 December 2008 (UTC)
Not only that, but, I think that "else s" should be "else x". Shouldn't it? What language is this, anyway? Haskell?130.63.92.162 (talk) 17:49, 22 April 2010 (UTC)
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)
I strongly suggest that this article is removed. "Purely functional" is not a term of computer science as this article says, it doesn't mean anything indeed. I think the authors of this article are confused with the common term "Purely functional programming language" and the not so common or accepted "Purely functional data structures". Making an article called "purely functional" puts the two terms at the same level when the first one is really much more important. I'm not familiar with wikipedia so maybe someone who knows how this works and agrees with me can make the formal request for deletion. —Preceding unsigned comment added by 190.139.62.23 (talk) 07:03, 5 June 2009 (UTC)
I'll further discourage simply changing the name of this article to "Purely functional data structures", as this is the name of a book, and not the name of a class of structures as this article suggest. You can search the data structures named in the article as "examples" and you'll see that none of them are listed as a "functional data structure", the only thing that relates them to functional languages is that the later use them, but the same can be said about imperative (ie. not functional) languages. I really don't see any part worth saving of this article. — Preceding unsigned comment added by 190.139.62.23 (talk) 2009-06-05T07:27:50
Just as a point, the tree diagram is wrong the f in blue should be an f' not f. jbolden1517Talk 12:21, 6 Jun
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)
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)
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)
A longer version can be found here, including examples that have been since moved to Persistent data structure. Diego (talk) 11:50, 2 August 2016 (UTC)