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

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

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

>  Jonathan Burns wrote:

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

Yes. What I have in mind is cases such as the well-known 
renderinglist,
in which a graphic element can act on method calls like
"Draw", which are generic to all graphic element types, and also
on calls like "Smooth", which belong specifically to spline curves
and such.

In Smalltalk, the receiver of a call can handle it directly, or
else pass it up its chain of inheritance to some superclass
which it belongs to. The same mechanism requires special coding
to implement in C++.

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

There will be power to spare, I think.

But I think the power will show itself through the central
concept of hierarchy - meaning recursion. And grammar, or
regular languages, which are an intricate kind of recursion -
but which have a theory behind them which contains efficient
basic algorithms.

Let me get back to this, when I've studied up on XSLT.

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

OK. You know how we speak of indirect reference to data elements,via
pointers. We can refer to the element as defined, or to a
pointer to a choice of elements, or a pointer to a choice of
pointers.

I suspect that the answer we want is indirect typing.
We can refer to an operation by the types it takes as defined,
or by indirect types which may stand in for a choice of types,
or to a choice of indirect types.

We may get this implemented by operations on namespaces. Maybe.

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

As with C pointers. Yeah.

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

Dynamic namespaces again.

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

Some posts back, I was trying out the idea of variables ascontainers,
therefore as documents.

But of course, it's a virtual container, if you can reach in
and get stuff out.

What you're suggesting, I think, is that a variable is a virtual
container - like a typed URL, with read/write capability. The type
of the container, and its oontents, are independent of its location -
whether local or remote.

Actually, in this sense, a Web page is a virtual document. To look
at it, you can't tell whether it is from your site or another (the
URL has to tell you that), or whether it was just sitting there as
data, or constructed on the fly by a CGI program.

Hmmm.

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

This'll date me. I remember when there was much fuss about"relocatable
code" and how to compile it. The point was, that
the traditional machine code was compiled with absolute
machine addresses hardwired in. It only ran correctly whem
it was located at a specific place in memory.

Then along came relocatable code, which could run no matter
where it was placed. How? Either indirect addressing, or
base registers, which are a machine-level form of indirect
addressing.

The exact same trick has been done lately, in the form of
relative URLs on Web pages. A site can run on my machine;
then I FTP every page to a remote host, and all the links
still work there.

You're talking about automatically switching a variable
from local to remote reference.

We're near the mother lode here, I think.

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

 Another case of indirect typing.

Stone the crows. This is getting interesting.

Thnaks for a most enlightening set of suggestions. Gives me
a lot to think about.

Jonathan


In evolutionary terms, we're standing still, while doors get smarter 
and
smarter.
You see where this leads.
--- End forwarded message ---