1. (I repeat). Useful subject lines would be
nice.
C Y wrote:
>
> --- "S.H.M.J. Houben"
> <houben@natlab.research.philips.com> wrote:
> > Hello list,
> >
> > I just wanted to add a few remarks:
>
<snip>
>
> > Having that said, I think the code base in Maxima
> > could stand a cleanup.
Undoubtedly true. Much code was written in Maclisp,
circa 1968-75.
> For starters, the code is
> mostly in
> > UPPER CASE, although that is easy to fix.
If it isn't broken, be careful about fixing it.
ANSI common lisp does not distinguish between the
symbols FOO and foo.
>I also saw
>
> > quite a number of occurences of (go ...) (Lisp's
> goto
> > construct).
Removing go's in favor of something else is undoubtedly
a bad idea. If it isn't broken don't fix it.
> More in general, the code is often
> difficult to
> > read and could use more commenting. The code is not
> > very consistent: that much already shows by seeing
> file
> > extensions such as .lisp, .lsp and even .LISP all
> used.
Lots of people wrote parts of the code. Some of the
code was actually "improved" by people who were IMHO
overconfident that they knew "the right way" but
were sadly mistaken. They introduced many layers of
macro expansion, some of which you now see producing
bugs.
Cleaning up the file-name extensions seems OK, but
I think the fixups should be of the form "here is the
newly implemented/tested/improved X module". Not
"I fiddled around with this working code so I could
understand it, and took out whatever I didn't understand,
and I hope it still works for you... it seems ok
in my limited tests." :)
>
> That cleanup would be an extremely good idea, and IMHO
> would probably be good to make the first priority, to
> keep things organized - writing new code is easier if
> what's already there is standard, clean and commented.
>
> > Another problem is all the special support for
> > things like Multics and the old Lisp machine. I
> don't see
> > how we could possibly hope to keep all this in sync
> with
> > new additions.
I assume that no effort will go into maintaining such
compatibility, but such code is clearly marked by notations
such as #+Multics (....)
>
> Are there still any of those machines in actual use?
> We may not have to worry about that at all, and if we
> don't maybe we can clean up the code further by
> removing those parts.
This would not affect much computational code. It would
affect user interface code, which maybe should be
rewritten from scratch.
>
> > Perhaps a policy should be developed on which
> > platforms are officially supported, and what is done
> with
> > code for non-supported platforms (retained as-is?
> updated
> > to track the rest of the source, even if it cannot
> be tested?
> > simply removed?)
>
> OK, here's my reasoning - older versions won't vanish,
> and will still have this support. We should not
> update code we can't test - the minute we do that
> someone will use it to do something important and a
> zillion bugs will fall out. Also, if no one is using
> those parts, why waste the effort? We can just say
> version X is the last version which supports platform
> Y. My feeling is that the best thing would probably
> be to remove it in new versions, in the interests of a
> clean, smooth system,
Such code is typically compiled away into nothing on
other platforms. Deleting it makes the source
code slightly smaller; the vast majority of such
conditionalizations are in macro files that should
not be touched except by people who know all about
all places those macros are used. (i.e. by no one).
> but as I said that's only IMHO
> and those who know better should be the ones listened
> to.
>
> > 2. About GUI support
> >
> > The current xmaxima talks over a pipe to the real
> > maxima. Doing the GUI directly from Lisp would be
> more
> > elegant; unfortunately, there is no such thing as a
> > standard GUI interface for Lisp. So I think that
> the pipe
> > idea is still the best idea:
> >
> > 1. The Lisp code remains portable
> > 2. Emacs people can still use it
> > 3. The GUI can be implemented in an arbitrary
> > programming language.
>
> I agree. I have a glade interface template at
> http://mathshield.sourceforge.net with a few of the
> basics, and there is a group in Italy working on a
> widget which may be of considerable help to us in the
> graphical display of equations but things like
> plotting would still have to be handled somehow.
>
> > Note that Mathematica also has the kernel in a
> > separate process, so this is apparently not an
> impediment
> > for popularity.
>
> From the user standpoint it doesn't matter - it's what
> they see that counts.
>
> > One problem is that one might want nicely typeset
> > output (i.e. two-dimensional formulas, and not in
> ASCII art
> > as the current maxima does, but with real intergral
> signs.)
>
> As I mentioned earlier, there is a project at
> http://cs.unibo.it/~lpadovan/mml-widget/ which might
> be able to help us in that department. It doesn't
> have editing capabilities yet, but I believe that
> support is planned.
>
> > This could be implemented by adding a new output
> > format to Maxima.
> > Using this output format, Maxima would
> > 1. output formulas in 1D, and
> > 2. add control sequences that indicate 2D layout and
> > special symbols such as integral signs and arrows.
>
> Actually, what I had hoped to do was use the mml
> widget above and teach maxima to output mathml - Dr.
> Barton Willis
> http://www.unk.edu/acad/math/people/willisb/ has
> already done some work along those lines and was kind
> enough to send me his code. He doesn't use the
> version intended for browsers and the like to display,
> but that shouldn't be too hard to add (famous last
> words)
I suspect that MathML rendering is a solution to a different
problem.
The real issue between front and back end is transmitted
messages like "stop what you are doing" and "are you still alive".
Anything else can be character strings, which is I think
what the front and back end of Mathematica talk to each
other.
MathML has very limited appeal to me. It is also about 100X more
verbose than necessary. (or as a friend of mine says,
"it compresses very well").
On the other hand, producing MathML would be easy. Just
take (for example) the MacTeX generator and modify the
format for output MathML instead of TeX.
>
> > Every front end could then typeset the output it
> > received from Maxima over the pipe in a manner
> suitable
> > for its intended audience. In this way, one could
> have
> > both an Emacs front-end and a C++ GUI front-end
> > talking to the same Maxima kernel.
>
> That's almost certainly the best way to handle it.
> That way, Richard can have an interface which works
> for him on the scripting/power usage, and we wimps can
> have our GUI. We may want to come up with our own
> communication syntax, or maybe use mathml/TeX/whatever
> (thanks to Richard maxima can already do TeX output).
> Or maybe even be flexible enough to let the front end
> specify ASCII, TeX, or MathML. That would probably be
> the most powerful setup. Heck, if mozilla really does
> include mathml support and abiword starts using it for
> their stuff, we might be able to do some really wild
> and crazy interfacing.
>
> > Just some ideas.
>
> We like ideas :-)
>
> > Greetings,
> >
> > Stephan
>
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima