[Xotcl] poll for opinions
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 20 Feb 2002 16:28:53 +0100
Dear XOTcl community,
we are working currently on various issues which we
think are important for our 1.0 release:
- speedup through byte-code support
- better components with introspection facilities
- easy to use rel-db interface
...
concerning the first item: i was performing some
experiments for providing extension-specific
byte-code support, e.g. to allow to register
byte-code instructions for the most-used commands
in XOTcl (such as [self], next, etc.). through
these xotcl-specific bytre-codes we get
nice improvements (e.g. [self]
is more than 10 times faster, some benchmarks
improve by 40%). This improvements require
a patch for tcl, which is therefore not acceptable
for most people now. We talked to the Tcl
implementors to include such a patch, but currently
some of them think about a substantial redesign
of the bytecode which has much more constraints once
extension writers depend on the current design, so
i don't expect that a patch with this functionality
will be intergrated in tcl in the new future.
however, there is already some influence for XOTcl:
In Tcl, compilation is command based: this means,
for every call of a command literally available in
the the body of a proc, a bytecode sequence can
be provided by the command. This means that it
is possible to compile the body of method m1 in
Object o
o proc m1 {} {
o set x 123
}
o proc m2 {} {
[self] set x 234
}
to something clever, but not the body of m2,
since the command in the body of m2 depends on
the results of [self] which the compiler does not know.
Since m2 is the much
better style, we should address this principal
problem, since this will ease future improvements for xotcl.
An easy soultion is to provide a tcl-command
selfInvoke, which can be byte-compiled. selfInvoke has
the following sematics
proc selfInvoke args { eval [self] $args }
and if implemented in C, it leads already to
some speedup (without bytecode support), since the call
of the tcl command "self" is replaced internally by a
call to a c-function.
Another advantage is that the number of [self] in an
xotcl script is reduced, an programs might become easier
to type ()since less shilft/alt/.. keys have to be pressed)
and hopefully less "cluttered" to read.
yet another advantage is that this change makes in a program
more visible when a delegation is used (call to a
different object) instead of the call of the current
object.
since "selfInvoke" is not something i would like to
type often either, and this is rather a language
primitive, we are considering some syntactical
alternatives, and want some input from the
"community". Certainly, the explicit call of [self] or
to another object will be supported in the future as well.
what do you think about the following variants:
o proc m1 {} {
[self] set x 123
}
o proc m2 {} {
.. set x 123
}
o proc m3 {} {
= set x 123
}
o proc m4 {} {
=> set x 123
}
o proc m5 {} {
- set x 123
}
other ideas?
note, that the used symbol cannot be used as an
(global) object name (same as with next, self, set,
and other global tcl commands)
what do you think?
best regards
-gustaf neumann
Date: Wed, 20 Feb 2002 16:28:53 +0100
Dear XOTcl community,
we are working currently on various issues which we
think are important for our 1.0 release:
- speedup through byte-code support
- better components with introspection facilities
- easy to use rel-db interface
...
concerning the first item: i was performing some
experiments for providing extension-specific
byte-code support, e.g. to allow to register
byte-code instructions for the most-used commands
in XOTcl (such as [self], next, etc.). through
these xotcl-specific bytre-codes we get
nice improvements (e.g. [self]
is more than 10 times faster, some benchmarks
improve by 40%). This improvements require
a patch for tcl, which is therefore not acceptable
for most people now. We talked to the Tcl
implementors to include such a patch, but currently
some of them think about a substantial redesign
of the bytecode which has much more constraints once
extension writers depend on the current design, so
i don't expect that a patch with this functionality
will be intergrated in tcl in the new future.
however, there is already some influence for XOTcl:
In Tcl, compilation is command based: this means,
for every call of a command literally available in
the the body of a proc, a bytecode sequence can
be provided by the command. This means that it
is possible to compile the body of method m1 in
Object o
o proc m1 {} {
o set x 123
}
o proc m2 {} {
[self] set x 234
}
to something clever, but not the body of m2,
since the command in the body of m2 depends on
the results of [self] which the compiler does not know.
Since m2 is the much
better style, we should address this principal
problem, since this will ease future improvements for xotcl.
An easy soultion is to provide a tcl-command
selfInvoke, which can be byte-compiled. selfInvoke has
the following sematics
proc selfInvoke args { eval [self] $args }
and if implemented in C, it leads already to
some speedup (without bytecode support), since the call
of the tcl command "self" is replaced internally by a
call to a c-function.
Another advantage is that the number of [self] in an
xotcl script is reduced, an programs might become easier
to type ()since less shilft/alt/.. keys have to be pressed)
and hopefully less "cluttered" to read.
yet another advantage is that this change makes in a program
more visible when a delegation is used (call to a
different object) instead of the call of the current
object.
since "selfInvoke" is not something i would like to
type often either, and this is rather a language
primitive, we are considering some syntactical
alternatives, and want some input from the
"community". Certainly, the explicit call of [self] or
to another object will be supported in the future as well.
what do you think about the following variants:
o proc m1 {} {
[self] set x 123
}
o proc m2 {} {
.. set x 123
}
o proc m3 {} {
= set x 123
}
o proc m4 {} {
=> set x 123
}
o proc m5 {} {
- set x 123
}
other ideas?
note, that the used symbol cannot be used as an
(global) object name (same as with next, self, set,
and other global tcl commands)
what do you think?
best regards
-gustaf neumann
