It seems that the looping constructs don't currently return a value. In other words, they don't return an array of the results. CoffeeScript allows for both scenarios, that is, looping for side-effects and looping that returns an array of results. I'm thinking it would be very useful to have dotimes*, dolist*, for-in*, etc. that return an array of results. Below is an example from coffeescript.org. Let me know what you think.
David
countdown = (num for num in [10..1])
------------------------------------
var countdown, num;
countdown = (function() { var _i, _results; _results = []; for (num = _i = 10; _i >= 1; num = --_i) { _results.push(num); } return _results; })();
On Tue, Jan 15, 2013 at 2:17 PM, David Sargeant david@dsargeant.com wrote:
It seems that the looping constructs don't currently return a value. In other words, they don't return an array of the results. CoffeeScript allows for both scenarios, that is, looping for side-effects and looping that returns an array of results. I'm thinking it would be very useful to have dotimes*, dolist*, for-in*, etc. that return an array of results. Below is an example from coffeescript.org. Let me know what you think.
David
countdown = (num for num in [10..1])
In Common Lisp—and Parenscript—that would be
(loop for num :from 10 :to 1 collect num)
Which expands to roughly the same JS code.
— B. Smilga.
By the way, David's request led me to experiment with different looping constructs in PS, and in the process I noticed that the behaviour of DOLIST diverges from its Common Lisp prototype when used with a RESULT-FORM that references the iteration variable. E. g.:
(dolist (i '(1 2 3) (foo i)) (foo i))
expands to
(function () { for (var i = null, _js_arrvar58 = [1, 2, 3], _js_idx57 = 0; _js_idx57 < _js_arrvar58.length; _js_idx57 += 1) { i = _js_arrvar58[_js_idx57]; foo(i); }; return foo(i); })();
Since JavaScript variables have at least function scope, this effectively evaluates to foo(3), excluding side effects.
On the other hand, CLHS entry for DOLIST (§6.2) contains the following clause:
dolist (var list-form [result-form]) declaration* {tag | statement}* ...
At the time RESULT-FORM is processed, VAR is bound to NIL.
Given this project's goal, stated by Vladimir in a recent message, of bringing PS semantically as close as possible to Lisp, this discrepancy is rather unfortunate, so please find attached a patch to remove it.
— B. Smilga.
parenscript-devel@common-lisp.net
-
Boris Smilga -
David Sargeant