On 28 set, 19:38, Xah Lee <xah...@gmail.com> wrote: > • “list comprehension” is a very bad jargon; thus harmful to > functional programing or programing in general. Being a bad jargon, it > encourage mis-communication, mis-understanding.
I disagree: it is a quite intuitive term to describe what the expression does. > • “list comprehension” is a redundant concept in programing. The > concept is of historical interest. e.g. when people talk about the > history of computer languages. The LC can simply be filter(map(func, > list), predicate). I agree it is redundant. Like pretty much all syntax: all one needs is a way to define functions and to apply function to arguments (or assignment and pre-defined loops for imperative folks). Syntax may still be more convenient, though. Which is strange since you were an ardent syntax lover a few iterations ago. > • The special syntax of “list comprehension” as it exists in many > langs, are not necessary. It can simply be a plain function, e.g > LC(function, list, filter). I disagree. Syntax may be redundant, but it is there to be convenient. I'll quote it again: "For instance, this is far more convenient: [x+1 for x in [1,2,3,4,5] if x%2==0] than this: map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5])) but on the other hand, this is more convenient: map(inc,filter(evenp,[1,2,3,4,5])) (ignoring the lines of code for inc and evenp, of course. But as long as they are used in many parts, it *is* more convenient) In short, list comprehensions are useful syntatic expressions returning lists as long as you don't care for the short functions used in them." > «do syntax does allow for imperative commands to be issued in scheme, > just like let. It does not mean it was used in said examples nor that > do is automatically inherently imperative just because of choice of > name. imperative do -> (do (steppers ...) (final-condition? result) > malign-imperative-code-here ...)» > > i don't think your argument is forceful enough. > > It appears that by this argument you even say that “let” is not > functional. In the case of Lisps, it depends on context: let is an expression returning a value, but Lisps are not purely functional languages and you *may* use imperative statements in the body, resulting in useful side-effect computations. That's why I said do is no more imperative than let: 1) because it *is* let and 2) because Lisps *allow* imperative constructs in the body of lambdas. do is not inherently imperative in the same sense Lisp/Scheme is not inherently imperative: they allow you to do purely functional evaluation of expressions but also to tint the computations with side-effects... your choice. > So, overall, i consider your argument for “do” in Scheme lisp being > functional is weak, or trivial. It seems to be a pet peeve. It is a pet peeve in that you call `do' imperative without arguments while a few other Schemers call `do' imperative on the basis of political bickering. Nobody gives `do' a chance of the base of it being what it is: a macro transform into let. Any imperative programming you do with `do' will get the same effect as if you do the same imperative programming with let. Imperative or functional, it's up to the user, not inherently from any language construct. > You got > annoyed because i seem to have ignored it entirely. But i got annoyed > by you because you don't get the point about what i consider more > significant opinion on “list comprehension”, which you totally ignored > and kept at hacking the “do” in Scheme lisp. It's because I don't think I have much to comment on list comprehensions other than being useful syntax at times for an expression returning a list. -- http://mail.python.org/mailman/listinfo/python-list
