Re: [Axiom-developer] Re: A modest proposal

[Stephen Wilson]

Hello Bill,

"Bill Page" <address@hidden> writes:
> > ...
> > C Y writes:
> > > If I understand correctly from previous posts, in this context "ghetto"
> > > is being used to describe a large body of tools that are divorced from
> > > mainstream directions being taken by the open source community.
> > > Centering on Lisp already triggers some of those complaints, and Bill's
> > > concern (if I understand correctly) is that if we home-grow too much we
> > > will end up not being able to grow with the open source world and be
> > > left behind with a bunch of non-standard tools no one wants to take the
> > > time to understand.
> >
> 
> Thanks for carrying my side of the conversation for me, Cliff. :-)
> I've had my mind on other things for the last few hours... Yes, you
> state very clearly and exactly my concerns.

Im glad Cliff reflected your thoughts accurately as well.

> On 29 Jun 2007 20:13:40 -0400, Stephen Wilson wrote:
> 
> > Ok.  I recall similar notions.  New tools that solve new problems are
> > always non-standard by definition.  I just never connected `ghetto'
> > with that perspective.
> >
> 
> What "new problems" are you referring to here? I do not see any new
> problems in this part of the Axiom project. The methodologies that we
> are talking about here have been around nearly as long as Axiom
> itself.

In some ways this is true.  But take your own concern about a
complicated build environment as an example.  There is no reason for
it.

I am skipping the next segment of your post because I do not feel
there is a need to promote or justify Lisp.  I really would like to
avoid a language war.

[...]
> What does ASDF do that 'make' and other parts of the existing build
> system does not already do?

There are several things.

Make has a specific attitude, if you can call it that, about what it
takes to build a system.  It is very much rooted in the requirements
of C and similarly compiled software.  In short, it invokes a compiler
repeatedly over a list of files, topologically sorted w.r.t a DAG of
dependencies, and finally links an executable.

Lisp is different. You still need to consider dependencies, but you do
not need the iterative process and the final `link' stage to get a
working system.  Everything can be done dynamically while the system
is running.  For example, I use ASDF in the Axisp repo for all new
lisp code.  I can edit a pice of code in one emacs buffer, and have a
running Axiom system in another.  When I have made a change, I do the
equivalent of:

      (1) -> )lisp (asdf:oos 'asdf:load-op :axisp)

In reality, I have this command associated with a key binding, to save
typing.  The end result is an Axiom, with all dependencies tracked and
loaded afresh, without having to restart the system.

Think about the consequences.  Already, there exists the basic
machinery to drag-and-drop a pamphlet file into a running system and
have it instantly available.  The connotations are far from being
limited to a simple convenience feature useful only to developers.


Another example, if you would bare with me.  The iterative process of
compilation does not jive well with a Lisp based system.  Consider the
algebra build, where we repeatedly invoke the Lisp system to compile
each and every file independently.  This is necessary for C, but not
for Lisp.  We could trivially define the dependencies in ASDF, and
build the algebra in one shot.  This is a simple minded application
which would reduce the build time, for fun, by 15 minutes+. You save,
at a minimum, the repeated autoloading of the code which implements
Axioms compiler.  Of course you could build a custom image which has
everything preloaded and save some time, but to me that is a gross
hack, and you loose the benefits which I alluded to above.
Furthermore, if you were to choose to do something similar from within
make you would be reimplementing a poor-mans ASDF, so why bother?
There are too many advantages to using ASDF directly.

I gave the above examples first as I feel they are the most `user
visible'.  Certainly others can extend on the theme. 

However, for the sake of completeness, one needs to consider the
design of ASDF itself -- what it means for developers.  This is Lisp
specific, so I wont go into deep details.  But understand that it is
defined via CLOS, the Common Lisp Object System.  The interface is
designed such that all entities over which the system operates are
objects (classes), and all functionality is exported as a method.
This is totally foreign to make and friends.

The system is intrinsically extensible, via subclassing and
specialization.  Thus, If you wanted to dynamically tangle and weave a
pamphlet file, you can do that with a minimum of effort.  No need to
grok make, shell scripts, sed regular expressions, M4 macros, etc,
etc.  You, among all people, should appreciate the benefits.  It is a
mostly environment neutral way of specifying such a process.  It is,
for any relative purpose, an instantly portable solution to an
exceedingly wide variety of problems.

> > >  And the goal is to develop tools such that given a working Lisp
> > > environment users and developers will be able to focus on the Algebra
> > > without worrying about the underlying tools.  If they MUST work with
> > > them, I would like them to be literate all the way down - no dark corners
> > > to get into trouble with.  But that's again just me.
> 
> That part I completely agree with but I fail to see why that requires
> doing the things that you and Stephen are proposing.

Its not a requirement.  There is nothing fundamental holding back
other approaches.  But I truly do feel that this is a reasonable and
pragmatic approach, even given the pie in the sky ideal we would all
like to see realized.

> > Your certainly not alone :)
> >
> 
> That's what I like about the web! ;-)

Indeed!


Take care,
Steve