Talk:List comprehension

From Wikipedia, the free encyclopedia

[edit] History

"The earliest reference to the list comprehension notation is in Rod Burstall and John Darlington's description of their programming language, NPL from 1977, but already SETL had a similar construct." -- I don't understand this phrase. If SETL already had such a construct, how can the NPL one be the first reference? Is it the first occurence of the term, or is the SETL construct actually different?

The FOLDOC reference has similar, unclear statements. It's sometimes difficult to know which constructs "are the same". I can tell that SETL has a similar construct called a "tuple former" (see eg http://www.settheory.com/Chapters/Chapter_3.html). But it also works for sets (a "set former") and can contain quantifications forall and exists. It might also be that there are no accepted "references" about SETL. --TuukkaH 09:57, 28 August 2006 (UTC)

[edit] Forms of List Comprehension

"Certain lists are too complex to express by other means." -- An example would be nice.

It could be easier to give for the previous formulation: "Thus the resulting operation can be complex to express in other means." One example of advanced list comprehension use I've seen is the Haskell solution and generalization here: http://www.frank-buss.de/challenge/index.html --TuukkaH 22:28, 31 August 2006 (UTC)

[edit] I just don't get it

This definition seems to only make sense if you already know what a list comprehension is! In which case -- why would you be looking up the definition?

Let me take it apart, to try and demontrate what I mean:

"In programming languages, list comprehension is a construct for list processing, analogous to the set-builder notation (set comprehension), that is, the mathematical notation such as the following:"

Okay -- so it's a 'construct for list processing' -- that seem to be categorising it, not explaining it.

And it's 'analogous to the set-builder notation (set comprehension)' -- so we've said that it's similar to set comprehension.

This seems to be uniquely devoid of any description... to summarise:

"List comprehensions are a construct for list processing, that is similar to set comprehensions"

Now getting back to the first few words: "In programming languages" -- this doesn't seem to be accurate. Are list comprehensions limited to functional languages (or perhaps limited to functional languages and the functional parts of mixed-impure functional languages) ?

This definition doesn't resolve some of my own naive questions about list comprehensions.

For example -- is a list comprehension a set of rules that can be used to show that a member doesn't belong to a list?

Or is it a piece of code that theoretically generates a list?

What sort of values is it limited to?

Can a list comprehension apply to something other than numbers? (I think there can... but i don't know)...

59.167.212.209 06:06, 26 March 2007 (UTC)LeonB

Thanks for your comments! A list comprehension denotes a list which is the result of the operations included in the comprehension on input lists. I would've expected the text to give the right idea, although it doesn't contain a definition. For exact definitions, you'll have to turn to the specification of each programming language. I tweaked the intro a bit, I hope it helps at least a little.

I would think we needn't explain that mathematical and programming language constructs can in general work on other types than numbers too, but perhaps someone can find a non-intrusive way to include this. Haskell and Python are the languages we know of, which already shows that list comprehensions are available for both functional and imperative languages like any other expression syntax. --TuukkaH 20:15, 26 March 2007 (UTC)

Thankyou TukkaH! This sentence here: "A list comprehension denotes a list which is the result of the operations included in the comprehension on input lists" Clears it up a bit for me. I quite like your edits! Thank you again! 203.52.70.253 03:32, 27 March 2007 (UTC)LeonB (different IP address today... but still me, i promise)

Although it is nice when a definition of a term does not repeat the term it is intended to define. Just a thought :) dr.ef.tymac 14:35, 27 March 2007 (UTC)