exprla-devel Mailing List for XPL: eXtensible Programming Language (Page 8)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

--- In xpl-dev@y..., gutman@m... wrote:
Jonathan Burns wrote:

> 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 :-)

Yes. At this point, the only we need to do
is to choose a good XML syntax.

> 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.

Correct me if I misunderstand something.
In some languages, the type (class) of a variable's value
is fixed throughout its scope, while, in other languages,
the type of a variable's value can be different
at different execution points. Is this we are talking about?

Even if you meant something different, let's consider
this very problem, since it seems to be similar.

Every normal (foobar-complete, I do not remember the term)
programming language is powerful enough to implement
any programming concept (even multiple class inheritance
can be implemented in the Turing machine language).
The only cost is bulkiness of the resultant code.

Of course, we do not want XPL to be so weak as to be easily
(almost directly) transformed into any language.
Quite the reverse, we want XPL to be so powerful as
to be able to easily implement any concept implemented
in any language (of a wide class of them).
At least I want it to be so. :-)

As regards our question (fixed vs variable type of a value),
my suggestion is as follows: let XPL be ready for both cases.
For instance, let it be possible, when declaring a variable,
to say if the type of its values is fixed or not
(or provide an instruction saying that all the variables
within some fragment have either fixed or variable type).

If the destination language assumes only fixed types,
and an XPL program employes variable types,
the resultant code just will be more bulky.
When using XPL, it is the user who decides whether
to employ variable types. The cost is known.

> 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.

This problem seems to be similar.
As soon as the scope and lifetime of an XPL variable
are determined (for an XPL program), it is the task
of the transformation procedure to provide the corresponding
resultant code which can be either concise or bulky,
depending on the destination language.

> I think the lesson we'll learn, if we don't anticipate it,
> is that XPL applications will often be object-oriented.

A like this conclusion. :-)

> 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.

Hmm... I do not think this concerns XPL itself.
When a user writes an XPL program, he/she may suppose that
the whole program will be executed on a single machine.
Later, if the code will be split into different parts
(e.g. into server and client ones), it is again the task of the
transformation procedure to provide correct resultant codes.
And only at this step the message-passing arguments start
playing their role.

As an example, consider the following hypothetical XPL code:

  <declare variable="x" class="someClass"/>
  <if>
    <condition>
      <equal>
        <property name="someProperty" of="x"/>
        <constant value="someValue"/>
      </equal>
    </condition>
    <then>
      <assign>
        <property name="someProperty" of="x"/>
        <constant value="anotherValue"/>
      </assign>
      <etc>...</etc>
    </then>
    <else>
      <etc>...</etc>
    </else>
  </if>

Suppose that the developer decides that the whole code
should be executed on the client side except the "then" part
which should be separated into a server module.
A problem seems to arise: this part uses the "x" variable
which is declared within the client part.
No problem! The transformation procedure will create an
additional bridge code between the server's and client's "x"s
so that, whenever the server's "x" is changed, the client's "x"
also changes appropriately (and vice versa, if need be).

> 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.

You have already provided a solution: just make
the transformation procedure to create (or use)
an object tag system in this case.

--
Alexander E. Gutman
--- End forwarded message ---

exprla-devel Mailing List for XPL: eXtensible Programming Language (Page 8)

exprla-devel — This is the Developers' list for the for XPL