[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML as a transition to s-expr



Quoth Guy Steele - Sun Microsystems Labs on Tuesday, 18 December:
:
:    (defun tag1 (&key attr1 &rest body) ... )
:    No ambiguity.
: 
: Hm.  What dialect of Lisp is that from?

Intuitive Lisp (tm).  It's just an ad hoc notation to explain why I
think it's not ambiguous.  My bad, for using something that smelled so
strongly of CL that it elicited an exception from a CL parser.

I do think there is some interest and value in this discussion,
because we're getting at what differentiates human parsing of a
programming language from human parsing of a markup language.

I don't mind writing

person 
  "mixed content prefix"
  name :context "informal"
    bob
  "mixed content infix"
  height :units "cm"
    188
  "mixed content postfix"

but I don't want to write

cond
  n < 1
    1
  t
    *
      n
      fact
        -
          n
          1

which looks like someone was playing with the platen while I was
typing.

Even Scheme and Forth and APL, which are about as syntax-light as you
can get, do *have* syntax, and the reason is that people have
expectations about the notation for certain mathematical and (in more
recent years) imperative/applicative meanings.  We can express things
concisely because we have shared languages, more pervasive and
well-worn than any natural language, and any novel notation that
disregards those conventions is wasteful.  Scheme and Forth and APL
abuse these for complex reasons which can be appealing at times, but
the abuse remains an adequate explanation for their failure to take on
the role of mainstream expressive notation.

I think programming languages need syntax for success, because they
have to provide an appropriate visual density of concept on the page
or screen.  Mark-ups don't need that most of the time: The content
provides the conceptual density.  Mark-ups only need syntax when they
introspect.

General-purpose mark-ups can't assume notational conventions and
customs which simply don't exist.  All the syntax has to be pulled
back into the meta-language's navel-gazing process, because the meat
and potatoes of content could turn out to be beans and rice, and my
terrorist-parser doesn't grok your freedom-fighter.  The more work
that goes into the mark-up, the more meta-language syntax is ramified,
but the content remains unchanged, like comment blocks in program
code.

I think that the problem with s-exprs for mark-ups is that they
don't let you put enough syntax into the metalanguage.  You have to
add something to provide for an escape clause, so that the mark-up
can introspect, reflect, and reify it's own concepts.  Whatever you
add will be outside the tradition of s-expr usage.  It may be more
difficult to forge a new trail alongside an old established (and
sometimes befouled) one, than to break entirely new ground.