M. Edward (Ed) Borasky wrote:
So:
a. Is it to be Common Lisp rather than Scheme? Should it work (and be
tested) with all three major open-source platforms (clisp, sbcl and
gcl)?
Common lisp. For the simple reason that a slow transition from a working
version to a working
version on a daily basis does not lend itself to a complete language
transition. The rewrite will
move to ANSI lisp as a simple side-effect of newly written code so it
should not matter what
Common lisp you use to host it.
b. The kind of test / behavior driven development such a massive
refactoring requires is "usually" done in Ruby these days. Are there
Lisp-based tools for this so the project could "eat its own dog food",
or would there need to be some "scaffolding" built in a "scripting
language" like Ruby or Python?
I am building unit-tests for the internal routines as I rewrite them so
that I can verify that the
rewrite is reasonably correct. The idea of refactoring code is much
older than Ruby. See the
"On Lisp" book.
Axiom already has a complete test system built into the build. I rebuild the
system from scratch several times a day, usually after every few
routines are merged.
I have spent a little time on the idea of "fuzz testing" Axiom but the
pseudo-random
generator is a challenge. On possible approach I'm studying is to use a
hidden markov model
against the Axiom test files to generate "random-but-nearly-valid"
inputs. Especially challenging
are random inputs that pass the parser and are mathematically "near
valid". I think there is a
PhD thesis topic sneaking around in this problem.
c. Aren't there more "Lisp-like" theories of mathematics and
implementations of them? I'm thinking of Automath, but I suspect there
are others. And there are certainly Prolog-like systems, proof
engines, etc. The current crop of "functional" languages (Haskell,
Erlang, OCaml, etc.) does seem like a better platform for this sort of
thing than Common Lisp. Scheme would make sense if we wanted to push
this into undergrad / high school curricula, though. Summer of Code??
ACL2 is written in lisp and there has been a project goal of embedding
ACL2 inside the
Axiom machinery. There has been some discussion of this topic on this
mailing list. ACL2
calls could be made on function definitions using an inherited set of
mathematical decorations.
Thus, the Group axioms could be added to the Group category and
functions implementing
operations on the elements could be shown to obey the Group laws (half a
dozen PhD
thesis topics a year hidden here)
Why would Haskell be a better platform? Because Haskell is functional?
Again, see the book
"On Lisp" where the functional programming style is stressed. It was
written in 1993.
A Scheme implementation would end up creating Common lisp on Scheme
which would
be time consuming.
d. Hardware? This stuff needs lots of cores and RAM - maybe another
reason to use a more modern language like Erlang with explicit and
"provably correct" concurrency primitives.
There was a recent conference on parallel lisp systems (in Japan I
think). There is no reason
why an independent lisp system could not run each core. That is
essentially the same technique
as the Java-per-core implementations. A large portion of the lisp system
can live in shared,
read-only memory as it works off separate heaps/stacks.
The "new idea" in Go about passing channels on channels is basically
just passing closures,
a very old lisp trick. Using a message passing paradigm (where objects
can be shared or
serialized through the message) is easy to do between lisps. Go
"parallelism" appears to be
implemented by lightweight programs added to a queue which managed
dispatch. Go is not
really running on all of the processors but the lightweight threads are.
Speaking of all of this, have you all seen Jeff Bone's "rant":
Programming languages, operating systems, despair and anger http://bit.ly/1xtACU
Yes, I saw Jeff's rant and, as an Elder of the Internet, and a very
long-time programmer (nearly 39 years)
I have to agree with him. I have a hard time finding a new technique
that wasn't done in lisp years ago.
Python claims to be lisp-like but they have no clue about macros,
program-data equivalence, the
cons-nil-()-false equivalence, dynamic environments, real closures, and
a host of other useful things.
Even their python command-line interpreter doesn't seem to allow
techniques that have been
available in the lisp break loop. Try modifying a python function on the
fly and continuing from
the breakpoint. And forget about creating your own syntactic elements.
Haskell has "lazy evaluation" (see the function "Delay" in the Axiom
sources), monads (stateful
pseudo-functional programs) which are trivial to write, pattern matching
of arguments (see the
partial function definition sequence in Axiom or any prolog-in-lisp).
Go has interfaces without inheritance, a very old idea in Common lisp. I
can't wait until they
introduce wrappers and whoppers.
Lisp can modify the compiler internals at compile time by supplying code
to manipulate the
compiler internal data structures (lisp is a self-syntax tree and macros
are source-to-source transforms
done at compile time). Lisp programs usually write lisp programs on the
fly since programs and data
are the same. Try that in Ruby. Or construct programs that learn by
self-modification, growing organically
to adapt to the input stream by permanent change. Without writing a
whole parser/compiler chain I
have no idea how to write self-modifying Python programs.
Languages limit what you can think. Ask any Java programmer about their
program and you are likely
to hear "design patterns". Ask any lisp programmer about design patterns
and be prepared for a laugh.
In any case, Axiom is firmly in the Common lisp camp for the forseeable
future.
Perhaps computational mathematics should be designing their own
operating system and programming language for computational
mathematics, using something like the LLVM (low-level virtual machine)
or DROPS (Dresden Real-time OPerating System) kernel. Or the
Intellasys Forth-based SEAforth array processor? http://bit.ly/2t4e3C
I looked at the Clojure language running on the Java virtual machine and
at the Azul system which
is designed to host hundreds of Java VMs in parallel. But the question
is, if you're going to use Java
VMs why not use Lisp VMs? Lisp compiles to machine code, so why not not
host hundreds of Lisps?
With a proper implementation you only need separate stacks (or a
spaghetti stack) and separate
heaps or "clades within a common heap". A Clade-heap modification would
allow object sharing
or object transport between processes. Immutable data structures is a
very interesting idea here.
As for the Axiom internals rewrite/refactor, the intention is to define
"semantic layers" that make it
perfectly clear where certain functionality should be supported. Algebra
concepts should be fairly
near the top of the tower with a gradual transition to raw lisp. I would
ideally like to be able to
write each "layer" in only a few pages of code expressed in the concepts
of the previous layer.
If that can be done than it would be possible to teach Axiom by starting
at a few-page pile of code
and working your way upward or downward as appropriate. A perfect
example of this is the
standard definition of lisp in lisp code. Such elegance and brevity is
the soul of the design.
Imagine understanding all of the algebra support code in two pages.
Tim
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer