On Jan 15, 1:37 am, William Stein <wst...@gmail.com> wrote:

> This could all be avoided if before changing a variable to maxima we
> prepended it with _sage_var_ (say), and stripped those off when moving
> from maxima back to Sage.  This is worth considering...

Well, I think there is a neater way to go about it, which is
to exploit the Lisp package (i.e. namespace) machinery.
In summary, one can define groups of symbols at run time.
(A symbol package is a dynamic, not lexical, construct.)
So the general strategy would be to create a Sage namespace
and work within that, so that Sage symbols could be
distinguished from similarly-named ones in the Maxima namespace.

Some time ago I created a Maxima add-on named namespaces
to expose the Lisp package stuff. It more or less works as
intended but there are probably surprising effects related to
some Maxima symbol being visible or invisible. Also if you're
accustomed to lexical namespaces (as in Java and, for the
most part, Python) then dynamic namespaces might be
surprising.

A bare outline of the use of this namespace package:

load (foo);
load (bar);
/* ... and any other Maxima add-ons ... */
load (namespaces);
/* At this point any existing Maxima symbols are
 * visible in new packages. Any new symbols e.g. blurf
 * are visible only if qualified.
 */
blurf : 1234;
in_namespace (sage);
blurf : 5678;
blurf;
 => 1234
maxima|blurf;
 => 5678
in_namespace (maxima);
blurf;
 => 1234
sage|blurf;
 => 5678

I've probably promoted this idea before, and I'll probably
do so again; sorry for the repetition. As ever I wouldn't
mind having some help to finish it, if only some complaints
"well, it would be more useful if it would do Y instead of X ...".

FWIW

Robert Dodier
-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to