Re: [Axiom-developer] Lisp

[root]

>Did you actually read this article? In fact the article contains the
>specific reason why you should *not* be converting BOOT code to Lisp:
>(my emphasis ** ** below):

Funny how we read the same article differently.

I have a large program for work (approx 50k lines of lisp) that 
contains 2 domain-specific languages within the program. One of
the languages, for example, lets me write conditional conncurrent
assigments in a language that is very close to the specification
that I'm given. It is close enough so the authors of the original
specification write the lisp code for their specs in a separate file.

Thus, the specification reads something like:

  a := f(x,y,x)

and my "domain specific language" that the specification author
writes is:

  (assign a (f x y x))

I COULD have written it as "strings" that read exactly like the
original syntax but I gained several advantages by using lisp-like
syntax. 

The first is that my "parser" for this "language" is (read). It took
me milliseconds to implement the parser and it is fully debugged.

The second is that the language is actually macros which expand into
XML for communication, assembler for testing, and conditional
concurrent assignments for use. So the same surface syntax is
trivially macro-expanded in context.

The third is that the domain-specific language can by extended
without modifying my program. Thus when the author wanted to do
an optimization for evaluating one of the arguments he only needed
to write, in his external spec file:

(defun optimizeExpression (e) ...)

(assign a `(f ,(optimizeExpression x) y z))

and it all "just worked". So the lisp-like syntax allows anyone
downstream of me to modify and extend the syntax and semantics
without change to my program.



If I wrote a "boot-like syntax" aka "strings" I'd have to write and
debug a parser. Then I'd have to be involved in discussions about
what "grammar" to accept, and I'd have teach the spec author about
making their grammer unambiguous. Debugging failing code would involve
figuring out what failed where, since the source is gone. And I would
not be able to run the source code interpreted so I could single-step it,
thus increasing debugging time. Nor could I trace the surface syntax
without knowing the kind of code generated and the mangled names.

So my 50k lines of lisp would be 100k lines, 50k of which is a
"strings" to lisp parser/translator. The end result would be more
complex, much harder to understand, much harder to debug, and much
less flexible and dynamic.

Tim