Bug in and-map and or-map? What am I doing wrong?

[Alejandro Forero Cuervo]

I'm trying this on Guile 1.4, I don't know if it has been fixed in the
CVS version.

I just discovered the `and-map' and `or-map' procedures, which seem
very useful (since `and' and `or' are macros, you can't pass them as
the second argument to `apply', meaning you just can't apply them to
lists... right?).  However, they seem to accept a function and a list
as their arguments, applying it to all the elements in the list and
then making an and (or, in the case of `or-map', an or) to the return
values of the invocations.

Shouldn't they (`and-map' and `or-map') accept any number of lists
(instead of just one list), applying the function to arguments from
all the lists (instead of just to the arguments from the list) like
map does?

For example, you can do:

-=> (map equal? (list 1 2 3) (list 3 2 1) (list 2 2 2))
    (#f #t #f)

So, now, if you really care about an and (or an or) of the elements in
the list, you do:

-=> (and-map equal? (list 1 2 3) (list 3 2 1) (list 2 2 2))
standard input::: In expression (and-map equal? (list 1 2 ...) ...):
standard input::: Wrong number of arguments to #<procedure and-map (f lst)>
ABORT: (wrong-number-of-args)

Boom.

Am I getting something wrong, or is this really a bug?

Thanks! :)

Alejo.
http://bachue.com/alejo

--
The mere formulation of a problem is far more essential than its solution.
      -- Albert Einstein.

$0='!/sfldbi!yjoV0msfQ!sfiupob!utvK'x44;print map{("\e[7m \e[0m",chr ord
(chop$0)-1)[$_].("\n")[++$i%77]}split//,unpack'B*',pack'H*',($F='F'x19).
"F0F3E0607879CC1E0F0F339F3FF399C666733333CCF87F99E6133999999E67CFFCCF3".
"219CC1CCC033E7E660198CCE4E66798303873CCE60F3387$F"#Don't you love Perl?

pgp0_WYvQljBA.pgp
Description: PGP signature