The core problem here is that the 'option' argument of s_list uses the
literal free variable 'x' in the condition.
The 'lambda([x],...)' construction used in sublist has far cleaner semantics
that the arbitrary free variable 'x' being used to represent the argument,
so I would strongly recommend sticking to sublist.
If it is so important to save a few keystrokes at the cost of anomalous
semantics, the better way to define s_list is as a macro (using ::=). But I
don't recommend that.
-s
On Fri, Aug 28, 2009 at 11:11 AM, Robert Dodier <robert.dodier at gmail.com>wrote:
> On 8/27/09, Sheldon Newhouse <sen1 at math.msu.edu> wrote:
>
> > (%t85) s_list(list, option) :=
> > sublist(list, lambda([x], ev(option)))
>
> Incidentally I think it's clearer in general to construct the lambda
> expression you want before you punt to sublist. I think that's
> going to generally be more predictable than trying to control
> evaluation (hard to get just what you want).
>
> Specifically what I mean in this case is something like:
>
> s_list (list, option) := sublist (list, subst (foo=option, lambda ([x],
> foo)));
>
> so by the time sublist sees it, the lambda expression has the right
> stuff pasted into it.
>
> This business about lambda is aside from the bug in sublist
> which I'm going to fix.
>
> FWIW
>
> Robert Dodier
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>