Re: [Axiom-developer] Re: noweb

[C Y]

--- root <address@hidden> wrote:

> i'd much rather reduce the number of languages need to understand
> axiom rather than enlarge the number. some are necessary (like
> lisp, spad, aldor) but some are optional (e.g. java in the aldor
> merge) and more properly should be done using existing tools.

I agree.
 
> there are many feasible solutions to a problem. and there are
> many "convenient" solutions in many different languages. but 
> solutions which expand the needed skill set for maintainers are
> much less desireable than ones which do not.
> 
> as a policy i favor minimizing the number of languages used.
> adding sed (1 language), awk (a second), clever bash shell
> scripts (a third), java (a fourth), auto* (a fifth), simply
> reduces the number of people who can reliably maintain the system
> and increases the work required to port, possibly to the point
> of being impossible.

In particular, we will be hoping for not programmers in the normal
sense but mathematical researchers doing programming :-).

The one exception I might be willing to grant from that list is the
auto* system, because it encodes a lot of operating-environment
specific logic that "regular" languages don't, and that information is
something Axiom might need.  Axiom's lisp parts can be handled (and
should be handled, IMO) using ASDF.  However, outside of Lisp (like,
say, the case of wanting to select GCL or CMUCL to build with, or
building non-lisp libraries we can't rewrite into lisp like (as an
example) cernlib to be interfaced via FFI) autoconf and friends are
very nearly the universal solution.  I think a literate document
version of autoconf scripts will be both a viable solution and a good
one.

In the very, VERY long term I would like to see all significant
mathematical capabilities implemented as part of the Axiom system using
Lisp or Aldor, but the amount of work out there is HUGE, the work
required to code and document it up to Axiom's standards is even MORE
huge, and I expect we will never catch up with all the new work coming
out.

> 2) sed and awk are NOT standard parts of a windows distribution.
> again as a matter of policy we need to reduce the requirements
> so we can work across a larger number of systems. ideally all 
> of axiom would run in common lisp and porting becomes a copy
> operation. C is only slightly more problematic. in fact, the
> key reason that axiom does not currently run on the mac is breakage
> caused by C. awk/sed/autoconf all seriously complicate the port
> issue.

I agree with this.  Lisp is not perfect in this regard but it is
reasonably close and becoming more so with time.
 
> frankly i'd much rather see the tools devolve into lisp
> implementations. gcl, sbcl and clisp generate native exe files on
> windows and executables on linux. given that lisp is a full 
> programming language and is integral to axiom why don't we write
> code that is trivial to port rather than
> add requirements that are certain to make axiom unportable?

I agree in general with this.    
 
> as a policy i favor doing things in lisp unless it can be shown
> that such a solution is impossible. in the future i'd make the
> same claim about using aldor (assuming we free aldor).

I agree.  In fact, if CFFI becomes mature enough we might be able to
get away with using things like the QT graphics libraries while keeping
all of our code in Lisp.  What's your take on Lisp FFIs Tim?  Do they
constitute a non-lisp dependency?  I suppose in once sense they most
certainly do but at some level, the Windows GDI libraries if nothing
else, we will have to interface with non-lisp functionality.  If the
system changes under us we will have to follow it.  Even Garnet and
McCLIM rely on CLX and (in Garnet's case) GDI, and to integrate
smoothly with user environments higher level backends will be needed
(There is working going on on a McCLIM GTK backend now).  

> 3) in fact i'm making every attempt to explain the lisp programs
> as you'll see in the eventual bookvol5.pamphlet file. it is
> NOT necessary to explain the language idioms but it IS necessary
> to explain what is happening in a block of code.

Looking forward to that book!

> the noweb script will be sitting in a standalone pamphlet in
> src/scripts. it will not appear as an integral part of anything to
> a future maintainer.
> so the future maintainer can reasonably expect to have a (possibly 
> redundant) explanation of why this script exists, what it does, what
> data it expect to work on, etc. this is NOT the same as explaining
> the awk language constructs.

If we are going to need to redo noweb in Lisp in order to be able to
scale properly to large documents, maybe we can regard both the script
and noweb itself as a temporary solution? 
 
> i would argue that literate programming is a fundamental change in
> mindset that requires you to explain to some future maintainer how
> and why any new code works. he should be able to read the paragraph
> and know where this code fits as well as what it is trying to
> accomplish.

I'm trying to do that as much as I'm able in the Emacs interface.  By
the way Tim, is Elisp OK or does that count as another language?  For
something like this we have to work in the language of the program -
should we just accept that if someone wants to edit this code they
would be reasonably expected to be familiar with the workings of that
program, or at least enough so that they could figure out well
commented literate code?

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com