Evaluation order in map

[William James]

Is it guaranteed that map will apply the function to the list elements in left-to-right order?  Will

Code Select Expand

(map print (sequence 5 8))always produce

Code Select Expand

5678?



In Scheme, the order is unspecified.  SRFI 1 proposes map-in-order, which works from left to right.

[Lutz]

Yes, 'map' will always work the argument lists from left to right for the number of args in the first parameter list and assume 'nil' fo a missing argument, which may cause an error message depending on the function applied.

Code Select Expand


(map list '(1 2 3 4 5) '(a b c))

=> ((1 a) (2 b) (3 c) (4 nil) (5 nil))

(map list '(1 2 3) '(a b c d e))

=> ((1 a) (2 b) (3 c))


Lutz

[William James]

Good. An advantage over Scheme.

A newbie asked the Scheme gurus:

I just want to use a print statement with multiple things inside of it.

This doesn't seem possible. Is there a work-a-round?



(print "the value of variable foo is " foo)

One solution was

Code Select Expand

(define (myprint . args)
   (for-each (lambda (x) (display x)) args))
When I suggested

Code Select Expand

(define (myprint . args)
  (map display args))
I was told that map-in-order (which isn't even in the standard language) would have to be used.

[rickyboy]

No, the first solution is "The Right Way" for Scheme, according to http://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%25_idx_560">R5RS (emphasis mine):

The arguments to for-each are like the arguments to map, but for-each calls proc for its side effects rather than for its values. Unlike map, for-each is guaranteed to call proc on the elements of the lists in order from the first element(s) to the last, and the value returned by for-each is unspecified.

Also, you can drop the lambda too in that person's for-each solution; so that it becomes something like:

Code Select Expand

(define (display+ . args) (for-each display args))

Of course, like you, I don't have any objection to applying the left-to-right argument evaluation order constraint on calls to 'map'.  Any advantage gained by unconstraining 'map' calls (as R5RS does) will be lost in short order by the effects of Moore's Law anyway.  So, Lutz has made a good decision, as you surmised.