Re: Use of SGML for documentation (Re: potato -> woody upgrade not smooth...)
Matthew> Those parsers are huge and complex. Anyone can embed a LISP (or Scheme)
Matthew> interpreter into their program. And judging by the sheer number of toy
Matthew> Scheme interpreters out there, it's pretty easy to write one.
There's a big difference between a toy interpreter and one that has
all the bells and whistles you mention (e.g. CLOS). The latter tend
to be, guess what, huge and complex.
Matthew> XML is "good" for many different kinds of programming languages for the
Matthew> same reason that Java is "good" for many different kinds of platforms;
Matthew> someone took the time and effort to write all the implementations for it.
Matthew> That doesn't mean that Java, or XML, is inherently "better" for this kind
Matthew> of application, it's just one way of doing it.
This is a good point, but even if document processing in LISP were as
well supported as it is in SGML, I'd choose SGML. See your example
below and my comment on it.
Matthew> <define name="factorial" args="x">
Matthew> <define name="iterator" args="product counter max">
Matthew> <if>
Matthew> <gt><counter/><max/></gt>
Matthew> <product/>
Matthew> <iterator>
Matthew> <multiply><counter/><product/></multiply>
Matthew> <add><counter/>1</add>
Matthew> <max/>
Matthew> </iterator>
Matthew> </if>
Matthew> </define>
Matthew> <iterator>1 1 <x/></iterator>
Matthew> </define>
Matthew> That is truely disgusting, especially when you can write this:
Matthew> (defun factorial (x)
Matthew> (labels ((iterator (product counter max)
Matthew> (if (> counter max)
Matthew> product
Matthew> (iterator (* counter product)
Matthew> (+ counter 1)
Matthew> max))))
Matthew> (iterator 1 1 x)))
Why is it disgusting? I actually _prefer_ the SGML syntax with its
redundancy. It is what's missing in LISP as programming language.
Remember, McCarthy never expected humans to write in LISP - he wanted
a sugared metalanguage, but it never materialized, in part, I think,
because other languages like ML and Haskell stepped in. Humans are
not abstract eval machines, and even code (not to speak of
documentation!) is written primarily for humans.
Matthew> This is why a lot of LISP programmers don't take XML
Matthew> seriously. It lacks macros, and it lacks an object system
Entities fill most of the need for these. It is true that,
unfortunately, entity support in most of the new crop of XML tools is
poor, but that is a pratical problem.
--
Ian Zimmerman, Oakland, California, U.S.A.
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.
GPG pub key: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
Reply to: