[exprla-devel] Re: [XPL] Some additional advantages of XPL
Status: Pre-Alpha
Brought to you by:
xpl2
From: reid_spencer <ras...@re...> - 2002-01-31 08:34:46
|
--- 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 --- |