Re: Use of SGML for documentation (Re: potato -> woody upgrade not smooth...)
On Sun, Jul 08, 2001 at 03:56:29PM -0700, Ian Zimmerman wrote:
>
> 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.
Yes, but even a toy interpreter can have the macro facility.
>
> 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
Because you can't read it. One of the complaints LISP gets is that
"You can't see the language for the parenthesis" yet, this is what
they come up with instead?
> redundancy. It is what's missing in LISP as programming language.
I'll skip the Repetitive Strain Injury, thank you. LISP is plenty
verbose and the proper tabbing is what allows a human to read it easily.
<define name="factorial" args="x"><define name="iterator" args="product counter max">
<if><gt><counter/><max/></gt><product/><iterator><multiply><counter/><product/>
</multiply><add><counter/>1</add><max/></iterator></if></define><iterator>1 1 <x/>
</iterator></define>
I don't think it was the redundancy that made it readable at all... it
was the tabbing.
Not to mention that there's plenty of shortcuts to prevent having
to retype the tag all over again, such as <tag/> and </>, created
by people annoyed by the redundancy no doubt.
> Remember, McCarthy never expected humans to write in LISP - he wanted
> a sugared metalanguage, but it never materialized, in part, I think,
ML and Haskell did not materialize for many many years after. The reason
why the sugared metalanguage never materialized has several roots,
a minor reason being that there is no "lambda" key on keypads and the
major reason probably being that people liked s-expressions better.
And neither ML nor Haskell have macros (but they have lots of excuses).
> 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.
People are not abstract eval machines but they certainly can manipulate
parse trees. I think the fact that LISP has survived for 40 years,
though many languages have come and gone during that period, is testament
to that.
>
> 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.
>
We are getting a bit off the topic of SGML and document processing now,
however, I don't know how kindly the debian-sgml people will take to this.
> --
> 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
--
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Matthew Danish email: mdanish@andrew.cmu.edu ;;
;; OpenPGP public key available from: 'finger mrd@db.debian.org' ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Reply to: