Subject: Re: The Next Generation of Lisp Programmers
From: Erik Naggum <erik@naggum.no>
Date: 25 Aug 2002 16:34:42 +0000
Newsgroups: comp.lang.lisp
Message-ID: <3239282082503601@naggum.no>

* Paolo Amoroso
| Could you elaborate on the 2.5% of SGML that is not braindamaged?  What
| ideas are worth saving?  Do such ideas also live somewhere else (e.g., in
| XML)?

  To start from the end, the ideas survived unchanged in XML, neither improved
  nor weakened.  The first core idea is hierarchical structuring of information.
  Lisp has had this forever.  The second is textual representation.  Lisp has
  had this forever.  The third is validatability of the structure.  Lisp has no
  notion of this separate from the semantics of special operators or the usual
  evaluation rules.  The fourth is an entity structure that allow documents to
  share components.  Lisp does this by loading things into the image and the
  `require´/`provide´ pair of deprecated operators.  From there on it is all
  downhill for the SGML family.

  The really grave mistakes include the element-attribute dichotomy, the new
  syntax for every meta-level, such as the attribute-value syntax, the qouting
  conventions, character entities and references, document type definitions,
  and ultimately the sgml declaration, the primitive language for content
  models, the changing syntax according as features are supported or not, the
  redundant end-tag, and failure to use a simple escaping mechanism for
  characters that could be confused as markup with the character references as
  data adding additional complexity.  The sheer complexity of parsing SGML and
  XML and presenting it to the caller lies mainly in the syntactic mess and
  the utter lack of an intelligent model for in-memory representation.  (DOM
  is completely braindamaged with no redeeming qualities.)

  Furthermore, the more you think about things in SGML terms, the more you
  realize that fully explicit hierarchical structure is not /enough/.  You need
  macros that take parameters and that expand into commonly used forms and you
  need a content model language that is amenable to changes and support layered
  transition from one version to another.  The straitjacket that SGML presents
  to your information structuring is actually a serious limitation and not at
  all the freedom from implementation-dependence that it set out to be.

  In brief, you are better off just grasping that you need a uniform syntax, a
  hierarchical structure, and a macro mechanism that produces a different
  structure in memory when processing it -- and the implement this in Common
  Lisp, instead.  Simplicity and elegance are found in getting rid of the junk
  and moving the complexity to the processor instead of the source language.
  What SGML has that is not braindamaged and that was not taken from other
  languages before it is basically limited to the validatability and the entity
  structure.  The latter is underrated and large misunderstood and misused, so
  it takes some effort to understand how to use it properly, but it should grow
  to become a fully-fledged macro system before it becomes fully useful.

-- 
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.