Introduction and misc ideas

[Brian T Rice]

Hi Alexis

On Mon, 24 Jun 2002, Alexis Read wrote:
AR>On Mon, 17 Jun 2002, Brian T Rice wrote:
AR>> AR>In the case of LISP, and Maude, I don't see which has the more
AR>> AR>advantageous syntax.
AR>>
AR>> It's simple: I don't want there to be a syntax or a language, and
AR>> machine-manipulable syntax is the key to that. Maude is also notably
AR>> missing a backquote and unquote operations, which makes the meta-level
AR>> rough to deal with, and SEXP syntax is the only one I know that handles
AR>> that generically.
AR>
AR>If I've got this correct, QUASIQUOTE and UNQUOTE are syntactic
AR>meta-operators to build partial expressions, remarkably similar to Maude's
AR>UP and DOWN operators ;o).
AR>KWOTE (the opposite of EVAL, the process of finding the end value of an
AR>expression) is formed as META-REDUCE, with REDUCE == EVAL.
AR>' is just the same as in LISP (ie. QUOTE), it refers to the meta-data of
AR>an object.

Yes, all the operations are available, so Maude's source itself would be
enough to work from. Even without the source, I could provide a layer over
it. Either way, I am not satisfied with the syntax, or having a syntax at
all. The other night, I spoke with a Tunes member on IRC about providing
an architecture and communications bootstrap protocol (text over tcp/ip or
pipes as examples) for maude's semantics or some suitable modification for
Tunes. One reason for favoring a SEXP-style syntax, regardless of the
extras like quasiquote or backquote abbreviations, or even of macros, is
that expressions can be passed back and forth more interactively and with
a much simpler parsing scheme. This has nothing to do with the structure
of Lisp itself or even how the most common SEXP languages work. For
example, there's Symmetric Lisp which I've mentioned before here; but the
only extant references are on CiteSeer (http://citerseer.nj.nec.com/).
SEXP is also extensible by the use of the reader-evaluator distinction:
redefining characters to act locally as literal-abbreviations that program
the listener to build up the total expression.

I suppose I should mention that SEXP's are more closely mappable to
arrows. :)

All of this is something I'm going to put together a packaged
specification for, since I have the time and I've been delaying it for
too long. Expect a mail shortly describing my work on it.

AR>It seems to me that quasiquote and unquote superseed quote in a
AR>partially-evaluated environment ie. eval and kwote are 'eager', and
AR>quasiquote and unquote are lazy, with quote having no use.

Eager and lazy are close. In Lisp, it's described that macros are forms
that don't evaluate their arguments, but functions do. This is only a
rough approximation of what's needed though, as you point out.

AR>So all 3 language types (LISP, Maude, Joy) seem to have a machine
AR>manipulable syntax, I believe all 3 can do rewriting, and adding partial
AR>evaluation, and a module system should be easy in either of them.

Yes, and they all have their drawbacks. But I would not say that any of
them have syntaxes that are manipulable in a safe way without a lot of
redundant work on the part of the program-generator or analyzer or partial
evaluator. Perhaps Maude is the closest. Speaking of which, Maude of
course does have this module system which beats anything seen in all of
Lisp's history, and it's an open question whether modules in Joy would
work out; it has a lot of growing to do.

AR>On the subject of module systems, macros seem to make little sense in a
AR>partially evaluated system - everything should be defined for runtime
AR>execution with a set of 'caching' or state attributes (for late binding).

That's interesting, but it's not something I've given enough thought.
Maybe Fare has something to add about that.

AR>Alexis

Thanks, I'll get working on the SEXP formulation of Maude, and send it out
in a bit.
~