tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

Hi,
> % string match ARITH* [list ARITH MATRIX]
> 1
> % string match ARITH* [list ARITH MATRIX \{]
> 1
> % string match ARITH* [list ARITH MATRIX \}]
> 1
> % string match ARITH* {ARITH MATRIX \}}
> 1
>   
I believe the point was:
% string match ARITH* [list "ARITH MATRIX" foo bar]
0
> of nested sublists very easily (or at all). Twylite has convinced me 
> that glob matching is sufficient for 80+% of basic cases for [try]. 
>   
Great :)  But please don't take that to mean that I am convinced myself ;/

Twylite

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

I think it's time for a summary of where we are on the try/catch/finally.

The overall intent of the TIP can be summed up as "make a control 
structure that makes dealing with exceptions, errors and resource 
cleanup simpler - both logically and visually".

1. Functionality

We want to
(a) Handle return codes, so that we can build control structures and 
handle exceptions that use return codes.  In most cases an exact match 
against a single integer (or magic name) is sufficient.
(b) Handle matching against -errorCode in the case of the return code 
TCL_ERROR (1), so that we can have something similar to other languages 
with typed exception handling.  In most cases a prefix match, or glob 
match, or element-wise glob match on a list is sufficient.
(aside) Any argument about the ugliness of handling return codes with 
catch+if/then or catch+switch applies equally to handing errors & 
-errorCode, and vice versa.  As a result this TIP must provide for both 
(a) and (b), although it is not necessarily a requirement that they are 
provided for in the same command.
(c) Handle on those exceptions/errors that are of interest (can be 
handled at this point) and let others propagate normally.
(d) Handle success continuation, i.e. branch when there is no 
error/exception.  This is not generally supported by procedural 
languages but the requirement has been expressed by several developers 
and TCT members.
(e) Handle cleanup at the end of a block of code by means of a "finally" 
handler (regardless of errors/exceptions).
(f) Have reasonable performance, at least for the common cases.
(g) Discourage the use of the result for determining the nature of the 
error (an in doing so encourage the use of -errorCode).  At the very 
least this means not having default support for matching on the result.
(h) For exceptions thrown from handlers and finally blocks, maintain the 
details of the original exception (i.e. chain exceptions in the options 
dict).

2. Look & Feel

(a) It's going to be called [try]
(b) Handlers are identified by keywords.  The keyword "catch" has been 
argued against (confusion with existing language feature/keyword), as 
has "except" (ambiguous - "with exception" or "except for").  Likely 
candidates are "on" and "handle".
(c) A [try] statement is going to look more like an "if {} then {} else 
{}" than a "switch { case {body} case {body} }".  The former seems to be 
preferred by everyone involved in the discussions.
(d) Capture of variables (return code, result and options dict) needs to 
happen at the front of the [try] for the statement as a whole, rather 
than per handler.  This avoids confusion over which vars will be defined 
after the [try] returns, and also avoids variable churn if the 
errorPattern to be matched can access the variables.  Although some 
amount of locality is lost, this also makes the syntax cleaner (less 
repeated "noise").
(e) A [switch]-like "fall through to next statement" would be a 
nice-to-have.

3. Matching

(a) In general the matching of exceptions (return code) and errors 
(errorCode where the return code is TCL_ERROR) are separate concerns.  
It makes sense to exploit this by using a fast/exact match against the 
return code first (meeting the performance requirement) followed by a 
slower match against the errorCode.
(b) When matching against errorCode:
  (i) There is (largely) consensus that basic pattern matching is "good 
enough" "for now".  Basic pattern matching may be defined as prefix 
matching, glob matching against errorCode (as a string), or an 
element-wise list-glob match against errorCode (as a list).  In short 
there is no agreement on the right way to do this. 
  (ii) There is also no guarantee that a match against errorCode will be 
adequate in the future.  For example an OO-style error object may be 
developed.
  (iii) An [expr]-type match is the most flexible but the lowest 
performance (and potentially ugliest syntax); as such it is not suitable 
(at least not as a default).
  (iv) Delegating to [switch] for matching is a nice compromise of 
performance and flexibility (and reuses existing functionality), but 
brings with it the baggage of the [switch] command's interface.
(c) The only thing we _can_ be sure of is that whatever we choose now 
will be inadequate in some what, implying that the syntax of [try] must 
contain provision for future extension.
(d) Taking (c) to its logical conclusion, [try] must be specified and 
implemented to support user-selectable pattern matching.  It is possible 
to have the matcher selected for the [try] as a whole, or per handler, 
and there are pros and cons to each approach.

In terms of (d) my personal preference is to specify the matcher per 
handler.  It is difficult to predict how different packages/libraries 
may approach error handling, both now and in the future (e.g. a future 
move from -errorCode to an OO-style error object).  If the matcher is 
selected for the [try] as a whole it may only be possible to support 
disparate error handling styles by using the most flexible and complex 
matcher (say [expr]-based), which could be an unnecessary complication.  
The same holds now for integrating with legacy code that only produces 
meaningful error information in the result.

4. General

These are weakly-expressed requirements or requirements of my own.

(a) There is a general desire for consistency / symmetry in the syntax.  
This would obviously improve the readability & understandability of the 
source code.
(b) The behaviour of the [try] should be predictable and conform to the 
principle of least surprise.  On particular consequence of this is that 
matchers must consider handlers/errorPatterns in left-to-right order, 
and  all handlers should be executed in the same fashion (implying that 
the [try] rather than the matcher should execute the handler body).  On 
the issue of ordering, left-to-right is the only order than makes sense 
for [expr]-based matching, and is the norm in other languages.

5. Proposal

Based on this summary of the discussions so far, this is my current 
proposal:

  try tryscript ?as {vars}? ?handler ...? ?finally finalscript?
    where handler is
  on code ?-matcher pattern? handlerscript
    and
  handlerscript may be "-" to fall through to the next handlerscript

The tryscript is executed and the outcome (return code, result, options 
dict) is captured into vars.  A fast match (possibly a dict lookup) is 
performed to find the handler(s) for that code.  If there is an 
unqualified handler (one with no matcher) or a single handler for the 
code, then it is executed; otherwise each handler is considered in turn 
(left-to-right order) by calling the associated matcher, and the first 
matching handler is executed.  If no matching handler is found then the 
exception is propagated.

The implementation will probably provide the following handlers by 
default (users can implement their own):
  - -like for glob matching against errorCode as a string (perhaps -glob?)
  - -llike for element-wise list-glob matching against errorCode as a list
  - -expr for expr-based matching (with access to return code, result & 
options dict)

Example of use:

  try {
    # do stuff
  } as {code em opts} on ok {
    # do more
  } on break - on continue {
    # special handing for break & continue
  } on error -like "POSIX *" {
    # handle POSIX errors
  } on error -expr { $em in {BAD FOO BAR} } {
    # support legacy errors
  } finally {
    # cleanup
  }

Concerns:
- How to handle "all other errors" (-like * would work, is that good 
enough?)
- No handlerscript may begin with a "-".
- No feedback yet on "as {vars}" and the order of the vars
- If there are multiple handlers and one is unqualified, should it be 
executed first or last?

Alternatives:
- The body "-" is reserved to indicate fallthrough to the next body.  
The body "+" could be reserved to indicate that a matcher and pattern 
follow.
e.g.
  on error + like "POSIX *" { ... }

I feel that this proposal meets the requirements with the greatest 
flexibility and the least ambiguity.  But of course that's my opinion.

Regards,
Twylite

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Neil M. <ne...@Cs...>]

Andreas Leitgeb wrote:
> On Sun, Nov 23, 2008 at 01:16:15AM +0000, Neil Madden wrote:
>> I believe I proposed a "--" didn't I?
> I just meant that the "--" should even then be kept, if all other
> options were deferred for later (if at all)
> 
>>> [ {POSIX *} ] somehow does strike me as odd, [...as...], we
>>> are *supposed* to use a string operation (pattern-matching)
>>> on a list ($errorCode).
>>> Perhaps this pattern should be itself taken as a list, and then
>>> glob-matched element-wise (to the length of the pattern).
>> This is exactly the purpose of -matchcommand.
> 
> But my point was, that a list-aware matching should happen by 
> default, such that most of the cases it works correctly, even 
> without implementing and installing a custom matcher.
> 
> If usage of errorCode catches on (as a hoped-for result of the
> new try-command), then sooner or later someone will define
> sub-types like "ARITH MATRIX" and wonder, why ARITH* doesn't
> match both ARITH and "ARITH MATRIX".
> It of course doesn't match the latter, because that actually
> looks like "{ARITH MATRIX} ..." thus would need an optional
> open brace be matched as well (How to do that with globs?)
> And then it may even look like "ARITH\ MATRIX ..." sometimes,
> namely if some later element of the errorCode happens to 
> contain an unpaired brace. 

% string match ARITH* [list ARITH MATRIX]
1
% string match ARITH* [list ARITH MATRIX \{]
1
% string match ARITH* [list ARITH MATRIX \}]
1
% string match ARITH* {ARITH MATRIX \}}
1

It works fine. It would fail on [list [list ARITH MATRIX]]. The only 
problem is that it is only capable of recognising very simple regular 
languages, whereas list syntax is context-free so you can't match parts 
of nested sublists very easily (or at all). Twylite has convinced me 
that glob matching is sufficient for 80+% of basic cases for [try]. 
There is no general list-pattern syntax in Tcl at the moment, so doing 
something more would require a much expanded scope for the TIP. List 
pattern matching is much more tricky due to the requirement to know what 
the expected types of elements are (so you can reliably distinguish 
sub-lists from strings and so on).

[...]
> Introducing a list-string mixup directly in the core 
> is a very bad move, imho.

I think it's fine in this case. No errors can arise because of it. We 
are not constructing or extracting lists here, just a simple match. We 
don't have to worry about balanced braces or quoting issues.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

Hi,
>>> The [try] command for matching on something other than the return
>>> code is excellent.  Especially if it can match on return values as
>>> well as errorcodes.  How about this for a twist on the idea...
>>>   try {
>>>     script
>>>   } catch {
>>>     var ?opts?
>>>   } then {
>>>     script
>>>   } handler .....and so on.....
>>>       
>> This fits with extending [catch], e.g.
>>   catch { ... } em opts then { ... } handler {...}
>> The feedback I've had so far on this approach has not been
>> favorable. It seems that developers would prefer to keep the
>> args/vars in the context of the handler body.
>>     
> Hmmm.....  Fair enough.  My reasoning is this:
>
> - Restricts and confuses the arguments to the individual handlers.
> They're obvious, mostly redundant, and get in the way of other more
> useful potentially optional arguments.
>
> - What happens if each handler specifies a different set of variables.
> Which ones will be defined when the code block completes?  Or are they
> only defined within the context of the handler being invoked?  It's
> confusing.
>
> Having them specified up front makes it obvious that they're set within
> the current scope, and hence will be available both to the invoked
> handler and to code following the [try] block.
>   
Looking at the recent "pluggable matcher/handler" proposals it is 
becoming clear that the vars must be defined before the "errorPattern" 
is evaluated - in the case of an [expr] type handler the errorPattern 
may be an expression that involves the return code, result and options, 
so they must be brought into scope before the pattern is checked.

Your second point (what is defined when a block completes) is also a 
good one - I was wondering about this last night.  Having the vars from 
all handlers defined would be unexpected (and in most cases a lot of 
extra work); having vars from only the executed handler would mean a lot 
of pulling vars into & out of scope until the right handler is found, 
and then potential for errors in the code following the [try] as it 
dereferences the wrong variable name.

Taken together these are a strong argument in favour of defining the 
vars up front.

An unfortunate consequence of this is that handlers become harder to reuse.
>>> Regardless, why not have the handler clause evaluate an expression
>>> in the context of a [dict with $opts]?  Then you can use whatever
>>> matching function you wish, the only minor pain is that you have to
>>> use some ugly bracketing of the option names { ${-code} == 2 }.
>>> But maybe there's a way around that, too, especially if the [dict
>>> with] is doable read-only and non-destructively somehow.
>>>       
A little more on this one: accessing the return options in the [expr] 
would be painful, because it requires using [dict].  It would be fairly 
trivial to implement mathfuncs for code(), errorcode() and opts(-what) 
that would do the right thing.
>> Not that I'm aware of, no.  My current thinking is that it will be 
>> outside the brackets, e.g.
>>   handle code/expr {?resultvar? ?optionsvar?} { body }
>>     
> That would be _much_ preferable.  I do think, though, that being able
> to glob-match on a returned value is a requirement to being worth the
> effort.  Otherwise you'll have a bunch of branches each with an
> embedded [switch] and it's going to look worse, be less useful, and
> probably less efficient, than what I've sometimes done:
>   
As several people have pointed out on this list, matching against the 
return value is something we want to discourage.  It would be possible 
via an [expr]-type handler, but I don't think it should be supported by 
the default (probably glob-type) handler.
> One possible thought; a "return" (pending a better name) handler that
> matches the return value, and leaving that off from the "on" handler.
> So...
>
>     HANDLE errorcode-pattern {...}
>     RETURN returnvalue-pattern {...}
>     ON return-code {...}
>
> might be better, on the basis that most of the return codes don't allow
> you to specify a return value without producing them directly through
> [return].  Further on that, the return-code could optionally be a list
> of two words with the return value pattern being the second, which
> would allow the "on" form to handle it transparently without the
> "return" form at all.
>   
I'm in favour of pluggable matchers _per handler_, which would allow you 
to do this sort of thing (but possibly not with the default handlers).
e.g.
  try {
    # stuff
  } on error -like "POSIX *" {
  } on error -withresult "foo*" {
  }

You can define the "withreturn" matcher to do whatever you want (in this 
case a glob match against the result)
>> One advantage of having the vars with the handler script is that it 
>> allows you to reuse handlers.  e.g.
>>   set GENERAL_IO_HANDLER {{em opts} { log "Problem: $em" }}
>>   ...
>>   try {
>>     # some IO routine
>>   } handle error * {*}$GENERAL_IO_HANDLER
>> And in this case its no coincidence that the GENERAL_IO_HANDLER looks 
>> like an anonymous function that can be used with [apply]
>>     
> I don't see any advantage to that at all.  The handler won't be
> compiled or anything of the kind any more than it would be without the
> vars, and special magic is still going to need to be added to allow it
> to efficiently be re-used with [apply] or [eval] or what-not.
>   
Code reuse.  If you have a cross-cutting strategy (over several 
packages/components in an application or library) for handling a 
particular type of error (say IO errors), you can abstract that into a 
code snippet that looks like an anon proc.  You can only do this if the 
proc knows the names of the variables its going to deal with, hence the 
advantage of having the vars and body adjacent. 

The alternative is to call a proc, but it is slightly less convenient:

  try {
    # some IO routine
  } on error {*}$GENERAL_IO_ERROR_MATCH { do_general_io_error $code $em 
$opts }

Besides being slightly more verbose, the pattern constant and the proc 
are no longer closely associated in code.

Anyway, I don't think this is a particularly important bit of 
functionality -- it would be nice to have, but there are stronger 
arguments for having the vars at the front of the [try].

Regards,
Twylite

[TCLCORE] Tk + mingw + gdb breakpoint issues

[Alexandre F. <ale...@gm...>]

Hi,

I'm having trouble debugging Tk with gdb under mingw (XP SP2).
Basically any breakpoint in tk86.dll is ignored. Tcl86.dll is fine.
I suspect some mess in object-source mapping with relative paths, because

 (1) Function lookup by name in Tk wrongly ends up in Tcl:

   br Tk_CanvasEventuallyRedraw
    Breakpoint 2 at 0x10056644: file ./../generic/tclCompile.c, line 2185.

 (2) Manual breakpoints (with emacs gdb mode), though they seem to
point to the proper source location, are ignored:

    Breakpoint 3 at 0x1005863d: file ./../generic/tkCanvas.c, line 4465.

Any such experience ?

-Alex

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

On Sun, Nov 23, 2008 at 01:16:15AM +0000, Neil Madden wrote:
> I believe I proposed a "--" didn't I?
I just meant that the "--" should even then be kept, if all other
options were deferred for later (if at all)

>> [ {POSIX *} ] somehow does strike me as odd, [...as...], we
>> are *supposed* to use a string operation (pattern-matching)
>> on a list ($errorCode).
>> Perhaps this pattern should be itself taken as a list, and then
>> glob-matched element-wise (to the length of the pattern).
> 
> This is exactly the purpose of -matchcommand.

But my point was, that a list-aware matching should happen by 
default, such that most of the cases it works correctly, even 
without implementing and installing a custom matcher.

If usage of errorCode catches on (as a hoped-for result of the
new try-command), then sooner or later someone will define
sub-types like "ARITH MATRIX" and wonder, why ARITH* doesn't
match both ARITH and "ARITH MATRIX".
It of course doesn't match the latter, because that actually
looks like "{ARITH MATRIX} ..." thus would need an optional
open brace be matched as well (How to do that with globs?)
And then it may even look like "ARITH\ MATRIX ..." sometimes,
namely if some later element of the errorCode happens to 
contain an unpaired brace. 

> glob as default (as [switch] already provides it),
But [switch] is not designed for list-matching.

> and leave freedom to plug in your own scheme.
My point is, that for correct programs, everyone
would not only have to specify, but even implement 
his own list-matcher.

Introducing a list-string mixup directly in the core 
is a very bad move, imho.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Magentus <mag...@gm...>]

On Sat, 22 Nov 2008 15:05:53 +0200, 
Twylite <tw...@cr...> wrote:

> Hi,
>> From: Magentus <mag...@gm...>
>> The [finally script] usage is trivial to implement using unset
>> traces (although not quite as clean, mostly since it uses a magic
>> variable name).
> This works for [proc] and [apply], but is not completely reliable.  
> There is no guarantee that the magic finally variable will be the
> last to be unset, so a script like 'finally [list close $f]' is safe
> but 'finally { close $f }' may not behave as expected.

Granted.  Which is why I generally attach it to the variable holding
the channel descriptor, and always use the [list ...] form.  The
statement still stands, as usual, with some caveats.


> Also [try] is not a separate scope for variables, so it would have to 
> have a special interaction with the magic finally variable such that 
> [finally] scripts added inside the context of [try] are executed at
> the end of the [try].

No arguments that it's a bad way of adding finally scripts to [try].  I
was responding the to idea of a [finally] command in general.  As said,
it's a nice idea, but trivial to implement (add: with care), and not
useful enough to worry about at this time.  My apologies if the extra
comments didn't make that clear.

In short, I do think that a proper [finally] command would be handy,
the one I offered can optionally be bound to a specific variable which
makes it a lot safer; I was just saying it's not necessary.  Easier
persistent local storage for a [proc] would be handy too (and sort of
achieved with continuations, although they're still much more fiddly
than necessary).


> Example:
>   proc dostuff {} {
>     set f [open {c:/boot.ini} r]
>     trace add variable --finally--trap-- unset [list apply [list args
> { close $f ; puts done }]]
>   }
>   dostuff
>   chan names ;# -> stdout stderr filed27ae8 stdin

As you said, a bad way of doing it.  I tend to use [list] for ANYTHING
that's going to be deferred, unless I absolutely have it.  Avoids a
whole lot of such problems.


>   proc dostuff {} {
>     set f [open {c:/boot.ini} r]
>     trace add variable --finally--trap-- unset [list apply [list args 
> [list close $f]]]
>   }
>   dostuff
>   chan names ;# -> stdout stderr stdin

Certainly the way I'd do it.  Mind you, I wouldn't waste an [apply] on
a hard-coded script like that; unless some of the core wizards here can
think of a reason why it's a good thing.  (Which I would be most
interested in hearing.)


>> The [try] command for matching on something other than the return
>> code is excellent.  Especially if it can match on return values as
>> well as errorcodes.  How about this for a twist on the idea...
>>
>>   try {
>>     script
>>   } catch {
>>     var ?opts?
>>   } then {
>>     script
>>   } handler .....and so on.....
>>   
> This fits with extending [catch], e.g.
>   catch { ... } em opts then { ... } handler {...}
> The feedback I've had so far on this approach has not been
> favorable. It seems that developers would prefer to keep the
> args/vars in the context of the handler body.

Hmmm.....  Fair enough.  My reasoning is this:

- Restricts and confuses the arguments to the individual handlers.
They're obvious, mostly redundant, and get in the way of other more
useful potentially optional arguments.

- What happens if each handler specifies a different set of variables.
Which ones will be defined when the code block completes?  Or are they
only defined within the context of the handler being invoked?  It's
confusing.

Having them specified up front makes it obvious that they're set within
the current scope, and hence will be available both to the invoked
handler and to code following the [try] block.


>> Regardless, why not have the handler clause evaluate an expression
>> in the context of a [dict with $opts]?  Then you can use whatever
>> matching function you wish, the only minor pain is that you have to
>> use some ugly bracketing of the option names { ${-code} == 2 }.
>> But maybe there's a way around that, too, especially if the [dict
>> with] is doable read-only and non-destructively somehow.
> In a word, performance.  I have been having conversations with other
> Tcl developers off-list, and proposed exactly this.  It is
> unquestionably the most flexible option, but it forces a sequential
> consideration of each handler's expression, preventing any sort of
> heuristic to improve the performance of the construct.  Since one of
> the uses of this [try] will be to build other language constructs,
> performance is something that deserves reasonable consideration.
> The tradeoff may be to have "pluggable handler matching" where some 
> handlers can use exact matching ( O(1) time), some can use glob, some 
> can use expr, etc.  Doing this in a manner that maintains a simple 
> syntax is quite difficult however.

This is pretty much exactly what I expected, and why I was thinking
that adding it later, to the standard already-specified
most-common-cases forms, would be optimal.

The simple on and handle cases are fast and efficient, and need only
support basic [glob] matching against the return and errorcode values
respectively.  (A list-wise glob match would probably be useful, in a
few places.)  The expr-based matching is then reserved for making curly
cases readable, able to perform and/or conditionals as well as
extraction with [regexp] and every other form of matching known to
TCL-kind.


>> And finally for over-all syntax, what'd be wrong with tagging the
>> try clauses onto the end of the present [catch] command.  Make the
>> options variable mandatory in this usage, and bring it into scope
>> for the evaluations as above.
> See above.  I'm not necessarily against it, but it doesn't seem to be
> a popular option.

Yeah.  I kind of got that myself.  Just seems like a bit of duplication
to me.  Nevermind.


>>>    handle {code ?resultVar ?optionsVar??} { script }
>> Is there any actual practical use to putting code in the braces?
> Not that I'm aware of, no.  My current thinking is that it will be 
> outside the brackets, e.g.
>   handle code/expr {?resultvar? ?optionsvar?} { body }

That would be _much_ preferable.  I do think, though, that being able
to glob-match on a returned value is a requirement to being worth the
effort.  Otherwise you'll have a bunch of branches each with an
embedded [switch] and it's going to look worse, be less useful, and
probably less efficient, than what I've sometimes done:

    switch -glob -- [catch {...} foo],$foo

hence my personal preference to moving the variables up top, and having
the syntax:

    HANDLE errorcode-pattern {...}
    ON return-code returnvalue-pattern {...}

One possible thought; a "return" (pending a better name) handler that
matches the return value, and leaving that off from the "on" handler.
So...

    HANDLE errorcode-pattern {...}
    RETURN returnvalue-pattern {...}
    ON return-code {...}

might be better, on the basis that most of the return codes don't allow
you to specify a return value without producing them directly through
[return].  Further on that, the return-code could optionally be a list
of two words with the return value pattern being the second, which
would allow the "on" form to handle it transparently without the
"return" form at all.


>> Something like a:
>>     withvars {resultVar ?optionsVar?}
>> following the main try script indicating where to stash the
>> variables. 
> One advantage of having the vars with the handler script is that it 
> allows you to reuse handlers.  e.g.
>   set GENERAL_IO_HANDLER {{em opts} { log "Problem: $em" }}
>   ...
>   try {
>     # some IO routine
>   } handle error * {*}$GENERAL_IO_HANDLER
> And in this case its no coincidence that the GENERAL_IO_HANDLER looks 
> like an anonymous function that can be used with [apply]

I don't see any advantage to that at all.  The handler won't be
compiled or anything of the kind any more than it would be without the
vars, and special magic is still going to need to be added to allow it
to efficiently be re-used with [apply] or [eval] or what-not.


>> For the blending with [if] option, there was chatter a while back
>> about fast [expr]-local variables intended mostly to hold partial
>> results during an expression; the main terms of the options dict
>> could quite readily be pre-loaded as [expr]-local variables.
> I'm very interesting in the idea of extending [expr] in various ways, 
> especially to make pattern matching easier and somehow bind the error 
> options as variables into the expr.  It's just not going to happen by
> 10 December, so we can't use any approach that relies on it.

Absolutely.  Again, that's why I suggested having the [expr]-based
method in addition to basic glob-matched "handler" and "on code"
forms.  Almost every place where I'd use the [try] structure, fall into
one of two catagories;

    try {
      ... open a file and do stuff ...
    } finally {
      ... close the file ...
    }

and

    try {
      ... do some stuff that might error ...
    } handle "error BLAH:*" {
      ... handle error blah ...
    } handle "error FOO:*" {
      ... handle error foo ...
    } on break * {
      ... handle the aborted case ...
    } on ok "* *" {
      ... handle two or more word return ...
    } on ok "" {
      ... handle empty return ...
    } on ok * {
      ... handle single-word or empty return ...
    }

Without the [expr]-based match that's a little uglier than needed, but
still marginally better than the usual catch+switch method.  The
pluggable handlers might let me do a [proc args] style match, which
would be very useful for several other places as well as here (eg.
useful continuations), but this would suffice for every use case I can
think of.  The "return" form or option-second-word of the "on" forms
code argument, would make that just a little bit neater...


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 45 days, 22:33)

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Neil M. <ne...@Cs...>]

On 23 Nov 2008, at 01:01, Andreas Leitgeb wrote:
> Neil Madden <ne...@Cs...> wrote:
>>      try ?-matchcommand cmd? script ?handlers ...? ?finally script?
>
> I don't like that particular option, and I think that glob-like
> matching will be enough for some time, but I would see for "--"
> as an options delimiter before the body (even though no options
> are yet defined) just in case we later notice that we do need any.

I believe I proposed a "--" didn't I?

>
>>  ... {POSIX *} ...
>
> While I find this most practicable, it somehow does strike me as
> odd, that in this particular case, we are *supposed* to use a
> string operation (pattern-matching) on a list ($errorCode).
>
> Perhaps this pattern should be itself taken as a list, and then
> glob-matched element-wise (to the length of the pattern).

This is exactly the purpose of -matchcommand. I'd rather not have to  
come up with an entirely new pattern syntax for lists (matching  
nested sub-lists etc). KISS -- glob as default (as [switch] already  
provides it), and leave freedom to plug in your own scheme.

> That way {POSIX *} would exhibit the same behaviour as is expected,
> but it would be easier to safely match the third element of the
> list, without being trapped by list-string meta-characters.

Lists are strings, so there should be no problem using glob. The only  
problem is if you want to do something more sophisticated, like {FOO  
{BAR *} JIM *}

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Neil M. <ne...@Cs...>]

On 22 Nov 2008, at 23:42, Twylite wrote:
> Hi,
>> try ?-matchcommand cmd? script ?handlers ...? ?finally script?
>>
>> Where -matchcommand is the command to use to do errorCode matching
>> and defaults to {switch -glob --}. (May need a -- marker to eliminate
>> ambiguity). The syntax of the handlers part would be:
>>
>> on exception-types ?vars? ?errorPattern? body ?errorPattern
>> body ...?
> I'm very uncomfortable with this syntax.  It is potentially ambiguous
> and feels very DWIMy (in a bad way).
>
> try {
>   # do stuff
> } on error {
>   puts hello
> } finally {
>   puts goodbye
> }
>
> ... is ambiguous.  It could be interpreted the way you think, or with
> "puts hello" as the vars and "finally" as the error pattern.
>
> Consider also:
> try { ... } on error {em opts} "POSIX *" { body } on break
>
> Is "on break" an errorPattern and body, or the start of a new  
> exception
> handler?

I don't think it's possible to avoid ambiguity while still preserving  
ease of use. The alternative is to make less things optional, which  
just becomes a pain. My preference is to make "on" a keyword in this  
context. It's highly unlikely that a script or a variable would just  
be named "on", and if we document this as a keyword in this context  
then there should be no problem.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

Neil Madden <ne...@Cs...> wrote:
>      try ?-matchcommand cmd? script ?handlers ...? ?finally script?

I don't like that particular option, and I think that glob-like
matching will be enough for some time, but I would see for "--"
as an options delimiter before the body (even though no options
are yet defined) just in case we later notice that we do need any.

>  ... {POSIX *} ...

While I find this most practicable, it somehow does strike me as
odd, that in this particular case, we are *supposed* to use a
string operation (pattern-matching) on a list ($errorCode).

Perhaps this pattern should be itself taken as a list, and then
glob-matched element-wise (to the length of the pattern).

That way {POSIX *} would exhibit the same behaviour as is expected,
but it would be easier to safely match the third element of the
list, without being trapped by list-string meta-characters.

Re: [TCLCORE] CFV on small high-prio TIPs

[Donal K. F. <don...@ma...>]

Joe Mistachkin wrote:
> It is being changed; however, I did not realize it was going to 
> be voted on today.
> 
> The TIP cannot be changed while it is being voted on?

Not through the online mechanism; it requires editorial access at this
stage.

> Anyhow, it will read:

That change has now been applied. Please will all who have already voted
on this TIP check whether the revised change affects their vote. (For
me, it doesn't. ;-))

Donal.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

Hi,
> try ?-matchcommand cmd? script ?handlers ...? ?finally script?
>
> Where -matchcommand is the command to use to do errorCode matching
> and defaults to {switch -glob --}. (May need a -- marker to eliminate
> ambiguity). The syntax of the handlers part would be:
>
> on exception-types ?vars? ?errorPattern? body ?errorPattern
> body ...?
I'm very uncomfortable with this syntax.  It is potentially ambiguous 
and feels very DWIMy (in a bad way).

try {
  # do stuff
} on error {
  puts hello
} finally {
  puts goodbye
}

... is ambiguous.  It could be interpreted the way you think, or with 
"puts hello" as the vars and "finally" as the error pattern.

Consider also:
try { ... } on error {em opts} "POSIX *" { body } on break

Is "on break" an errorPattern and body, or the start of a new exception 
handler?

One can construct other ambiguities that exploit the inability to 
distinguish between a pattern for a pluggable matcher (i.e. you can't 
make assumtions about what is and isn't a valid input) and the keywords 
of the [try] itself.

Regards,
Twylite

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Neil M. <ne...@Cs...>]

On 22 Nov 2008, at 03:49, Magentus wrote:
> On Thu, 20 Nov 2008 10:39:26 -0800,
> Joe English <jen...@fl...> wrote:
>
>>     handle {code ?resultVar ?optionsVar??} { script }
>
> Is there any actual practical use to putting code in the braces?  The
> variables, I don't think can be avoided in this style, although I'm  
> not
> sure that there is a need to have every single branch specify the
> variables individually.  I'd much prefer to have them specified  
> once at
> the top (and optionally at that) rather than repeated monotonously on
> every single branch.....

Agreed on both counts.

> [...]
> Supporting all the different types of match, though, would be a "Good
> Thing".  -glob, -nocase, -exact, -prefix, -regexp, and so forth...
> That's why I think the next part is worth giving a second thought.

If these are supported it should be only by explicit delegation to  
[switch], rather than making all these options part of the interface  
of [try] too.

I proposed the following interface offline to Twylite (slightly  
altered) yesterday:

     try ?-matchcommand cmd? script ?handlers ...? ?finally script?

Where -matchcommand is the command to use to do errorCode matching  
and defaults to {switch -glob --}. (May need a -- marker to eliminate  
ambiguity). The syntax of the handlers part would be:

     on exception-types ?vars? ?errorPattern? body ?errorPattern  
body ...?

Where exception-types is a list of one or more of "ok", "error",  
"return", "break", "continue" or an integer return code. errorPattern  
is a pattern (specific to the -matchcommand) used to match against  
the -errorcode (if any). ?vars? is a list of var names {?resultVar ? 
optsVar??} and finally "body" is a script. If you want to specify the  
errorPattern you must also specify the vars, to avoid ambiguity. If  
you want to specify multiple patterns, then the first errorPattern is  
mandatory. The try command then builds a lookup table mapping return  
code -> (ordered) dict of patterns/scripts. It does a simple lookup  
based on the return code of the initial script and then passes the  
errorCode and dict of patterns to the -matchcommand, i.e. it would  
become [switch -glob -- $errorCode $handlers]. If there is no  
errorCode (e.g. a non-error exception) then the empty string is  
passed. A "default" branch is also added to the end of the handlers  
which just rethrows the exception, or if a branch with no pattern is  
specified then this becomes the default branch. The body of a handler  
can be "-", with the same meaning as in [switch]. To be concrete, the  
syntax would look something like:

     try {
         ...
     } on error {msg opts} {IO *} - {POSIX *} {
         ...
     } {ARITH *} {
         ...
     } on {break continue} {
         ...
     } finally {
         ...
     }

You could also write those "on error" clauses as:

     } on error {msg opts} {IO *} - {POSIX *} {
        ...
     } on error {msg opts} {ARITH *} {
        ...
     }

Or any combination of the styles you prefer (the former allows you to  
specify the vars once, the latter may be more readable). The core  
dispatch then becomes something like:

     set rc [catch { $script } msg opts]
     invoke 1 {*}$matchcmd [dict get $opts -errorcode] [dict get  
$handlers $rc]

As before, "then" could be taken as sugar for "on ok", and some catch- 
all "else/otherwise" could be added.

It seems to me that this covers most (all?) use-cases, while still  
keeping [try] relatively minimal and efficient. In particular, [try]  
avoids acquiring the interface of any particular pattern matching  
construct. It can also support various types of matching (e.g. I can  
use algebraic types, OO enthusiasts can use sub-class matching, and  
others can use arbitrary expressions). The core [try] command only  
needs to implement basic return-code based matching, which is O(1),  
so remains efficient for those implementing control structures over  
the top of this. Examples of customisation:

   interp alias {} datatry {} try -matchcommand {datatype match}
   interp alias {} regtry  {} try -matchcommand {switch -regexp - 
nocase --}
   interp alias {} exptry  {} try -matchcommand expmatch
   proc expmatch {code cases} {
       foreach {case body} $cases {
           if {$case eq "default" || [expr $case]} { return [uplevel  
1 $body] }
       }
   }
   exptry { ... } on error {msg opts} {[lindex $code 2] > 1000} { ... }

Thoughts? I'm sure the syntax may need some jiggling to get order of  
things optimal and to eliminate any remaining ambiguities.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [TCLCORE] CFV on small high-prio TIPs

[miguel s. <mig...@gm...>]

Donal K. Fellows wrote:
> This is a Call For Votes on the following "small and practical" TIPs
> that I identified from my message earlier this week. (The other ones are
> in the process of being baked more.)
> 
>   TIP #171: Change Default <MouseWheel> Bindings Behavior
>   TIP #197: Text Widget Persistant Cursor
>   TIP #210: Add 'tempname' Subcommand to 'file'
>   TIP #238: Fire Event when Widget Created
>   TIP #284: New 'invoke' and 'namespace invoke' Commands
>   TIP #306: Auto-Naming Widgets
>   TIP #307: Make TclTransferResult() Public
>   TIP #335: An API for Detecting Active Interpreters
>   TIP #336: Supported Access To interp->errorline
>   TIP #337: Make TclBackgroundException() Public
>   TIP #338: Embedder Access to Startup Scripts of *_Main()
> 
> Please send your votes to the tcl-core mailing list by 12:00 GMT next
> Friday (i.e. [clock format 1227873600]). My votes follow:

My votes:

TIP #171: PRESENT
TIP #197: PRESENT
TIP #210: YES
TIP #238: YES
TIP #284: YES
TIP #306: YES
TIP #307: YES
TIP #335: NO [*]
TIP #336: YES
TIP #337: YES
TIP #338: YES


A note on TIP 335: I definitely do not like exposing numLevels, and vote for 
rejection. Joe Mistachkin has stated in this thread that he wanted to change the 
proposal (I guess as a result of our discussions?), and I find the alternative 
very convenient. So my vote should be read as

TIP #335: NO  for the version in the TIP DB
           YES for Joe's less intrusive alternative

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

Hi,
> From: Magentus <mag...@gm...>
>
> The [finally script] usage is trivial to implement using unset traces
> (although not quite as clean, mostly since it uses a magic variable
> name).
>   
This works for [proc] and [apply], but is not completely reliable.  
There is no guarantee that the magic finally variable will be the last 
to be unset, so a script like 'finally [list close $f]' is safe but 
'finally { close $f }' may not behave as expected.
Also [try] is not a separate scope for variables, so it would have to 
have a special interaction with the magic finally variable such that 
[finally] scripts added inside the context of [try] are executed at the 
end of the [try].

Example:

  proc dostuff {} {
    set f [open {c:/boot.ini} r]
    trace add variable --finally--trap-- unset [list apply [list args { 
close $f ; puts done }]]
  }
  dostuff
  chan names ;# -> stdout stderr filed27ae8 stdin

  proc dostuff {} {
    set f [open {c:/boot.ini} r]
    trace add variable --finally--trap-- unset [list apply [list args 
[list close $f]]]
  }
  dostuff
  chan names ;# -> stdout stderr stdin

> The [try] command for matching on something other than the return code
> is excellent.  Especially if it can match on return values as well as
> errorcodes.  How about this for a twist on the idea...
>
>   try {
>     script
>   } catch {
>     var ?opts?
>   } then {
>     script
>   } handler .....and so on.....
>   
This fits with extending [catch], e.g.

  catch { ... } em opts then { ... } handler {...}

The feedback I've had so far on this approach has not been favorable.  
It seems that developers would prefer to keep the args/vars in the 
context of the handler body.
> Regardless, why not have the handler clause evaluate an expression in
> the context of a [dict with $opts]?  Then you can use whatever matching
> function you wish, the only minor pain is that you have to use some
> ugly bracketing of the option names { ${-code} == 2 }.  But maybe
> there's a way around that, too, especially if the [dict with] is
> doable read-only and non-destructively somehow.
>   
In a word, performance.  I have been having conversations with other Tcl 
developers off-list, and proposed exactly this.  It is unquestionably 
the most flexible option, but it forces a sequential consideration of 
each handler's expression, preventing any sort of heuristic to improve 
the performance of the construct.  Since one of the uses of this [try] 
will be to build other language constructs, performance is something 
that deserves reasonable consideration.
The tradeoff may be to have "pluggable handler matching" where some 
handlers can use exact matching ( O(1) time), some can use glob, some 
can use expr, etc.  Doing this in a manner that maintains a simple 
syntax is quite difficult however.
> And finally for over-all syntax, what'd be wrong with tagging the
> try clauses onto the end of the present [catch] command.  Make the
> options variable mandatory in this usage, and bring it into scope for
> the evaluations as above.
>   
See above.  I'm not necessarily against it, but it doesn't seem to be a 
popular option.
>> >     handle {code ?resultVar ?optionsVar??} { script }
>>     
> Is there any actual practical use to putting code in the braces?
Not that I'm aware of, no.  My current thinking is that it will be 
outside the brackets, e.g.
  handle code/expr {?resultvar? ?optionsvar?} { body }
> Something like a:
>     withvars {resultVar ?optionsVar?}
> following the main try script indicating where to stash the variables.
>   
One advantage of having the vars with the handler script is that it 
allows you to reuse handlers.  e.g.
  set GENERAL_IO_HANDLER {{em opts} { log "Problem: $em" }}
  ...
  try {
    # some IO routine
  } handle error * {*}$GENERAL_IO_HANDLER

And in this case its no coincidence that the GENERAL_IO_HANDLER looks 
like an anonymous function that can be used with [apply]
> For the blending with [if] option, there was chatter a while back about
> fast [expr]-local variables intended mostly to hold partial results
> during an expression; the main terms of the options dict could quite
> readily be pre-loaded as [expr]-local variables.
I'm very interesting in the idea of extending [expr] in various ways, 
especially to make pattern matching easier and somehow bind the error 
options as variables into the expr.  It's just not going to happen by 10 
December, so we can't use any approach that relies on it.

Regards,
Twylite

[TCLCORE] CFV TIP #340

[Jan N. <nij...@us...>]

This is a Call For Votes on TIP #340.

 TIP #340: CONST Qualification of Tcl_SetResult's argument and -Wwrite-strings

Please send your votes to the tcl-core mailing list by
Monday dec 1st, 12:00 GMT (i.e. [clock format 1228132800]).
My vote follows:

 TIP #340: YES

Regards,
       Jan Nijtmans

Re: [TCLCORE] CFV on small high-prio TIPs

[Joe E. <jen...@fl...>]

Joe Mistachkin wrote:

> [Re: TIP #335: An API for Detecting Active Interpreters]
> > [I wrote]
> > I thought this was going to be amended [...]
> It is being changed; however, I did not realize it was going to
> be voted on today.
> The TIP cannot be changed while it is being voted on?
>
> Anyhow, it will read:
> ~ Specification
> This TIP introduces a single function to Tcl's public API:
>  > int '''Tcl_InterpActive'''(Tcl_Interp *''interp'')
> The '''Tcl_InterpActive''' function returns non-zero if the interpreter is
> in use.


That's better.

The TIP has not as of yet (r1.5) been updated
to reflect the above, but on the assumption
that it will be soon:

TIP#335 revision 1.5: NO.
TIP#335 revision 1.6: YES.


--Joe English

  jen...@fl...

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Magentus <mag...@gm...>]

On Thu, 20 Nov 2008 10:39:26 -0800, 
Joe English <jen...@fl...> wrote:

>     handle {code ?resultVar ?optionsVar??} { script }

Is there any actual practical use to putting code in the braces?  The
variables, I don't think can be avoided in this style, although I'm not
sure that there is a need to have every single branch specify the
variables individually.  I'd much prefer to have them specified once at
the top (and optionally at that) rather than repeated monotonously on
every single branch.....

Something like a:
    withvars {resultVar ?optionsVar?}
following the main try script indicating where to stash the variables.
(I did mention that in my last post that hasn't yet been passed through)

Although personally I'd prefer a -vars option to [try], despite the
obvious issue of not being allowed to have a command called -vars that
_takes no arguments_.  Is anyone seriously going to try and insist
that that's a big issue?!?  If it's a variable name, then fine, it's a
very realistic problem, but what static script is going to non-obviously
conflict (the main use-case), and for passed in scripts through
variables, just use the -- guard option.  From using [switch], it's
common to put -- before variables anyhow.  I know a "Better Way" would
be preferably, but it's the least ugly and most practical so far.


In any case, a nice clean simple layout seems to be:
    handle pattern {...}
where the return code is TCL_ERROR and pattern is glob matched against
errorcode.
    on code pattern {...}
now pattern matches against the return value, even if code is
TCL_ERROR.  More usefully, it'll gracefully handle applications which
have multiple kinds of success, as well as multiple kinds of error,
and can handle both regular bare [error] returns and the use of
errorcode with equal ease.

Supporting all the different types of match, though, would be a "Good
Thing".  -glob, -nocase, -exact, -prefix, -regexp, and so forth...
That's why I think the next part is worth giving a second thought.


For the blending with [if] option, there was chatter a while back about
fast [expr]-local variables intended mostly to hold partial results
during an expression; the main terms of the options dict could quite
readily be pre-loaded as [expr]-local variables.

A little care might be needed to avoid shadowing the variable you wish
to use to hold the value to compare, but that should be doable.
Perhaps [expr]-local variables should use a %syntax synonymous with the
regular $syntax for variables to avoid name clashes (and highlight
the fact that they're [expr]-local).

All this could further be put off by implementing it as a separate
[try] term later, for when extended matching is needed. Then you've got
"handle" and "on" for just about everything, and "when" or even "if"
for anything else.  (Imagine an ambiguous case among more readily
matchable cases, that would otherwise force you to break the [try] into
a much less easy to read chunk of code.)


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 44 days, 21:32)

Re: [TCLCORE] The Remaining "Big Plan" TIPs... (TIP#162 ipv6)

[David G. <dav...@po...>]

Donal K. Fellows wrote:
> Jeff Hobbs wrote:
>> I have a working patch for this that Pat has vetted.  I will try and 
>> squeeze out some time this weekend to update the patch (tkchat consensus 
>> was to use -family instead of -type for inet4|inet6) against the head(s).
> 
> It's not clear to me why that's needed. Couldn't I just use -myaddr to
> force the issue if I cared and Let Tcl Do The Right Thing the rest of
> the time?

It goes something like this...  A lookup for a site such as
"www.kame.org" might return both an inet4 and an inet6 address.  The v6
planning docs say to to use the v6 when available, but sometimes you
might want to force v4, just cause.  And addresses like ::192.68.12.14
are really v6 in disguise, but you might not want the outgoing on a v6
socket.  -family forces the hints to getaddrinfo() so you get the result
you want.

Re: [TCLCORE] The Remaining "Big Plan" TIPs... (TIP#162 ipv6)

[Donal K. F. <don...@ma...>]

Jeff Hobbs wrote:
> I have a working patch for this that Pat has vetted.  I will try and 
> squeeze out some time this weekend to update the patch (tkchat consensus 
> was to use -family instead of -type for inet4|inet6) against the head(s).

It's not clear to me why that's needed. Couldn't I just use -myaddr to
force the issue if I cared and Let Tcl Do The Right Thing the rest of
the time?

Donal.

Re: [TCLCORE] The Remaining "Big Plan" TIPs... (TIP#162 ipv6)

[Stuart C. <stu...@sy...>]

David Gravereaux wrote:
> Jeff Hobbs wrote:
> 
>> I have a working patch for this that Pat has vetted.  I will try and 
>> squeeze out some time this weekend to update the patch (tkchat consensus 
>> was to use -family instead of -type for inet4|inet6) against the head(s).
> 
> That fits well with socket()'s af, type, and protocol params quite
> nicely.  I like it.  A good basis to grow from.
> 

The name of the first parameter to socket(2) is 'domain'.
I can't say I remember a consensus, and this really is a pittance but 
I'll throw in my CDN $0.02 here and say I prefer -domain -type and 
-protocol for the simple reason that they follow the names used for 
socket(2).
One could argue that those aren't the greatest names and certainly come 
up with better ones but I think it's good to have consistency across as 
wide a swath of environments as possible.

Re: [TCLCORE] The Remaining "Big Plan" TIPs... (TIP#162 ipv6)

[David G. <dav...@po...>]

Jeff Hobbs wrote:

> I have a working patch for this that Pat has vetted.  I will try and 
> squeeze out some time this weekend to update the patch (tkchat consensus 
> was to use -family instead of -type for inet4|inet6) against the head(s).

That fits well with socket()'s af, type, and protocol params quite
nicely.  I like it.  A good basis to grow from.

Re: [TCLCORE] The Remaining "Big Plan" TIPs... (TIP#162 ipv6)

[Jeff H. <je...@ac...>]

Donal K. Fellows wrote:
>    TIP#162: IPv6 Sockets for Tcl
	...
> For example, #162 (IPv6) is really not about the sort of major
> re-engineering that David Gravereaux envisages, as that would take much
> more work than we have time to do *even with an implementation ready for
> one platform*. Given that, getting IPv6 support is actually the issue
> before us and that's what I plan to call that TIP on. (Yes, a generic
> plugin architecture for socket types would be neat, as would fixing the
> blocking-resolver bug. But they're not this TIP.)

I have a working patch for this that Pat has vetted.  I will try and 
squeeze out some time this weekend to update the patch (tkchat consensus 
was to use -family instead of -type for inet4|inet6) against the head(s).

Jeff

[TCLCORE] The Remaining "Big Plan" TIPs...

[Donal K. F. <don...@ma...>]

Apart from the TIP vote currently running (if there are adjustments to
those TIPs to be done during the vote, send me what you think should
change) these are the things that I'm eyeing to do as part of the 8.6
feature set.

   TIP#162: IPv6 Sockets for Tcl
   TIP#180: Add a Megawidget Support Core Package
   TIP#234: Add Support For Zlib Compression
   TIP#244: PNG Photo Image Support for Tk
   TIP#281: Improvements in System Error Handling
   TIP#329: Try/Catch/Finally syntax

Now, for the constraints/notes. The big constraint is time: we want to
close the window on new features in early December so that we have time
to push the implementation into a fit state for an 8.6.0 release in the
(northern hemisphere) Spring. This means that some projects are going to
be necessarily much smaller than some people think.

For example, #162 (IPv6) is really not about the sort of major
re-engineering that David Gravereaux envisages, as that would take much
more work than we have time to do *even with an implementation ready for
one platform*. Given that, getting IPv6 support is actually the issue
before us and that's what I plan to call that TIP on. (Yes, a generic
plugin architecture for socket types would be neat, as would fixing the
blocking-resolver bug. But they're not this TIP.)

It's possible that #180 will be purely scripted, maybe not in Tk at all.
It certainly needs quite a bit of work to revise once I work out (with
Damon?) what is actually not already trivial. (TclOO changes the whole
equation quite a bit...) Do not be surprised if this slips and goes into
tklib instead.

TIP#234 has suffered badly from the bikeshed effect. For myself, I want
this sufficiently strongly that I'd be happy to eliminate chunks of the
Tcl API (we can do them in the future after all) and do just those parts
that we can be sure of. That then enables TIP#244, which is important
for Tk.

I'm inclined to characterize TIP#281 as more of an approval for what I
expect will be an ongoing programme to improve the error handling on
(especially) Windows. It's not clear to what extent we should make a new
API to support this yet; maybe in 8.6 it is sufficient to keep the added
functions internal for later exposure.

And finally, I'd like to see TIP#329 go in. Right now, doing stuff with
[catch], [switch], etc. is sufficiently messy and ugly that people
don't. This results in code that is not as robust. Yes, [try] adds
nothing that you can't do now. I expect the first version to be scripted
(though I hope to be able to produce a C version before 8.6.0). But the
key is that it much more strongly encourages people to do the right
thing with error handling (and hence error creation too). Doing the
other exception cases is purely a bonus from my perspective. (It does
benefit rather from #281...)

In order that we may run an orderly vote within our own deadline, the
"Big Ticket CFV" will probably be next Friday. If you want to argue
about the APIs in these TIPs, *please* get it over with before then! We
can't/won't wait for you to resolve some minor point!

Donal.

Re: [TCLCORE] CFV on small high-prio TIPs

[Joe M. <jo...@mi...>]

>> TIP #335: An API for Detecting Active Interpreters
> 
> I thought this was going to be amended to specify
> Tcl_IsInterpActive() instead of Tcl_GetNumLevels().
> The title of the TIP changed, but not the specification?
> 

It is being changed; however, I did not realize it was going to 
be voted on today.

The TIP cannot be changed while it is being voted on?

Anyhow, it will read:

~ Specification

This TIP introduces a single function to Tcl's public API:

 > int '''Tcl_InterpActive'''(Tcl_Interp *''interp'')

The '''Tcl_InterpActive''' function returns non-zero if the interpreter is
in use.

~ Reference Implementation

|/*
| *----------------------------------------------------------------------
| *
| * Tcl_InterpActive --
| *
| *	Returns non-zero if the specified interpreter is in use.
| *
| * Results:
| *	See above.
| *
| * Side effects:
| *	None.
| *
| *----------------------------------------------------------------------
| */
|
|int
|Tcl_InterpActive(Tcl_Interp *interp)
|{
|    return (((Interp *) interp)->numLevels > 0);
|}

--
Joe Mistachkin <jo...@mi...>