--- Camm Maguire <[EMAIL PROTECTED]> wrote:
> OK, these functions are in 2.6.8pre now. Please let me know if 2)
> presents any problem.
Wow! Thanks! I'll let you know how it goes - I made a mistake and
started building cvs HEAD (2.7.0pre) so it'll be a bit longer... is it
in the ANSI version of 2.6.8pre? (so I know which one to build...)
> source is not shareable (system memory)
Erm. I'm not sure I follow you - do you mean functionality defined in
a source file takes up space it would not need to once compiled and is
not accessible in that form by other routines?
> source pushes on the user all compilation problems and time
Heh - I guess as a Gentoo user I'm no longer even remotely bothered by
that, but it is a point. I view it as the continuing reaffirmation of
ability to bootstrap.
> source presumes more user expertise, particularly rare in lisp
Well, knowing how to compile and load it I guess is a point. I'll
admit my first run-ins with Lisp were a bit confused...
> source leaves more work for the user and less for the provider
True.
> source consumes more total system resources
Only until it's compiled ;-). And disk space is cheap.
> source is less well separated from user code
Um. Not sure what you mean here? You mean there is less temptation to
"look inside" the guts of a library and violate library boundaries if
the provided file is a binary?
> source is easier to provide, and tends to therefore be more
> changeable and less 'hardened'
But that's a key advantage! The trick is to make it so there is no
need or desire to change it, and I admit that's a doozie.
> These issues are reminiscent of gentoo vs. Debian, bash scripting
> vs. C code, and even axiom's decision to ship binaries and not just
> source.
I'm a Gentoo user and fan :-).
> > reason that it avoids any reliance on the behavior of the C
> > language or compilers, but that's just me.
>
> All that is taken care of once a binary is loaded, in principle at
> least. With source distributions, we depend on the behavior of lisp
> *and* C compilers on said code before it can be used (efficiently).
> And, sad as it may be, if rely we must, C is a much stabler target
> than any lisp, alas.
My understanding is that sbcl and cmucl use a working lisp binary to
bootstrap themselves - I know GCL uses other means. Of course SOME
binary is necessary, and at some point in the distant past someone must
have written the first compilers in machine and assembly code. There
are discussions from time to time on what could constitute a minimum
bootstrap compiler for Lisp, and I confess to being interested in that
question. Hopefully we will never again have to bootstrap from bare
metal, but if we do it would be nice to know how to do it.
> I think of this akin to the lifetime of my scripts, vs. the lifetime
> of my portfolio optimization code. Or Joe's sawfish code to change
> the color of icons consistently on kde and gnome, vs. the Linux
> kernel. In general the quicker and easier the solution, and the more
> possible implementors there are, the shorter the lifetime. It is a
> question of weight. No one will ever rewrite axiom in a similar
> time frame.
True, but no one SHOULD need to rewrite either one. Rewriting is, by
definition, a duplication of effort. The less rewriting, the more
original work and the faster we can attack new and interesting
problems. (Of course, that means any new and useful code has to attack
the HARD problems, but still...)
If Freespec had been able to get off the ground, I would have liked to
see it follow up on some of the directions the ANSI committee pointed
out but never implemented, that would have solved a lot of the problems
we see today. Unfortunately, some less direct means than building off
of dpANS3 must be found and that will take a LOT longer :-(.
> > This is the kind of development I would like to see Axiom pursue -
> > the solution of problems in such a fashion that there is no need
> > or incentive to solve them again.
>
> Could not agree more here. So we should not rewrite TeX in lisp, but
> rather find a way to use this excellent tool from within lisp.
That's a point, and I think LaTeX will be by far the last non-lisp
dependency to go, if it ever does. I would be very happy to see such
an interface - was there a project somewhere working to expose more of
TeX for non-traditional uses? While I am in awe of the algorithms and
how well they work, I have always been a little puzzled by the software
"stack" of TeX. As I understand it, TeX is written in Pascal which is
then translated to C which is compiled. So it relies on the language
behavior definitions of Pascal AND C, or more specifically that the
translation routines of the behavior specified in the Pascal language
of the original author are faithfully translated into C code that is
interpreted by a modern compiler in the same way the original author of
the translation routine assumed it would. I am not all that familiar
with C and Pascal so perhaps this is reasonable, but it always struck
me as a little... odd. I admit it has been effective. I guess the
copyright restriction of no copying at all of the core TeX file unless
it is kept identical helps provide stability, even if the open source
advocate in me gets the jitters seeing it...
Actually, as I understand it cl-typesetting has already implemented
large bits of TeX's algorithms in Lisp, although not yet the
mathematical routines (darn it...) Of course, it's almost completely
undocumented, which is frustrating and ironic as all get out
considering its conceptual ancestor and the fact it's a typesetting
system... but at least its license is now compatible :-).
Whether it is worth bringing cl-typesetting up to the level of a true
TeX replacement I don't know (although I am sure everyone else would
quickly answer no, with good reasons behind it) but TeX does its job
well enough (and that job is hard enough) that I am content to leave
pondering that task for another day - there are enough low hanging
fruit to pluck.
Cheers,
CY
____________________________________________________________________________________Got
a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
