Loading ...
Sorry, an error occurred while loading the content.

Why XML caught on where LISP and Scheme failed to?

Expand Messages
  • Omer Zak
    As I read Extensible Programming for the 21st Century (URL:http://pyre.third-bit.com/~gvwilson/xmlprog.html), I pondered the secret of success of XML. In a
    Message 1 of 4 , May 27 11:42 PM
    • 0 Attachment
      As I read "Extensible Programming for the 21st Century"
      (URL:http://pyre.third-bit.com/~gvwilson/xmlprog.html), I pondered the
      secret of success of XML. In a way, I am already using XML software
      (glade, the GUI editing tool, saves the edited GUI description in a XML
      file, which can later be read by a Python library and used to construct
      the GUI for a script).

      After all, it can be considered to be just another syntactic
      representation of LISP or Scheme. For example, the transformation between

      (+ 1 2)

      and

      <paren>
      <token name="+"/>
      <token name="1"/>
      <token name="2"/>
      </paren>

      is trivial.

      My guess is that XML succeeds because it allows the developer to add
      types to S expressions and to constrain them and their contents. This is
      like imposing hard-typedness on variables and/or their values in a
      conventional programming language. It works because the developer can
      give different names to his expressions besides the equivalent of naming
      every tag <paren>.

      As a proof of concept, it may be a good idea to develop a XML
      representation of a Python script, along with code for transforming a
      Python script to its XML representation and vice versa.
      --- Omer
      My own blog is at http://www.livejournal.com/users/tddpirate/

      My opinions, as expressed in this E-mail message, are mine alone.
      They do not represent the official policy of any organization with which
      I may be affiliated in any way.
      WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
    • Shlomi Fish
      ... What makes you think it isn t: Or:
      Message 2 of 4 , May 29 9:05 PM
      • 0 Attachment
        On Friday 28 May 2004 09:42, Omer Zak wrote:
        > As I read "Extensible Programming for the 21st Century"
        > (URL:http://pyre.third-bit.com/~gvwilson/xmlprog.html), I pondered the
        > secret of success of XML. In a way, I am already using XML software
        > (glade, the GUI editing tool, saves the edited GUI description in a XML
        > file, which can later be read by a Python library and used to construct
        > the GUI for a script).
        >
        > After all, it can be considered to be just another syntactic
        > representation of LISP or Scheme. For example, the transformation between
        >
        > (+ 1 2)
        >
        > and
        >
        > <paren>
        > <token name="+"/>
        > <token name="1"/>
        > <token name="2"/>
        > </paren>
        >
        > is trivial.
        >

        What makes you think it isn't:

        <paren>
        <op name="+" />
        <token name="1" />
        <token name="2" />
        </paren>

        Or:

        <paren op="+">
        <token name="1" />
        <token name="2" />
        </paren>

        Both of these forms suffer from the fact that if one of the operands (or the
        operations) is an expression, then it would be difficulty to encode it that
        way. A better way would be:

        <paren>
        <op>+</op>
        <token>1</token>
        <token>2</token>
        </paren>

        That way the Scheme expression ((if cond + -) (+ 5 6) 7) would be encoded as:

        <paren>
        <op>
        <paren>
        <op>if</op>
        <token>cond</token>
        <token>+</token>
        <token>-</token>
        </paren>
        </op>
        <token>
        <paren>
        <op>+</op>
        <token>5</token>
        <token>6</token>
        </paren>
        </token>
        <token>7</token>
        </paren>

        Furthermore, we may as well use the tag <expr> or <expression> instead of
        <paren> and the tag <element> instead of <token>. Another thing that exists
        in XML that is missing from S-expressions is the in-text markup. Like:

        <p>The quick brown fox jumps over the <b>incredibly</b> lazy dog.</p>
        ^^^ ^^^^

        Generally XML (and its philosophical father- SGML) is a superset of the markup
        functionality given by S-expressions. For every S-expression, there are many
        ways (possibly infinite) to encode as XML, while XML conversion to
        S-expressions is not always possible in a straightforward manner, may be
        lossy, or otherwise will simply be a verbose pseudo-XML encoding into
        S-expressions.

        Then there's YAML (YAML A'int a Markup Language) of course, which is basically
        just nested arrays and associative arrays and their values. This is somewhere
        between S-expressions (which are just nested lists) and XML. XML-RPC is a way
        to encode YAML-like structures into XML, which makes one not understand why
        XML is necessary in this case.

        Regards,

        Shlomi Fish


        > My guess is that XML succeeds because it allows the developer to add
        > types to S expressions and to constrain them and their contents. This is
        > like imposing hard-typedness on variables and/or their values in a
        > conventional programming language. It works because the developer can
        > give different names to his expressions besides the equivalent of naming
        > every tag <paren>.
        >
        > As a proof of concept, it may be a good idea to develop a XML
        > representation of a Python script, along with code for transforming a
        > Python script to its XML representation and vice versa.
        > --- Omer

        --

        ---------------------------------------------------------------------
        Shlomi Fish shlomif@...
        Homepage: http://shlomif.il.eu.org/

        Quidquid latine dictum sit, altum viditur.
        [Whatever is said in Latin sounds profound.]
      • Nadav Har'El
        ... I think you re misunderstanding XML. XML is was not supposed to be a programming language, but rather a data representation (markup) language. Lisp and XML
        Message 3 of 4 , May 30 12:55 AM
        • 0 Attachment
          On Fri, May 28, 2004, Omer Zak wrote about "[hackers-il] Why XML caught on where LISP and Scheme failed to?":
          > As I read "Extensible Programming for the 21st Century"
          > (URL:http://pyre.third-bit.com/~gvwilson/xmlprog.html), I pondered the
          > secret of success of XML. In a way, I am already using XML software
          > (glade, the GUI editing tool, saves the edited GUI description in a XML
          > file, which can later be read by a Python library and used to construct
          > the GUI for a script).
          >
          > After all, it can be considered to be just another syntactic
          > representation of LISP or Scheme. For example, the transformation between
          >
          > (+ 1 2)
          >
          > and
          >
          > <paren>
          > <token name="+"/>
          > <token name="1"/>
          > <token name="2"/>
          > </paren>
          >
          > is trivial.

          I think you're misunderstanding XML. XML is was not supposed to be a
          programming language, but rather a data representation (markup) language.
          Lisp and XML are only related by the fact that both use "0" and "1" bits ;)

          I remember that 6-7 years ago or so, at work, I had to invent a file format
          for saving large sets of result coming from a certain program. The format had
          to be relatively simple to read or write and machine-independant (so ASCII
          was a benefit) and extentible (i.e., the reading program could look at
          certain sections written by a newer writer, and know that it doesn't recognize
          these sections and simply skip them, with no error). XML was exactly right
          for this job, but at that time XML was not very popular, so I chose not to
          use it and invented my own format that basically looked like a (possibly
          recursive)
          <section_name> <type> <length>
          ....

          Which corresponds to the XML
          <type section_name>
          ...
          </type>

          Nowadays, unfortunately, XML is so hyped that I hear of people using XML
          for things that even a simple tab-separated format would do.

          In any case, as these data formats do not contain any executable instructions,
          loops, and so on, using lisp would not make much sense. Surely, for hand-
          edited input files the power of a programming language (having things like
          conditionals and loops) can come in handy, but these aren't essential for
          machine-generated data files, which are what most XML files are nowadays.

          You might want to compare Postscript and PDF - the former was a full
          programming language used as a printed page input format, and it was later
          replaced by a more simplistic, not-a-language, format.

          --
          Nadav Har'El | Sunday, May 30 2004, 10 Sivan 5764
          nyh@... |-----------------------------------------
          Phone +972-523-790466, ICQ 13349191 |A messy desk is a sign of a messy mind.
          http://nadav.harel.org.il |An empty desk is a sign of an empty mind.
        • Oleg Goldshmidt
          ... Obligatory disclaimer: I know Lisp pretty well, but my understanding of XML is rudimentary. You ve been warned. Well, from the Lisp (shall I say, abstract
          Message 4 of 4 , May 30 7:54 AM
          • 0 Attachment
            "Nadav Har'El" <nyh@...> writes:

            > On Fri, May 28, 2004, Omer Zak wrote about "[hackers-il] Why XML
            > caught on where LISP and Scheme failed to?":

            > > As I read "Extensible Programming for the 21st Century"
            > > (URL:http://pyre.third-bit.com/~gvwilson/xmlprog.html), I pondered the
            > > secret of success of XML.
            >
            > I think you're misunderstanding XML. XML is was not supposed to be a
            > programming language, but rather a data representation (markup) language.
            > Lisp and XML are only related by the fact that both use "0" and "1" bits ;)

            Obligatory disclaimer: I know Lisp pretty well, but my understanding
            of XML is rudimentary. You've been warned.

            Well, from the Lisp (shall I say, abstract CS?) point of view there is
            no difference between program and data. If you have a lisp-like
            interpreter for Omer's (or similar) XML representation you can write
            code. For all intents and purposes it will be Lisp. I don't think that
            anyone here will argue that the actual tokens matter[1].

            On the other hand, representing structured data in Lisp is also
            possible and frequently done. I did it myself a few times, including
            writing custom tools to "lispify" and "delispify" independently
            formatted data.

            I seriously doubt though that there is a "secret" to XML's success on
            the technical level. It's not the first or the last markup
            language. It's not the first or the last extensible language. I would
            guess ("assert without proof," borrowing an expression from Wilson)
            that big business support[2] + some familiarity of syntax to those who
            had been using HTML "forever" (on the Internet timescale) were the key
            factors. I also suspect that XML is successful as a structured data
            representation, with custom tools written in every programming
            language known to mankind, including, significantly, Lisp. Since
            anybody can write their own tools one can live with structured data
            representation and a small (a.k.a. limited) tool, and without a
            full-blown Lisp interpreter (but maybe a JVM :).

            Of course, there is Greenspun's 10th Rule of Programming:

            "Any sufficiently complicated <insert your favourite language here -
            OG[3]> program contains an ad hoc informally-specified bug-ridden slow
            implementation of half of Common Lisp."

            All the rest is likely to be religious wars. ;-)

            [1] One can argue that XML tags afford you some additional capabilities
            w.r.t. error checking, since the closing tag echoes the type of the
            opening one. Any decent editor will match parentheses in Lisp code
            though, making such checking very easy.

            [2] IMH(umble)O the same is true, to a significant extent, for Java.

            [3] The original said, "C or Fortran" - OG ;-).

            --
            Oleg Goldshmidt | pub@...
          Your message has been successfully submitted and would be delivered to recipients shortly.