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