Tcl - Re: proposal: reswitch

Author

Re: proposal: reswitch

Andreas Leitgeb

2006-01-25, 7:57 am

Fredderic <put_my_name_here@optusnet.com.au> wrote:
> On 19 Jan 2006 12:29:20 GMT,
> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:
>
> I totally disagree that using [break] and [continue] in [switch]s will
> break anything, so long as you do it via an option

Again, I agree with you on the point, that break/continue
*with* arguments/options are at least feasible to re-use.
(The "out of question" was minted on break/continue as
argument-less commands, and I still stick to that)

DKF seems to be very unhappy about new exceptions (at seems
there is some swamp, that we'd better not investigate here)

> Since [break] and [continue] are little more than convenience
> functions these days, this opens the possibility to at a latter
> date introduce the "return -levels" concept to loop levels within
> a procedure (which I've used, and have seen used, very successfully
> in some other languages). I

Yes, I've also dreamt about such a feature in tcl (namely
breaking out of several loop-structures at once), and that's
exactly the reason, why I'm not too happy with break/continue
used with arguments for switch, because this really might
raise some confusion, as to which arguments will leave
which (and how many) levels of loops and/or switches and/or
other constructs before they're really handled.

As long as they are limited to loops, it's somewhat easier
to recognize every loop that encloses the break. If some
argument makes it work on (e.g. for a start) switches, I'd have
no idea, which other constructs would be counted and which not:

while {...} {
switch {...} { ... {
foreach ... {
if {...} {
break -someoptions -level 2
}
}
}
}

> (Personal note: Yes, I do accept, and already accepted the possibility
> of, my [catch] idea being rejected. :) I've been using TCL for a few
> years now, since about 1997, though until recently I was stuck with
> using an oldish version that was supplied -- now that I'm able to use a
> reasonably up-to-date version, I'm taking the opportunity to discuss
> some of the things that have been bugging me for most of those years,
> when they come up, and I'm taking the opportunity here to express some
> things that have been bugging me on a conceptual level, during this
> overall discussion.)

too understandable :-)
I've been Tcl'ing since about 1995 (iirc, that was with tcl7.4b4)
And since the earliest days I'd been asking for a feature, which
is now finally in 8.5: the {expand}-feature :-) (although it's
very different from my original proposals, it's only (but still)
slightly different from my own latest proposal in that direction)
And I've also proposed stuff, that I'm actually actively trying
to forget (preprocessing for comments,...)

> A one-hit-wonder is only acceptable if it IS the means to
> obtain such generalised usage. TCL's tendancy towards "package"
> type commands (dict, file, etc.) are a very good example of not
> creating one-hit-wonder functions
actually, my latest script has a preamble:
interp alias {} sindex {} string index
interp alias {} slen {} string length
....
interp alias {} bscan {} binary scan

To help keep my lines < 80 chars

While I understand, that the core should not clutter
the global namespace too much, I can freely do it in
my own code :-)

> Also IMHO, a switch-only command is just cruft
> in every other context -- admittedly sometimes
> this is necessary, but this time it isn't.

Hmm, you're probably right that "reswitch" really isn't it.
As you say it's much to switch-specific.
But break/continue also have their problems.
Something like "redo" could be a name general
enough, but would be a new exception, still.

> I agree... Which is why I thought the use of a [reloop] type function
> was appropriate, because it streses the fact that contrary to the other
> two, this one CAN cause loops. [switch] to my mind, isn't a looping
> construct. However it is none the less a block construct, and so the
> possibility to loop is worth considering.

"if" is also a block-construct, isn't it ?-)

> One place where I've needed
> to wrap a [switch] in a [while], is to implement state machines, for
> example.
Yes, that would be Use#1 for me, too (currently I wrap
switch in a loop for this type of use, and I think that
the keepers of tcl spirit would rather not change that).

> The documentation I have reads: " The switch command matches
> its string argument against each of the pattern arguments in
> order. " I'd be concerned that hash-based optimisation might remove
> this constraint.
Even if it does so, it would do so only for -exact matching.
and in that case, it doesn't make a visible difference other
than speed.

> The only part that would need further
> discussion, is whether reloop would run
> the increment part of a [for].
Imo, it should most certainly *not* run it.
The incr-part must always be followed by the loop-check, so if
you omit the latter, also omit the former.

The incr-part generally advances some index or iterator, and
the loop-condition is supposed to check, if we're out of
iterable things. While it is surely conceivable to have
a situation where the incr-part needs to be run more than
once before checking the condition, I think this would be
a bad thing for almost (but not quite entirely) all loops.

> I'd hope that only the last "default" block would be the default one.
Yes, of course. t'was merely a joke :-)

> Personally, considering the stringyness of TCL, I think they should
> have broken with tradition and added an "else" clause to the [switch],
> similar to the [if].
alt.history.what-if ?
I guess you're right, but then perhaps not:
the patterns and bodies can be separate arguments,
so you might end up with:
switch 42 12 {} 13 {} default {puts buh}
where the other way would be:
switch 42 12 {} 13 {} else {puts buh}
Not much of a gain :-)

> [redo] works for me... My main pet hate in this discussion, is the
> introduction of a switch-only command and/or exception.
Understandable. I've already said good-bye to "reswitch"
as the name of the not-good-bye's new exception/command :-)

> I'm hoping this issue won't be solved on the basis of "oh, it's just
> too hard to fit that stuff into my new idea for optimisation".
> Optimisation is good, but I think it should never be a driving factor
> in a high-level non-compiled language, that's what low-level and
> compiled languages are for. Develop the language, THEN optimise. Not
> the other way around. If the optimisation doesn't work out, maybe
> you'll come up with a better method next version.

But there are often things that are correctly avoided on the basis of
principial lack of optimizability.

> [ reswitch-behaviour versus hashtable-optimization ]
> It may also be possible to add a -fast option to [switch],
> telling it that you don't care about the test order, or alternatively
> add a -strict option that states that you do (depending on the current
> consensus of what the existing official documentation says).
Now, such a "-fast" option would definitely be
"design controlled by optimizability". I think
this option should be tried very hard to avoid.
(controlling this should not be a "user-servicable part".

Joe English

2006-01-27, 3:59 am

Donal K. Fellows wrote:
>Fredderic wrote:
>
>We're not in any hurry to revisit this issue. It was the biggest
>argument on tcl-core I've ever seen, surpassing even some of the OO
>stuff. :-)
>
>
>I'm not planning any. I really hope nobody else is. :-)

And just in case anybody is, there's a large stockpile of
pitchforks and torches ready for the peasants to pick up
and wield against the next mad scientist to come around
with a misbegotten syntax extension.

--JE

"11 rules!"

Sponsored Links