revising ev, was: problem with "concatting variables"

John, I think we all agree that Maxima should never give a Lisp
(internal) error.  That is always the wrong behavior, and we should be
fixing these things. A better message in these cases would be: "Maxima
encountered an internal error.  Please report exactly what caused this to
...".

About having length("cat") => length("cat"), I don't agree.  That would
mean that silly errors like

        if length("cat")=3 then a else b

will return b.  After all, the expression length("cat") does not equal 3.
That will be hell to debug, especially for a beginning user.

            -s


On Thu, Sep 26, 2013 at 5:01 PM, John Lapeyre <lapeyre.math122a at gmail.com>wrote:

>
> It would be nice to have a statement on deprecated features.( Maybe it
> already exists) ... to the extent that the experts can agree on
> deprecated features. I keep forgetting what they are and start trying
> to use something that I forgot is evil. Or if not deprecated, state
> clearly that some feature has very limited use. The docs say that ''
> is only applied when it's read, but the implications are maybe not
> clear enough. ev and alias are candidates. alias isn't even just an
> aliasing.  It kind of makes symbols disappear, in a way. It's
> maddening.
>
> Only slightly off topic: If anyone is worried about user-friendliness,
> what is and is not exposed to normal users, power-users, etc,
> something that bugs me every time I see it, and I've mentioned it
> before.
>
> I think users should never (instead of frequently, as it
> is now) see things like this:
>
>  Maxima 5.31.1 http://maxima.sourceforge.net
>  using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL)
>  (%i1) length("cat");
>  Maxima encountered a Lisp error:
>  Error in PROGN [or a callee]: Caught fatal error [memory may be damaged]
>  Automatically continuing.
>  To enable the Lisp debugger set *debugger-hook* to nil.
>
> Anyone who knows how to set the debugger hook and knows how to use
> it, never needs to see this message. It is at best useless
> for the other 99+% of the users.
>
> If I recall correctly, I think once I tried modifying length() to trap
> errors or return the input form and the test suite still passed.
> Maybe length("cat") should print a useful warning and return
> length("cat").
>
> -- John
>
>
> On 09/26/2013 10:07 PM, Richard Fateman wrote:
> > On 9/26/2013 11:27 AM, Robert Dodier wrote:
> >> Stavros Macrakis <macrakis <at> alum.mit.edu> writes:
> >>
> >>> We should really define some clean functions for well-defined subsets
> >>> of the functionality of ev.
> >> Agreed.
> >>
> >>> In particular, eval(...) should do the obvious thing.
> >>> It is trivial to define: (defun $eval (x) (meval x)).
> > In terms of user friendliness, is this the right name for the average
> user?
> >
> > after all
> > x:43;
> > 1+x;
> > comes out 44 because 1+x is evaluated ... to 1+43 and then simplified to
> 44.
> > So everything you type in gets evaluated, though with a few exceptions
> like x
> > in lambda([x] ...)
> >
> > Maybe a better name would be something like re_eval( E); ? almost the
> same as ev(E) ?
> >
> > As food for thought, I offer a description of how Mathlab '68 did
> evaluation. At
> > least as I recall. It was kind of the reverse of Lisp's quote where 'x
> means the
> > symbol x, not its binding or value.
> >
> > Anyway
> > x:=43;
> > 1+x; returns 1+x.
> > 1+'x; returns 1+43 or 44.
> >
> > This works nicely with diff(f(x),x) begin the differential form quoted,
> and
> > 'diff(f(x),x) as the "verb" to compute the derivative.
> >
> > I suppose you could write ''x to evaluate twice.
> >
> > To expect any scheme to really satisfy everyone is probably unrealistic.
> Even
> > after decades of trying to hash this out, Mathematica has a
> mind-boggling mess
> > of 'features'. By default the evaluation there corresponds to ev(E,
> infeval), but
> > with some kind of criterion that 'if it doesn't change, stop.' This
> doesn't quite work
> > all the time but that's the idea.
> >
> >
> > RJF
> >
> >
> >
> >
> >> 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.
> >>
> >>> Do we have any idea why Redfern et al. proposed this peculiar
> >>> way of handling indexed variables? Is it a workaround for the
> >>> failure of Maxima/Macsyma to treat subscripted variables as
> >>> first-class variables in some contexts? (Can we inventory those
> >>> contexts and fix them systematically?)
> >> Agreed.
> >>
> >> best
> >>
> >> Robert Dodier
> >>
> >>
> >> _______________________________________________
> >> Maxima mailing list
> >> Maxima at math.utexas.edu
> >> http://www.math.utexas.edu/mailman/listinfo/maxima
> >
> > _______________________________________________
> > Maxima mailing list
> > Maxima at math.utexas.edu
> > http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>