Putting predictability into byte-compilation
Evil Son
http://groups.google.com/group/comp.lang.tcl/msg/453d9d1596130841
in a thread about "regexp vs string match" where Jeff Hobbs writes
And the reason is that [string equal -length ...] is an uncommon
case,
so no bytecode was created to support it. It is technically feasible
(rather easy from the bytecode perspective).
I understand that given the limited resources, it is better to devote
energy to the commonest cases. But his parenthetical remark stuck in
my mind.
So here comes one of his ideas where Ungrateful Evil suggests more
work for the development team (did I mention they don't seem to
sleep). Is it feasible for one of our experts to write a nice
tutorial with an example that shows how to "byte-compile-enable" an
option such as -length in [string equal -length ...]?
Why is it a good thing?
1. Not byte compiling some options to a command increases the
"surprise factor". (And of course it's slower)
2. If the task of adding the feature is "rather easy" (I'm reminded of
proofs in Math that are said to be "trivial"), and given that we have
a fair few C programmers here, it would appear that the work put into
a tutorial will pay for itself many times over. So people like Jeff
can mentor others and audit and accept code rather than have to write
all of it - especially this kind of code that the old hands may find
tedious (they've done it so many times) but which new hands may find
exciting and challenging (they are actually *contributing* and they
get deserved credit).
Is there any merit in the suggestion? Can we teach more to fish? Can
we accelerate Tcl progress?
Regards Evil Son
[ref]: http://wiki.tcl.tk/1677
Alexandre Ferrieux
Without attempting to pour cold water ... one extra criterion is code
consistency, and a tiny core.
(especially the list of bytecodes: it is already rather ugly, by a
nasty side-effect of Tcl's beautiful pass-by-name style)
Just letting opcodes proliferate and special cases be BC-enabled as
soon as someone wants them and provides an implementation (even a good
one), has no chance of preserving that ideal. That's why there is the
TCT: their right to say NO is even more important than their
collective coding skill.
That said, the Patches tracker on SF is the unique place to put your
proposals. If you find a good compromise between {extra code,extra
opcodes,frequency of need,performance boost}, nothing should block its
inclusion...
-Alex