revising ev, was: problem with "concatting variables"



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