Home > Archive > Tcl > January 2006 > Nonstandard completion codes (WAS Re: proposal: reswitch)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Nonstandard completion codes (WAS Re: proposal: reswitch)
|
|
| Joe English 2006-01-20, 7:10 pm |
| Donal K. Fellows wrote:
>Andreas Leitgeb wrote:
>
>That risk exists, but I'd ignore it. :-)
Am I the only one who uses nonstandard completion codes
for specialized control flow?
I've used -returncode $X (where $X > 4) in the past as
an interrupt signal (to halt a long-running process),
as a way to distinguish managed failure modes from
unexpected errors, and for more conventional throw/catch-style
exception handling. It's not something I do very often,
but it does come in very handy on occasion.
--Joe English
| |
| Fredderic 2006-01-20, 9:57 pm |
| On 20 Jan 2006 21:23:41 GMT,
jenglish@flightlab.com (Joe English) wrote:
> Am I the only one who uses nonstandard completion codes
> for specialized control flow?
No... I've used them a time or three.
Though I make it a general rule to use codes >> 4, simply since the
system uses 0-4 for itself, it kind of makes sense that there might be
a 5 some day. Or a 6, or 7...
Though I figure it's unlikely there'll be a 10 or 11 in the lifetime of
my scripts (6 wholely new concepts in core looping structure, above and
beyond those already there, is probably at least marginally unlikely),
so I generally start there. On the other hand, the last script I used
extra return codes in, started at 300, since that's the value range
used by HTTP for interesting values.
Fredderic
| |
| Andreas Leitgeb 2006-01-22, 3:57 am |
| Fredderic <put_my_name_here@optusnet.com.au> wrote:
>
> No... I've used them a time or three.
>
> Though I make it a general rule to use codes >> 4, simply since the
> system uses 0-4 for itself, it kind of makes sense that there might be
> a 5 some day. Or a 6, or 7...
Yes, that's what I wanted to reply, too.
I haven't yet used it at all, but I was once just before
using it, and I considered using a larger value too, for
the very same reason.
It probably had been better to mention in the docs for
catch&return, that "some range immediately above 4 should
rather be avoided for custom exceptions, in anticipation
of more standard-exceptions to be added in future."
We could remove likeliness of a clash (reswitch versus
custom exception) even further, by adding some magic into
the message, but more on that in the original reswitch-thread.
| |
| Fredderic 2006-01-22, 10:00 pm |
| On 22 Jan 2006 09:30:59 GMT,
Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:
> It probably had been better to mention in the docs for
> catch&return, that "some range immediately above 4 should
> rather be avoided for custom exceptions, in anticipation
> of more standard-exceptions to be added in future."
You mean they don't teach common sense in grade school anymore?
(Actually, I take that back. The last thread I had input to pretty much
proved the point already.)
You're right, though... It should have been mentioned in the
documentation when the capability was first implemented, that TCL
reserves the right to add a few extra codes every so often.
> We could remove likeliness of a clash (reswitch versus
> custom exception) even further, by adding some magic into
> the message, but more on that in the original reswitch-thread.
While I disagree with the reason for doing this, the method might just
work, especially in that it's reusable (of course, it should be noted
in the documentation that a different code should be used for user
functions, even those that run along the same lines, and that codes <10
for example, are henceforth reserved for TCL's internal use, so as to
avoid this whole issue all over again in the near future). Though I
don't much like a string compare in a feature that has the potential to
see an awful lot of use, maybe some internal magic can hide that --
perhaps we should consume number 5 for "internal extensions", apply a
bit of magic to avoid those nasty string comparisons, and accept that a
few scripts will get messed up, but that they'll know better now so it
shouldn't happen again for a very long time. The same thing happened
with a few scripts that had their own [dict] command, and will
inevitably happen again to someone, somewhere, with every single new
command added to the TCL core. Doesn't help this time, but should
help future occurrences.
I've been asking myself a few questions during this sub-thread, things
that I've hit which have ruined the otherwise perfectly good use for the
[switch] command; Do we want to stop the current code block when we hit
a "reswitch", or should we continue to the end? (the continue on for now
option is fairly easily fudged in script, as could be the do-it-now by
following it with a switch-reactive break and some internal magic) Do
we want to continue searching, or just execute the next block
regardless (I feel supporting the C-style semantics is a must, I've
missed that on many an occasion, but making that the only way misses
some of the inherent magic of TCL). If we continue searching, should
we restart the search from the beginning (this can cause loops, and can
be fudged with a bit of scripting, a "do {} while" type loop would help
here -- but it's still occasionally handy). I've personally needed to
synthesise each of those situations from time to time, so I know they
exist.
Two options come to my mind for very good solutions; how about extending
[break] and [continue] with a "-switch ?string?" option. [break
-switch] would stop this code block instead of the inner-most loop.
[continue -switch] would likewise stop this code block, the difference
being that if ?string? wasn't given it would simply continue on with
the next code block. In both cases if a ?string? was supplied, the
next block that matched would be the one to go next. Personally I think
that "default" should ONLY match if NO other block does (same as it
does right now). So [continue] and [break] would never reach a
"default" block. Their semantics would be basically identical if
a ?string? argument IS given, so if you're upset about "default" not
executing, maybe [continue] could run the "default" block if no further
matches exist, vs [break] which would not.
Along those same lines, I've often wanted to be able to "reloop without
retest" (both in [for] and [while]), and have had to do some mildly ugly
hacks to get that functionality. We could consume return code 5 for
that purpose, and use that code to carry the [reswitch] functionality
(yes, I'm un-repenting in my statement that anyone who used return
code five deserves what they get ;) ). A kind of "reloop" command. It
sort of fits in after continue... We've got unconditional-non-reloop
(break), conditional-reloop (continue), and now unconditional-reloop
(reloop). And, combining it with the [continue] and [break] extensions,
you could make it a "reswitch from the beginning ([break] semantics)"
in addition to the two "continue on from where we are" choices.
Fredderic
| |
| Uwe Klein 2006-01-22, 10:00 pm |
| Hi Fredderic,
on return codes:
what about having introspection and reservation for return codes?
on reswitch and sibblings:
doing the reswitch thing should abort/leave that block of code
at that place.
I'd guess having more than a "dont break like" option is not really
that necessary.
For me the advantage lies in not having the same longish code in 2 switch
arms ( and thus reducing possible errors and furthering my lazyness. )
uwe
| |
| Donal K. Fellows 2006-01-22, 10:00 pm |
| Uwe Klein wrote:
> on return codes:
> what about having introspection and reservation for return codes?
Ugly; they're not local to interpreters. They might even be not local to
threads. That makes managing the allocator tricky.
Donal.
| |
| Andreas Leitgeb 2006-01-23, 7:58 am |
| Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
> I'd guess having more than a "dont break like" option is not really
> that necessary.
>
> For me the advantage lies in not having the same longish code in 2 switch
> arms ( and thus reducing possible errors and furthering my lazyness. )
These two paragraphs semantically contradict each other!
Those who have the same code in 5 arms shall be stuck with it?
Having just a (reverse-)C-style "(don't)break" is a half-assed
solution. In C this solution suffices only because in C
there is also "goto" that lets one jump around, anyway
(inside the switch-body and even backwards).
In Tcl, we should at least be able to have *several* (not
just the immediately previous) branches continue to one
single branch in a structured way - without a general goto.
Otherwise, dup(trip/quad/...)lication of code will not
noticably reduce - at most just in the simple cases.
I see no other sane way than use the exception-mechanism for it.
| |
| Uwe Klein 2006-01-23, 7:58 am |
| Andreas Leitgeb wrote:
> Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>
>
>
> These two paragraphs semantically contradict each other!
touche. BUT..
> Those who have the same code in 5 arms shall be stuck with it?
>
> Having just a (reverse-)C-style "(don't)break" is a half-assed
> solution. In C this solution suffices only because in C
> there is also "goto" that lets one jump around, anyway
> (inside the switch-body and even backwards).
>
> In Tcl, we should at least be able to have *several* (not
> just the immediately previous) branches continue to one
> single branch in a structured way - without a general goto.
> Otherwise, dup(trip/quad/...)lication of code will not
> noticably reduce - at most just in the simple cases.
>
> I see no other sane way than use the exception-mechanism for it.
>
a basic requirement for this would IMHO be readability.
i.e. the diverse flowchanging options to be introduced must lead
to better readability.
What variations do you/we have in mind?
1. Cbreak: continue with next codeblock
2. reswitch: continue with next switch-test
3. continue: restart at top
4. ......
uwe
| |
| Donal K. Fellows 2006-01-23, 7:05 pm |
| Uwe Klein wrote:
> a basic requirement for this would IMHO be readability.
>
> i.e. the diverse flowchanging options to be introduced must lead
> to better readability.
>
> What variations do you/we have in mind?
>
> 1. Cbreak: continue with next codeblock
>
> 2. reswitch: continue with next switch-test
>
> 3. continue: restart at top
One possibility would be to have the "payload" for the code (i.e. the
interpreter result) be a (literal) switch label to jump to. That would
enable all sorts of interesting behaviour, though without the awkward
"jump to anywhere in the function" semantics of classic C goto.
Donal.
| |
| Uwe Klein 2006-01-23, 7:05 pm |
| Donal K. Fellows wrote:
> Uwe Klein wrote:
>
>
>
> One possibility would be to have the "payload" for the code (i.e. the
> interpreter result) be a (literal) switch label to jump to. That would
> enable all sorts of interesting behaviour, though without the awkward
> "jump to anywhere in the function" semantics of classic C goto.
>
> Donal.
something like continue_at <label> ?
how do you propose to place the labels?
uwe
| |
| Andreas Leitgeb 2006-01-23, 7:05 pm |
| Fredderic <put_my_name_here@optusnet.com.au> wrote:
> Do we want to continue searching, or just execute the next block
> regardless (I feel supporting the C-style semantics is a must, I've
> missed that on many an occasion, but making that the only way misses
> some of the inherent magic of TCL).
Supporting the "continue with immediately next" surely isn't a bad thing.
Not going beyond it, *is* a bad thing.
> If we continue searching, should
> we restart the search from the beginning (this can cause loops, and can
> be fudged with a bit of scripting, [...] -- but it's still occasionally
> handy).
I personally don't care about a loop-ability of switch.
If it gets in, I'll probably use it. On the other hand, its
a "dangerous" tool, that can easily be misused to create
unmaintainable code (programming BASIC in tcl).
> Two options come to my mind for very good solutions; how about extending
> [break] and [continue] with a "-switch ?string?" option.
This would be *the* solution, if reserving new exception codes
was considered a taboo. But reserving a new exception code
for this task looks&feels better, imho.
> So [continue] and [break] would never reach a "default" block.
There are surely pros and cons for reaching the "default" block.
I don't have any strong feelings for or against.
Btw. there can be two "default" blocks, the sequentially first
of whose will just match a literal "default" value :-)
> Along those same lines, I've often wanted to be able to "reloop without
> retest" (both in [for] and [while]), and have had to do some mildly ugly
> hacks to get that functionality. We could consume return code 5 for
> that purpose, and use that code to carry the [reswitch] functionality
> (yes, I'm un-repenting in my statement that anyone who used return
> code five deserves what they get ;) ). A kind of "reloop" command.
hmm, "reloop" doesn't "look" like it would do anything with switch.
perhaps "redo"? This would sound like "reswitch" in switch and
"continue without incr/test" in loops)
| |
| Darren New 2006-01-23, 7:05 pm |
| Uwe Klein wrote:
> For me the advantage lies in not having the same longish code in 2 switch
> arms ( and thus reducing possible errors and furthering my lazyness. )
And your objection to procs to hold "longish code" is....? :-)
--
Darren New / San Diego, CA, USA (PST)
Luke, the Force is a powerful ally,
second only to The QuickSave.
| |
| Uwe Klein 2006-01-23, 7:05 pm |
| Darren New wrote:
> Uwe Klein wrote:
>
>
>
> And your objection to procs to hold "longish code" is....? :-)
>
nothing really, on occasion i found that i had an abundace of vars
to carry with me. I hate procs with 10 args.
what i usually do is split processing into 2 consecutive [switch]es
in the first switch prepare all input into general cases
in the second [switch] process the general cases
uwe
| |
| Darren New 2006-01-23, 7:05 pm |
| Uwe Klein wrote:
> nothing really, on occasion i found that i had an abundace of vars
> to carry with me. I hate procs with 10 args.
And your objection to uplevel is... ? ;-)
> what i usually do is split processing into 2 consecutive [switch]es
>
> in the first switch prepare all input into general cases
> in the second [switch] process the general cases
Probably a better design. I've just always found that when a language
as sophisticated as Tcl seems to lack a fundamental control structure,
it's because I've structured the code in an unclear way. :-)
--
Darren New / San Diego, CA, USA (PST)
Luke, the Force is a powerful ally,
second only to The QuickSave.
| |
| Uwe Klein 2006-01-23, 7:05 pm |
| Darren New wrote:
> Uwe Klein wrote:
>
>
>
> And your objection to uplevel is... ? ;-)
stopitstopitstopit pit stop!
>
>
>
> Probably a better design. I've just always found that when a language
> as sophisticated as Tcl seems to lack a fundamental control structure,
> it's because I've structured the code in an unclear way. :-)
>
OK lets dump funny switch enhancements and return to our uplevels.
uwe
| |
| Fredderic 2006-01-24, 3:57 am |
| On Mon, 23 Jan 2006 15:44:34 +0100,
Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
4. Stripping an arbitrarily applied limitation from what we already
have.
[color=darkred]
> something like continue_at <label> ?
"goto", but only in a switch? Half the fun of [switch] is that it
allows glob and regexp matches. It would be good to be able to match
on AB*, and then the more general A*. This is possible, but what if
one instance of the AB* case would be better served by simply dropping
the A and matching on the B*. This is simple example. If we're
talking about parsing a string, you could very quickly end up with
switches-within-switches involving sub-sets of the main switch patterns,
if all you have is a "goto" (aka [continue_at]).
I'm not saying [continue_at] is a bad idea. And I can't see any clean
alternative other than creating a switch-only function to do it (this
is one of the places where these one-hit-wonder commands ARE
applicable). But it's a stop-gap measure at best, in the context of
the original proposal as I read it, even if it does have its own
unique purpose.
> how do you propose to place the labels?
What's wrong with right after the pattern? We already have a
special-case body, namely "-" (which could theoretically be a valid
procedure name!).
% proc - {} {puts "forty-two"}
% -
forty-two
% switch 42 {
12 {puts twelve}
42 {-}
69 {puts sixty-nine}
}
sixty-nine
And then there's sub-expressions in the case of a RE-matched
[switch]. The switch pattern should be the code blocks "name", except
where a name is explicitly given. This would be particularly important
where [reswitch] comes into play, if multiple blocks are allowed to
have the same pattern (would come in handy where a bunch of matches
have some common pre- and/or post- code).
Fredderic
| |
| Andreas Leitgeb 2006-01-24, 3:57 am |
| Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
> OK lets dump funny switch enhancements and return to our uplevels.
I do hope that this was applied sarcasm...
proc dothing {} {uplevel 1 {
if {$foo eq "bar"} {set snafu "42"}
}}
No, I surely don't want any procedures lying around
and visible from everywhere that just perform a
snippet of another procedure, randomly accessing
or modifying callers local variables.
It might be feasible if we had procedure-local
procedures, but tcl doesn't have such a thing.
(even lambdas are not part of tcl, (yet?))
| |
| Uwe Klein 2006-01-24, 3:57 am |
| Good Morning Fredderic,
i had posted this further up(to A.Leitgreb):
<start copy>
Andreas Leitgeb wrote:
> Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>
yucky stuff deleted ..[color=darkred]
> The word was actually "TCL_CARYON" (apart from the typo (carry has 2 'r'))
you sure i didn't have these in mind ?;-)
[color=darkred]
[color=darkred]
> Why should we need any new options at all?
if the alternative is jumping on labels that is ok with me.
>
> Either a certain exception is thrown inside a body -> new behaviour
> or not -> classic behaviour
ups i would have liked to just use [continue] but that would break
code that uses [continue] in [switch] to continue in the enclosing loop.
would allowing options to [continue] break anything ?
> * "continue_at" exception with a <label>:
> (that is: like reswitch, but further do -exact matching)
> + many branches can continue to the same "common"-branch
> + even simpler (because one doesn't have to think of a value
> that would only match the intended branch)
> + since labels are(would be) literal constants, hash-based
> lookup can be done.
> -(?) eventually requires magic to tell patterns from labels.
>
what about using the literal patterns as labels?
they are already there and the meaning is obvious.
- you can not jump into some abitrary place.
switch $value \
ABC {
do_body_ABC
continue after AB*
} AB* {
do_body_AB*
continue at/before XYZ
} DEF {
do_body_DEF
if {$loopflag} {
continue at top
} else {
continue after end
} XYZ {
do_body_XYZ
} default {
do_default
}
<end copy>
uwe
| |
| Donal K. Fellows 2006-01-24, 7:57 am |
| Uwe Klein wrote:
> what about using the literal patterns as labels?
> they are already there and the meaning is obvious.
That was indeed what I was proposing. And it admits *very* efficient
implementation, though I'm not sure I like that it uses an exception
code in the first place. Those things leak.
Donal.
| |
| Donal K. Fellows 2006-01-24, 7:57 am |
| Andreas Leitgeb wrote:
> (even lambdas are not part of tcl, (yet?))
The vote on that is probably this w .
Donal.
| |
| Matt Newman 2006-01-24, 7:57 am |
| As a long time user of Tcl (1991-) I just want to say that one of the
overriding factors for me in Tcl's appeal has been SIMPLICITY.
Both in terms of writing (*and* reading) scripts, and extending where
needed in C.
The lack of complex syntactical constructs and a simple clarity of
inputs and outputs to commands (result, vars, return-code) enables the
language to be extended in an application-specific manner with relative
ease.
If we end up putting into Tcl a whole raft of complex syntactical
contructs, for me it ceases to be Tcl, becomming more and more like
Perl etc.
If I feel Perl is appropriate for a given project I can use Perl, if I
feel Java is right in a given context I can use Java, but please don't
throw away the simplicity that is Tcl - it really is one of its major
draws.
To be clear - I am very much in favor of Tcl evolving - but only in a
manner that keeps and builds upon its existing strengths.
| |
| Donal K. Fellows 2006-01-24, 7:57 am |
| Matt Newman wrote:
> To be clear - I am very much in favor of Tcl evolving - but only in a
> manner that keeps and builds upon its existing strengths.
Nicely said. Thanks.
Donal.
| |
| Fredderic 2006-01-24, 7:05 pm |
| On Tue, 24 Jan 2006 11:05:00 +0100,
"Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> wrote:
> The vote on that is probably this w.
Great, another procedure of mine about to be wiped out by a new core
function.
I wrote a lambda procedure (probably miss-named, but it was the
closest name I could think of at the time). Essentially it shoves a
list of variables you feed it into an array, then creates a _lambda
proc that upvar's those variables into the proc as locals, before
executing your script fragment. The scratch proc is then executed
within an [uplevel 1] so that it itself executes in the callers
context.
% set junk 7
7
% lambda {{abc 3} {def junk #0}} {expr [incr abc] + [incr def -1]}
0 10 {abc 4 def 6}}
% set junk
6
% set abc
can't read "abc": no such variable
The second term is the script fragments return value. The third term
is a dict containing the new value of the local variables the script was
executed with. upvar references (created by the third argument in a
variable definition) are handled by fetching the current value of the
referred to variable, storing it in the array, then copying it back
again afterwards. The first term is a catch return code, and in the
case of TCL_ERROR, the errorInfo and errorCode variables get appended
to the return list also.
There's probably a better way of doing it, it's little more than a
quick hack because I wanted to get on with what I was doing, but it
works, I think (I haven't tested it extensively). There's also an
interesting side effect; all referenced variables are read once (before
the script fragment is executed), and written at most once (after it
returns). It'll also create and destroy any referenced variables that
were unset or created by the script.
proc lambda {bindList script} {
set upList {upvar #0}
set upCopy {}
foreach bindItem $bindList {
foreach {varName varValue varLevel} $bindItem {break}
if { $varName == "**" && $varValue != {} && $varLevel != {} } {
set local_list [uplevel $varLevel [list info locals]]
foreach varName [lsearch -inline -all $local_list $varValue] {
upvar 1 $varLevel $varName var
if { [info exists var] } {
set ::_lambda($varName) $var
set ::_lambdb($varName) $var
}
lappend upCopy $varLevel $varName $varName
}
continue
}
if { ! [info exists local($varName)] } {
lappend upList _lambda($varName) $varName
}
if { $varLevel ne "" } {
if { [string is digit $varLevel] } {incr varLevel}
upvar $varLevel $varValue var
if { [info exists var] } {
set ::_lambda($varName) $var
set ::_lambdb($varName) $var
}
lappend upCopy $varLevel $varValue $varName
} else {
set ::_lambda($varName) $varValue
}
}
proc ::_lambda {} [join [list $upList $script] ";"]
set code [catch [list uplevel 1 ::_lambda] resp]
set retInfo [list $code $resp [eval dict:create [array get ::_lambda]]]
if { $code == 1 } {
lappend retInfo $::errorCode $::errorInfo
}
foreach {varLevel varValue varName} $upCopy {
upvar $varLevel $varValue var
if { ! [info exists ::_lambda($varName)] } {
unset var
} elseif { ! [info exists ::_lambdb($varName)] || \
$::_lambda($varName) ne $::_lambdb($varName) } {
set var $::_lambda($varName)
}
}
catch {unset ::_lambdb ::_lambda}
return $retInfo
}
If anyone spots any errors, or has any improvements (or a better name
that won't clash if the lambda proposal gets into core), do let me
know. :)
Fredderic
| |
| Fredderic 2006-01-24, 7:05 pm |
| On 24 Jan 2006 03:19:37 -0800,
"Matt Newman" <matt.neuman@gmail.com> wrote:
> To be clear - I am very much in favor of Tcl evolving - but only in a
> manner that keeps and builds upon its existing strengths.
This thread hasn't changed anything. Even with any of these
suggestions, [switch] will still work exactly as it used to. Give it a
string, and it'll run the first code block with a corresponding pattern.
The difference, is only in what it CAN do. All the original TCL
concepts still apply. The pattern is a word, and code block is a word,
and the option switches which might now appear in between, look like
option switches. If sub-expression variables are added for RE matches,
they'll (presumably) be in the same familiar order as per [regexp]. So
everything's the same as it used to be, it's just popping up in a new
place.
Fredderic
| |
| Neil Madden 2006-01-24, 7:05 pm |
| Uwe Klein wrote:
> Darren New wrote:
> nothing really, on occasion i found that i had an abundace of vars
> to carry with me. I hate procs with 10 args.
You could pass a single compound data structure (e.g. a dict, array, or
some sort of object). Encapsulation etc.
-- Neil
| |
| Andreas Leitgeb 2006-01-24, 7:05 pm |
| Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
> Uwe Klein wrote:
[color=darkred]
> That was indeed what I was proposing. And it admits *very* efficient
> implementation, though I'm not sure I like that it uses an exception
> code in the first place. Those things leak.
What, exactly, is leaking with exceptions?
| |
| Don Porter 2006-01-24, 9:58 pm |
| Donal K. Fellows wrote:
> ... Given that, the TIP does
> not specify a standard constructor command, sticking instead to the
> details of mechanisms for evaluating it (and which is namespaced nicely
> so it shouldn't hit anyone's code).
We've backed away from that and TIP 194 will propose an [::apply]
command when the vote starts (should be tomorrow).
Half-baked plans to propose [::tcl::apply] instead foundered when it
became apparent that blazing that trail had more work and more
precedent-setting creativity required than anyone wanted to take on as
part of this proposal.
In other command name collision news, though, note that TIP 248 (already
approved) includes a Great Renaming for Tk: [::button] -> [::tk::button]
for example, with existence of [::button] preserved via [namespace import].
Perhaps if that goes well, and can serve as an example, we can come
back and at least do the same for the "new in 8.5" commands like
[::dict], [::lassign], [::apply], etc.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|_______________________________________
_______________________________|
| |
| Donal K. Fellows 2006-01-25, 4:12 am |
| Andreas Leitgeb wrote:
> What, exactly, is leaking with exceptions?
Tcl does not try very hard to stop exception codes "leaking" from one
context to another; after all, that's usually what you want and is
indeed necessary in some circumstances. But it does mean that when we
introduce a new code, we have to consider what happens when things are
used in unexpected situations (e.g. what happens if someone makes the
"magic jump" command an inter-interpreter alias for the purposes of some
kind of debugging?)
On the other hand, I'm not sure we need *any* of this elaborate-ness at
all. Matt Newman's comments on simplicity sound very persuasive to me.
Donal.
| |
| Donal K. Fellows 2006-01-25, 4:12 am |
| Don Porter wrote:
> In other command name collision news, though, note that TIP 248 (already
> approved) includes a Great Renaming for Tk: [::button] -> [::tk::button]
> for example, with existence of [::button] preserved via [namespace import].
>
> Perhaps if that goes well, and can serve as an example, we can come
> back and at least do the same for the "new in 8.5" commands like
> [::dict], [::lassign], [::apply], etc.
I'd be tempted to say that all Tcl core commands should exist in the
::tcl namespace and be imported from there. But only if it doesn't
hammer our performance. With Tk that's not an issue, since Tk isn't
byte-compiled and isn't ever going to be; command dispatch is nowhere on
the map compared with the costs of creating and drawing a complex GUI.
Donal.
| |
| Andreas Leitgeb 2006-01-25, 7:57 am |
| Don Porter <dgp@email.nist.gov> wrote:
> In other command name collision news, though, note that TIP 248 (already
> approved) includes a Great Renaming for Tk: [::button] -> [::tk::button]
> for example, with existence of [::button] preserved via [namespace import].
> Perhaps if that goes well, and can serve as an example, we can come
> back and at least do the same for the "new in 8.5" commands like
> [::dict], [::lassign], [::apply], etc.
In what way would a namespace-imported ::tcl::apply be even
distinguishable from a direct ::apply ? (well, leaving aside
the existence of ::tcl::apply of course)
| |
| Andreas Leitgeb 2006-01-25, 7:57 am |
| Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
> Andreas Leitgeb wrote:
> Tcl does not try very hard to stop exception codes "leaking" from one
> context to another; after all, that's usually what you want and is
> indeed necessary in some circumstances. But it does mean that when we
> introduce a new code, we have to consider what happens when things are
> used in unexpected situations (e.g. what happens if someone makes the
> "magic jump" command an inter-interpreter alias for the purposes of some
> kind of debugging?)
I'd guess that not more happens, as when you call "break", "continue"
or "return -level $n -code $m ..." through the same means.
> On the other hand, I'm not sure we need *any* of this elaborate-ness at
> all. Matt Newman's comments on simplicity sound very persuasive to me.
You mean where says that he doesn't mean to stop all evolution of tcl ?-)
Btw., a new exception can't be all that new, can it?
| |
| Donal K. Fellows 2006-01-25, 7:15 pm |
| Andreas Leitgeb wrote:
> I'd guess that not more happens, as when you call "break", "continue"
> or "return -level $n -code $m ..." through the same means.
They're messy too. ;-)
Donal.
|
|
|
|
|