Multiple plots: oddities (bugs?), missing features in Xmaxima and wxMaxima

Virgil L <virgilinux at yahoo.com> writes:
> It is also relevant that -- as far as I know -- ?the
> explicit/implicit?declaration is used EVERY time, even in the simplest
> of all plots, whereas other specifications are only used in certain
> cases.?

This is not true.  explicit() and implicit() are just two of many
different kinds of graphic objects understood by draw2d.  Others
include: bars(), ellipse(), errors(), image(), label(), parametric(),
points(), polar(), polygon(), quadrilateral(), rectangle(), region(),
triangle(), and vector().  More may be added in the future.

draw2d is a very general drawing tool that accepts a list of graphic
objects and graphic options.  explicit() and implicit() are not
declarations, they are graphic objects.

However, the biggest problem is that an equation passed to draw2d() is
currently interpreted as a graphic option that affects all graphic
objects that follow it, for example:

  draw2d(color=purple, line_width=2, explicit(x^2, x,0,1));

  draw2d(points_joined=true, point_type=filled_circle,
         points(makelist([x,x^2], x,0,4)));

  draw2d(ip_grid=[100,100], proportional_axes=xy,
         implicit(x^2+y^2=1, x,-1.2,1.2, y,-1.2,1.2));

So you see, an equation at the beginning of draw2d's parameter list
already has a well-defined meaning.  In order to implement what you
suggest, we'd have to overload the meaning of an equation at the
beginning of the parameter list, which would create the potential for
symbol name conflicts between draw2d's options and user's equations.
For example, you might become quite accustomed to using this abbreviated
form, and then one day you decide to plot the following equation:

  draw2d(delay=R*C, ...);

but now it will fail, because delay happens to be the name of an
existing graphic option.  Or worse, you may have a script that you have
published somewhere, and then later it breaks because a new graphic
option is added to draw2d that conflicts with a variable name in your
equation.  This, in turn, would create pressure on Mario to avoid simple
option names, and instead choose complex names that are unlikely to
conflict with user's equations.

Having said all of this, I can sympathize with your desire to advocate
for a simpler draw2d interface for the common cases.  In retrospect,
maybe it would have been better to use a different syntax for options,
ideally some nice looking infix operator like "->" that would be used
consistently across Maxima for keyword-style parameters.  Unfortunately,
we cannot make that change now without breaking lots of existing code.

Fortunately, as Mario has already pointed out, it is trivial to create
convenience functions for the common cases you want.

    Best,
     Mark