Thread: [exprla-devel] Re: [XPL] Some additional advantages of XPL
Status: Pre-Alpha
Brought to you by:
xpl2
Menu
▾
▴
exprla-devel
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:30:13
|
--- 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 ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:30:44
|
--- 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 ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:34:39
|
--- 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 ---
|
|
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 ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:36:13
|
--- 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 --- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X