revising ev, was: problem with "concatting variables"

We could even generalize unquote to other places where Maxima doesn't
evaluate an argument, namely named and anonymous function definition.
 Unlike ''(...), I'd propose that it take effect when Maxima evaluates the
expression (and implicitly quotes it).  Thus:

Current behavior:
         a:2$
         f() := ''a$      ...    f() => 2
         (a:3, f():=''a)   ...  f() => 2   <<< because the evaluation
happens at read time, before a is reset
         block([a:7], f():=''a)  ...  f() => 3
         block([a:9], lambda([],''a))() => 3

Proposed behavior:

         a:2$
         f() := unquote(a)$  ...  f() => 2    <<< same behavior
         (a:3, f():=unquote(a))   ...  f() => 3
         block([a:7], f():=unquote(a))  ...  f() => 7
         block([a:9], lambda([],unquote(a)))() => 9

This would require a full scan of any nested :=/lambda/etc. expressions,
but that doesn't seem terribly onerous. A flag could be rplaca'd into the
expression to say that there are no included unquotes for efficiency if
that matters.

           -s




On Thu, Sep 26, 2013 at 3:58 PM, Stavros Macrakis <macrakis at alum.mit.edu>wrote:

> On Thu, Sep 26, 2013 at 2:27 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
>
>> ...
>>
> That's a good idea. It occurs to me that a user might expect
>> 'eval' or any evaluation function to evaluate stuff in contexts
>> in which it isn't otherwise.
>> E.g. '(1 + eval(x)) => (1 + <value of x>) ??
>> I'm not too attached to this idea -- just throwing it out for
>> consideration.
>>
>
> Yes, some power users would find that useful -- maybe something like the
> Lisp comma convention `(... ,x) should be added to buildq, e.g.
>
>          buildq([],1+unquote(x))
>
> But I don't think it should share the name 'eval', it should have a unique
> name not used elsewhere to avoid confusion.  But in any case, I don't think
> regular (non-power) users will find this particularly useful.
>
> By the way, in looking at the doc for buildq, I see one place we are
> misleading users:
>
>
>      Examples
>      `a' is explicitly bound to `x', while `b' has the same binding
>      (namely 29) as in the calling context, and `c' is carried through
>      verbatim.  The resulting expression is not evaluated until the
>      explicit evaluation `''%'.
>           (%i1) (a: 17, b: 29, c: 1729)$
>           (%i2) buildq ([a: x, b], a + b + c);
>           (%o2)                      x + c + 29
>           (%i3) ''%;
>           (%o3)                       x + 1758
>
>
> Note the incorrect statement  the explicit evaluation `''%' !!  Argh!! No
> wonder users are confused!
>
>              -s
>
>