From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed1.bredband.com!bredband!uio.no!nntp.uio.no!ifi.uio.no!not-for-mail From: Erik Naggum Newsgroups: comp.lang.lisp Subject: Re: The Next Generation of Lisp Programmers Date: 25 Aug 2002 16:34:42 +0000 Organization: Naggum Software, Oslo, Norway Lines: 51 Message-ID: <3239282082503601@naggum.no> References: <3239150725773370@naggum.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: maud.ifi.uio.no 1030293283 24799 129.240.64.16 (25 Aug 2002 16:34:43 GMT) X-Complaints-To: abuse@ifi.uio.no NNTP-Posting-Date: 25 Aug 2002 16:34:43 GMT Mail-Copies-To: never User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.lisp:38728 * 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.