[XPS-devel] XPL 0.1.1 Released

[Reid S. <ras...@re...>]

XPLers,

I have updated the schema definition for XPL as a new release, release
0.1.1. This release contains numerous corrections and additions but
retains the basic structure of the language. Included with the release
is full documentation (in case you don't have XML-Spy) and a full
example of the use of the XPL-en schema. Please download and comment,
you'll find this version much more amenable than the 0.1 version.

I would like to solicit your feedback on a variety of topics about the
language definition so far. When you get to the point that you grok what
I've done, please see if you can provide your feedback on the following
topics.

1. Incorporating Memory Management (Regions and Segments) Into The
Language. I wanted to do this to be explicit in the language about how
memory is organized and allocated so that it isn't shuffled off to some
"library routine" that varies from machine to machine and uses different
strategies. By incorporating memory management in the language, the
programmer has greater control of how the program utilizes memory.

2. Defining Files, Streams, Documents, Transforms, Segments, and Regions
as Object Classes. Regardless of whether you think it is useful for
these things to be in the language (as opposed to some "standard
library"), what do you think about including these things in the class
inheritance hierarchy. I think its a nifty idea because it allows you to
build a type hierarchy around things that interact with "external
entities" (i.e. files, streams, documents, memory, etc. are all external
to the XVM). 

3. Using Lisp Style Expressions. The operator expressions in XPL are
similar to LISP. That is, an expression is built from the inside out. 
Instead of saying a+b, we say +(a,b). Instead of writing (a*(b/c)) we
write *(a,/(b,c)). This structure falls naturally in line with XML
content models and makes it very easy to correctly parse the programming
expressions with an XML parser.  I believe that it will also  be very
efficient way to program and generate code.  However, it is not
necessarily intuitive for the novice. The last example above in XPL look
like:

    <mult_ii>
        <get_i>
            <value_loc>a</value_loc>
        </get_i>
        <div_ii>
            <get_i>
                <value_loc>b</value_loc>
            </get_i>
            <get_i>
                <value_loc>c</value_loc>
            </get_i>
        </div_ii>
    </mult_ii>

Its rather verbose, but functionally elegant.  I haven't worried about
how "pretty" XPL is because I don't think anyone is going to program
directly in the XML text. A visual editor (emacs mode?) that simplified
editing XPL would be an excellent tool to build for XPL. Any volunteers
out there?  Does the inelegance of the syntax bother you?  What if the
entire structure of the program was represented in 3D and manipulated in
a VR kind of way? Would it bother you then?  Because its XML, we can do
all kinds of transformations from other languages, syntaxes and editing
systems and still end up with XPL as the basic language that gets
compiled. It is this latter aspect of the language that is important
(rigid semantic specifications, fast compilation, accurate results). 

4. Everything In A Method/Function  Is An Operator. I wanted to provide
a simplicity of design such that program could be constructed by
arbitrarily nesting various operators. The fact that the control flow
operators (if, repeat, for, foreach, select, switch...) can return
values means they can be used directly in a computational expression.
C++ provides a very limited form of this with the ?: operator. I've
generalized it so that all control flow operators may be used in
computation expressions. For example, XPL permits the following C++
equivalent:

    int array[maxlen];
    /* ... */
    int i = for (int j = 0; j < maxlen; j++) { if (array[j] == 15) {
result j; break; }

Note that I take the liberty that this C++ code can (a) assign the
result of a for loop to an integer variable and (b) has an operator
"results" which specifies the result for the enclosing block. I won't
write the equivalent XPL because there is an example similar to this in
the release.  But, what I would like to know is what you think of this
ability? Power or confusion?

5. Method Discriminants. Unlike some other popular object-oriented
languages, I differentiate between the messages sent to an object and
the methods that implement those messages. To me, these are not the same
things. While the message send can be optimized to a simple function
call in many cases, XPL also directly supports active objects (running
in their own thread) in which case message sending is an asynchronous
operation. Furthermore, I allow a class to implement a method multiple
times. To disambiguate which methods get run on which message sends, I
have introduced the notion of a method discriminant. Discriminants are
simply boolean expressions that are computed at runtime to determine
which methods get run. While the same ends can be achieved with
if/unless/switch operators in the body of a single method, the use of
discriminants provides the programmer with some syntactic sugar to help
keep the program organized. First, method names are not necessarily the
same as the message names. Since multiple methods can be defined for a
single message on a class, this must be true. Consequently, the method
can be named after what it does, not what the message means. 
Extensibility is enhanced because adding a new behavior for a message is
as simple as adding a new method, leaving the existing methods alone and
simply defining a boolean expression that determines the conditions
under which the method executes. This style of programming greatly aids
state machine development since the state of the machine can be used as
the discriminant.  Finally, the XPL compiler can eliminate any apparent
overheads by simply recombining all the discriminant expressions into a
single function that implements all the methods.   I'd like to hear your
opinions about this.

6. Overlays -- Anyone Need 'em? Overlays in XPL are like unions in
C/C++. They provide a way for using the same memory for multiple fields.
However, because XPL is a type safe language, Overlays can't be used for
type coercion or bit fiddling. Any attempt to extract a field other than
the last one set will yield an error. So, what's the difference between
that and just using individual variables or a struct? Is memory
consumption these days really that big a concern?

7. Documents & Transforms Needed? Since XPL is based on XML and the XPS
will use XSLT heavily, I thought that it would be useful to incorporate
the notion of an XML document and an XSLT transformation directly into
the language. However, I haven't been able to think up many operators
that could be invoked on these kinds of objects. Perhaps I just haven't
thought about enough (a lot has gotten deferred), but it occurs to me
that perhaps these things are just not as fundamental to an XML
programming language as I had originally thought. The basic idea is that
you could invoke an XSLT transform on one document and get a different
document instance after transformation. Documents could be parsed by
sending messages to a parser class much the same way as DOM/SAX do. In
fact, it could just be the DOM or SAX APIs. How important is it to put
this in the core language as opposed to supporting it in a standard
library?  Is it something that every XPL program might need?

8. Multiple Natural Language Support. One of my original goals in
designing XPL was to allow the language to support multiple natural
languages. That is why the specification is broken into two parts,
XPL-Abstract.xsd and XPL-en.xsd. The abstract definition defines all
abstract elements using verbose and precise names in English. The
English language version (XPL-en) defines concrete elements using
shorter english names. The intent is to also create XPL-fr.xsd
(Francaise), XPL-de.xsd (Deutch), XPL-sp (Espanol), and other natural
language versions of the abstract language definition. All these natural
language versions would be compilable as XPL because the compiler will
only look at the abstract substitution group names for the elements, not
the actual names of the elements for a given natural language.  I think
this is very useful and would make XPL much more friendly and amenable
to programmers in other languages.  Your opinions on this?

I hope to hear back from you on these topics and any others you care to
bring up.  

Best Regards,

Reid Spencer
XPS Project Lead