Lisp Syntax for external representation [Was: URC usage scenarios ]

Daniel W. Connolly (connolly@hal.com)
Thu, 29 Sep 1994 12:31:43 -0500

Message-Id: <9409292012.AA05994@ulua.hal.com>
To: rdaniel@acl.lanl.gov
Subject: Lisp Syntax for external representation [Was: URC usage scenarios ]
In-Reply-To: Your message of "Thu, 29 Sep 1994 10:54:30 MDT."
<199409291654.KAA00857@idaknow.acl.lanl.gov>
Date: Thu, 29 Sep 1994 12:31:43 -0500
From: "Daniel W. Connolly" <connolly@hal.com>

In message <199409291654.KAA00857@idaknow.acl.lanl.gov>, rdaniel@acl.lanl.gov w
rites:
>Perhaps the syntax of the URC should be changed to be of the form:
>
> URC.version {
> elements
> }
> signatures
>
>I will have a better handle on that as I implement the parser for the
>URC structure.

I have held my tongue until now, but I just can't bear this any more.

For crying out loud, can we just use Lisp S-Expression syntax for the
external representation of these things and be done with it?

Why must we invent a new syntax? Why waste time designing,
implementing, and debugging new technology that is irrelevant to the
task at hand?

How do we know it will be expressive enough in the long run?

There are two types of arguments that I find convincing:
(1) formal arguments. If someone can produce a formal argument
that shows that every notion we will want to put in a URC
is expressible in some syntax, I would love to see it.

(2) emperical arguments. For this you need LOTS of data to
be convincing. Lisp S-expressions have been around since
the '50s, and I have never seen any complaints that they
are not sufficiently expressive. To me, this constitutes
a convincing emperical argument.

There have been complaints that S-expressions are inscrutable or
inconvenient, but I hardly think that readability is our #1 concern.

For a practical application of S-expressions, look at the WAIS stuff.
They use ASN-1 to specify the type of the data. They use an optimized
over-the-wire representation. And for a portable, external
representation, they use lisp s-expressions. We could even use the
code they wrote.

That's the handy thing about S-expressions. Not only are they printable
and portable, but the abstract object that they represent is widely
understood. It's clear to many folks that:

(a b c)
and
(a b c)

represent the same object. There are "canonical forms" for s-expressions.
You know you can build a data structure for random-access to an s-expression.

All these mechanisms would have to be re-invented for any new syntax.

If somebody has a different syntax with years of experience behind it,
let's see it. I'm willing to hear arguments that Tcl or SGML -- ugly
as they are -- is the right thing, since they're widely deployed and
understood. But by the "everything should be as simple as it can be
and no simpler," you'll have a hard time coming up with something better
than S-expressions.

But for pete's sake, let's not make something up just to be different.

Dan