[exprla-devel] Re: [XPL] Some additional advantages of XPL

[reid_spencer <ras...@re...>]

--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
Alexander Gutman wrote:

>  Hello, friends.
>
> Here are some of my thoughts concerning XPL
> and what it can be useful for.
>

Michael! Garreth! Ali! Tune in!

This man's got some serious input into the Advantages question.

> 1. XPL as a source language
>
> A program written in XPL can be transformed
> into programs in different languages.
> This transformation can be performed by suitable XSLTs:
> for each destination language, we have a corresponding
> XSLT, one for Java, another for JavaScript, etc.
>

It's terribly tempting to suppose that there is "just one"
procedural language. I think that for control flow, it is
nearly the case. Everyone has an If, a Do-While, and a
Call ... maybe a For, maybe a Switch-on-Case, but we could
do without these in a pinch. Try/Catch is left as an exercise
for the reader :-)

Message passing is problematic, though. There is a clear
difference between object method calling in C++, where the
class is predetermined in the compile phase, and in Java
or Smalltalk, where determining the class is part of the
execution.

Variable scope and lifetime also present some problems.
We'll need to do proper comparisons between the classic
scripting languages (Tcl, Perl, Python, to name the obvious)
to make certain we can handle these by tree-transformation.

(memo to self: get an overview of XSLT, Quick.)


> 2. XPL as a universal programming language
>
> Consider the following situation. A developer creates
> (or designs) an application for the Web. Some fragments
> of the code correspond to the server part, while other
> fragments should be executed on the client side.
> Therefore, these fragments should be written
> in different languages: for instance, the first in Java
> and the second in JavaScript.
>
> However, at early stages of development, it is rather
> difficult to predict which fragments of the application
> will work on a server and which on a client.
>

Good point.

> Moreover, there are different clients. Some of them
> are thick, other are thin. For thick clients, some
> fragments of the code will be executed on the client
> side and, for thin clients, the same fragments will work
> on the server side.
>
> In addition, it is quite possible that, in some time,
> a need will occur to transforming the application into
> a different platform which will require a different
> language, or some fragment will be separated for working
> on an intermediate server (for instance, in order
> to make the main server part more lightweight).
>

This reminds me strongly of the rationale for COM.

I think the lesson we'll learn, if we don't anticipate it,
is that XPL applications will often be object-oriented.
That is, each section will be available through an interface,
and call code in other sections by message-passing. AND,
a section when it calls another, will be unaware whether
this other is local or remote.

This would really please the majority of the Web programming
community.

But I cannot resist suggesting an idea which has been with me
for a long time:

    The interface to an object class is usually a list of method
    calls: action(parameter,...). The calls constitute the language
    which the object speaks, if you will. But every XML document
    type IS a language, potentially a far more sophisticated
    language than the usual class interface. So when we define
    a collection of related DTDs, we can think of it as defining
    s collection of interfaces. XML documents would then be the
    format for messages, each in the language of its receiver.

    If it's a Calculator, it talks Reverse Polish Notation (Forth!)
    If it's a Relational DB, it talks SQL.
    If it's a Virtual World, it talks VRML (or my own XTFP).

    ... and here's where the snake swallows its tail ...

    If it's an XML document, it talks Path Notation.

    Now it may be that in the name of sanity, we'll have to
    throttle the wealth of XML grammars down to lists of methods
    with fixed parameter lists. But something in me itches to see
    if I can define the relations between grammars, so as to
    realize complex systems as "Literate Classes", like above.

> If the code is written in XPL, all the above problems
> are easily solved: just transform different parts
> of the code into different languages.
>

Yes. It's very interesting that COM and CORBA cut everything down
to class interfaces, so that architectures can be defined which are
independent of language bindings. In a way, the XPL push is saying
"Why bother, when we can translate between languages automatically?"

> 3. XPL as a program storage format
>
> With the help of a special editor/environment,
> a user can create XPL programs by using his/her
> favorite programming language.
> This means that, on the screen, the user sees
> the code as if it is written in, say, Java,
> while the code is actually stored as an XPL program.
> Later, the XPL staff can be transformed into another
> language, say, C++. The advantage is obvious:
> a developer creates a C++ code by using Java coding.
>

My comments above apply here.

It is straightforward to translate Java control flow
to C++ control flow. The syntax is just about the same
anyway.

But, Java's dynamic class binding will not translate to
C++ static binding, without the creation of some kind of
object tag system for the C++. This is a problem.

> By the way, such an editor/environment will be very
> useful even if the destination is XPL: native XPL
> code is not convenient for everyday programming,
> it is rather "cryptic", and not so readable and
> concise as usual programming languages.
>

The beautiful thing is, good old-fashined compiler
technology (Lex and Yacc) is made precisely to convert
concise but locally-ambiguous high-level languages into
locally-precise parse trees - which XML represents
directly.

> 4. XPL as a skeleton for a programming environment
>
> If an editor/environment stores the code in XPL,
> it is much easier to provide very smart and powerful
> service for a user, since the DOM of the hidden XPL
> source can be effectively used. For instance,
> with the help of a simple search pattern,
> the XPL source can be queried to produce the list
> of methods available for an object under cursor
> in a very convenient and rich form.
>

(memo to self: and in your copious free time, you canread up on the 
DOM
8-!)

It's fascinating how many of the XML tools turn out to
be tools for programming languages.

> Enough for a start, I think. :-)
>
> Excuse my English.
> My native language is Russian, and there are no
> XPL applications yet which could help me creating
> messages in English by using my favorite language. :-)
>

But everything you write is perfectly clear!
No excuses required at all.

Regards
Jonathan

Software is born free, yet everywhere is found in loops
--- End forwarded message ---