The Maxima convention is that anything that is non-atomic should have a
symbol as its caar, that is, be of the form ((<operator> <flags>...) ...).
That is why MQAPPLY was invented -- to apply non-symbols to arguments.
-s
On Thu, Jun 13, 2013 at 4:52 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
> On Wed, Jun 12, 2013 at 1:24 PM, Stavros Macrakis <macrakis at alum.mit.edu>
> wrote:
>
> > I think the two possible behaviors are:
> >
> > A) subst( lambda([x],g(x)), 'f , f(q) ) => lambda([x],g(x))(q)
> >
> > B) subst( lambda([x],g(x)), 'f , f(q) ) => g(q)
> >
> > (B) is the current behavior. It seems wrong in principle, because the
> > transformation lambda([x],g(x))(q) => g(q) is performed by evaluation,
> not
> > by simplification; that is, '(lambda([x],g(x))(q)) does not simplify to
> > g(q).
> >
> > Another example of how (B) is inconsistent with other cases of subst:
> >
> > subst( print , 'f , f(23) ) => print(23) <<< does not print
> because
> > it does not eval
> > subst( lambda([x],print(x)), 'f, f(23) ) => 23 <<< prints and
> returns
> > 23 because it does eval
> >
> > However, (B) is a handy idiom, which Barton in particular is very fond
> > of....
>
> Agreed on all points. I'll see what I can do -- it turns out that it
> will necessary to modify 'substitute' as well as SIMPLIFYA,
> since at present subst(foo = lambda(...) ...) constructs an
> expression which is mishandled in general -- the operator is
> an expression and that causes trouble for code which assumes
> it is a symbol. I don't know if nonatomic operators are supposed
> to be OK -- anyway I am inclined to modify 'substitute' to construct
> an expression with MQAPPLY as the operator (and the lambda
> expression as its first argument).
>
> best
>
> Robert Dodier
>