Re: About o:XML

On Mon, Apr 18, 2005 at 06:25:05PM -0700, Brian Chrisman wrote:
> On Mon, Apr 18, 2005 at 03:58:56PM -0000, Ashwin Jayaprakash wrote:
> > [..]
> > I still don't know why one would want to write a program in XML and not in simple English-like languages like Java/C.

I wouldn't exactly say English-like for those languages, as they can be quite
cryptic at times. But I have the same opinion about writing programs directly
in XML. So far I haven't met any compelling reasons to do so.

> I'm not a developer on this project.

Neither am I. I am a developer of the SrcML (www.srcml.de) project however,
which has a few things in common with o:XML as you will see further below.

> I see a couple advantages to an XML syntax language such as this:
> - program mutability... XML parsers are well implemented.  Creating
>   code that generates or modifies other code is simplified.

What we have here is a mixing of two elements:
1) Code storage
and
2) Code modification (aka programming)

The SrcML project is also using XML as a means of storing a program's source
code. The difference to o:XML however is that we don't expect programmers to
directly work on this XML representation. So your point is true of course, but
it is already achievable through storing code in XML. Writing new code to
generate and modify other code can take advantage of the stored code being
stored in XML. There is no real reason though why the new code should be
written in XML too (but of course it should be stored in XML again).

> - clear syntax.. one thing I like about XSLt (and by extension, o:xml)
>   is the explicit delimiters for code blocks.  To me:
>     <xsl:if test="(expression)">
>       (bunch 'o stuff)
>     </xsl:if>
>   is more clear than
>     if ( (expression) ) {
>       (bunch 'o stuff)
>     }
>   ... particularly when nested.
>   This is more of a style preference though, not as compelling
>   as the former reason.

I personally prefer the approach python takes to this (eliminating delimiters
by making whitespace responsible for the blocks):

if expression:
    bunch of stuff
else:
    other stuff

Of course this is a personal preference as you already pointed out. I think
however that it might not be the best idea to demand from programmers to write
their code in XML simply because '</xsl:if>' is easier to see as a delimiter
than '}'. If that was the case we could just as well redefine an existing
syntax to use 'endif' or anything else which is 'more clear'.

I think it is not the syntax becoming clear in XML, but rather the semantics.
Storing your java code in XML takes a lot more space and the reason is not
only that XML tags are longer, but because you make semantic information
explicitly available. Let's take a look at this simple expression:

a = (SomeClass)v.getSomething();

This is how it translates to SrcML (as I know more about it than o:XML or
rather MLML in this case, but the idea remains the same):

  <expr>
    <assignment operator="assign">
      <lvalue>
        <expr>
          <var_use name="a"/>
        </expr>
      </lvalue>
      <rvalue>
        <expr>
          <typecast>
            <type name="SomeClass"/>
            <expr>
              <obj_access type="method" name="getSomething">
                <object>
                  <expr>
                    <identifier name="v"/>
                  </expr>
                </object>
                <arguments/>
              </obj_access>
            </expr>
          </typecast>
        </expr>
      </rvalue>
    </assignment>
  </expr>

This takes up quite a lot more space now, but look at the information which is
now explicitly available. Of course all this information was right there at
the start, but if you want to write a program making use of this information
it has now become a lot easier. The program can easily find out that we have
an assignment here, what left and right values are, that a typecast and a
method call is involved, etc etc.

This is also a point, where you have to decide what you want to do with that
XML representation. If you want to use it as you pointed out in your first
argument - to write code to generate and modify other code - then you will be
glad to have direct access to all the semantic informations. If you want to
write your code in XML directly you will of course not be happy about having
to write everything in such explicit detail.

> - syntax error issues.  Many of what would normally be syntax
>   errors determined by the compiler, can be picked up by verifying
>   a program against an XSD schema document.  Probably makes it
>   easier for those writing compilers?

Again a reason to store programs in XML. And yes it does make it easier for
those writing compilers, as the frontend parser is no longer neccessary (or
rather replaced by a commonplace XML parser). If you don't write the programs
directly in XML though it comes at the cost of an additional parser being
needed to perform the translation to XML.

If you write the programs directly in XML it makes it easier for compiler
writers too, compared to writing them in Java/C/... However I think this
is an irrelevant point when deciding whether to write code in XML or not. A
programmer does not decide to use a language because those who have written
the compiler for it had an easy time. Why not all use brainfuck then? Finding
syntax errors is trivial and a full blown compiler takes less than a hundred
lines. But it's obvious that no one wants to write programs in brainfuck just
because compiling it is so nice.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

There are no significant bugs in our released software that any significant
number of users want fixed. (Bill Gates)