As a workaround, you can experiment with (yes, it's ugly)
(%i1) myouter(f,lists):=block([ff : buildq([f], lambda([x],
block([lists], f(x))))], outermap(ff,lists))$
(%i2) myouter('cos,[[1],[2]]);
(%o2) [[cos(1)],[cos(2)]]
(%i3) myouter(lambda([x],x^2),[[1],[2]]);
(%o3) [[1],[4]]
(%i4) myouter(f,[[1],[2]]);
(%o4) [[f(1)],[f(2)]]
I think the block([lists], ...) in the lambda form is needed; without
it, things like
(%i5) myouter(lists,[[1],[2]]);
(%o5) [[lists(1)],[lists(2)]]
will give errors.
Barton
-----maxima-bounces at math.utexas.edu wrote: -----
>To: "Maxima mailing list" <Maxima at math.utexas.edu>
>From: praimon <praimon at gmail.com>
>Sent by: maxima-bounces at math.utexas.edu
>Date: 06/26/2007 01:49PM
>Subject: Re: [Maxima] Variables in function definition problem
>
>On 6/26/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
>> Your particular problem comes from a problem in the evaluator which I
>> consider to be a bug. And I believe we can fix it. In general, however,
>> Maxima's current semantics (dynamic scope) will lead to other situations
>> where the names of variables do matter.
>
>Thanks. Until the fix, would explicitly declaring as local all
>variables used on the left side of a function definition bypass the
>general problem, or could that lead to other issues?
>_______________________________________________
>Maxima mailing list
>Maxima at math.utexas.edu
>http://www.math.utexas.edu/mailman/listinfo/maxima