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