tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

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

On 2 Nov 2006, at 23:12, Miguel Sofer wrote:
>  TIP #293: ARGUMENT EXPANSION WITH LEADING {*}
> ===============================================

Still digesting this, but one point leaps out at me:
...
>
>     2. The usage of both *{expand}* and *{}* will be deprecated.
>        However, both idioms will remain enabled as alternatives.
...

What does "remain enabled" mean in relation to {}? Does this TIP also  
enable {} as expansion syntax in the 8.5+ line?

-- Neil

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

[<lm...@bi...>]

On Thu, Nov 02, 2006 at 04:48:40PM -0800, Will Duquette wrote:
> Very nice!  Thanks much.

So this takes

	{expand}whatever

and turns it into

	{*}whatever

right?  Seems better to me too.  They are both weird but such is life,
this seems better.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

[Brian G. <bgr...@mo...>]

Miguel Sofer wrote:
>  TIP #293: ARGUMENT EXPANSION WITH LEADING {*} 
> ===============================================
>  COMPATIBILITY 
> ===============
>
>  Note that removing *{expand}* and/or *{}* will break code that users 
>  might already have in production, and so cannot be done in an 8.* 
>  release. They will be removed in Tcl 9.0 though, so user code should 
>  not make use of them in order to ensure that future portability issues 
>  are minimized. 
>   

I'd like to see a build time option to remove the alpha compatibility.  
We don't currently use 8.5, but when we do, I know someone, somewhere 
will start using {expand} and I don't want to have to deal with this 
issue again when transitioning to 9.0.

Thanks,
-Brian

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

[Will D. <wi...@wj...>]

Very nice!  Thanks much.

Will

On Nov 2, 2006, at 3:34 PM, miguel sofer wrote:

> Miguel Sofer wrote:
>>  TIP #293: ARGUMENT EXPANSION WITH LEADING {*}
>> ===============================================
>>  Version:      $Revision: 1.1 $
>>  Author:       Miguel Sofer <msofer_at_users.sourceforge.net>
>>  State:        Accepted
>>  Type:         Project
>>  Tcl-Version:  8.5
>>  Vote:         Done
>>  Created:      Thursday, 02 November 2006
>>  URL:          http://purl.org/tcl/tip/293.html
>>  WebEdit:      http://purl.org/tcl/tip/edit/293
>>  Post-History:
>>  Obsoletes:    TIP #157
>>
>> --------------------------------------------------------------------- 
>> ----
>>
>>  ABSTRACT
>> ==========
>>
>>  Tcl shall use *{*}* to denote argument expansion, replacing the  
>> current
>>  *{expand}*.
>
> The voting has been conducted privately, this TIP has been accepted  
> 9/0
> with two abstentions. The voting record is
>
> YES:     MS, KBK, DRH, DGP, DKF, JH, JN, AKU, JE
> PRESENT: JI, MH
>
> Miguel
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

[miguel s. <mi...@ut...>]

Miguel Sofer wrote:
>  TIP #293: ARGUMENT EXPANSION WITH LEADING {*} 
> ===============================================
>  Version:      $Revision: 1.1 $
>  Author:       Miguel Sofer <msofer_at_users.sourceforge.net>
>  State:        Accepted
>  Type:         Project
>  Tcl-Version:  8.5
>  Vote:         Done
>  Created:      Thursday, 02 November 2006
>  URL:          http://purl.org/tcl/tip/293.html
>  WebEdit:      http://purl.org/tcl/tip/edit/293
>  Post-History: 
>  Obsoletes:    TIP #157
> 
> -------------------------------------------------------------------------
> 
>  ABSTRACT 
> ==========
> 
>  Tcl shall use *{*}* to denote argument expansion, replacing the current 
>  *{expand}*. 

The voting has been conducted privately, this TIP has been accepted 9/0 
with two abstentions. The voting record is

YES:     MS, KBK, DRH, DGP, DKF, JH, JN, AKU, JE
PRESENT: JI, MH

Miguel

Re: [TCLCORE] TIP #293: Argument Expansion with Leading {*}

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

Miguel Sofer wrote:
>  TIP #293: ARGUMENT EXPANSION WITH LEADING {*} 

I draw the attention of members of this list who are not members of the
TCT to the fact that this TIP has already been voted on and accepted (we
didn't want this lost in the noise of OO flaming!) The results of the
vote were as follows:

For: MS, KBK, DRH, DGP, DKF, JH, JN, AKU, JE
Against: nobody
Present: JI, MH

Donal.

[TCLCORE] TIP #293: Argument Expansion with Leading {*}

[Miguel S. <ms...@us...>]

 TIP #293: ARGUMENT EXPANSION WITH LEADING {*} 
===============================================
 Version:      $Revision: 1.1 $
 Author:       Miguel Sofer <msofer_at_users.sourceforge.net>
 State:        Accepted
 Type:         Project
 Tcl-Version:  8.5
 Vote:         Done
 Created:      Thursday, 02 November 2006
 URL:          http://purl.org/tcl/tip/293.html
 WebEdit:      http://purl.org/tcl/tip/edit/293
 Post-History: 
 Obsoletes:    TIP #157

-------------------------------------------------------------------------

 ABSTRACT 
==========

 Tcl shall use *{*}* to denote argument expansion, replacing the current 
 *{expand}*. 

 RATIONALE 
===========

 There seems to be a consensus that the functionality of *{expand}* is 
 exactly what was needed, but the syntax could be nicer. The problem, 
 both back in 2003 and today, is that there is no general agreement on 
 which is the best one. However, the issue of ugliness is regularly 
 revived in the mailing lists so it is not going away soon. Moreover, an 
 alpha release in a popular distribution allows the use of *{}* instead 
 of *{expand}*. 

 A compromise solution, *{*}*, is less verbose and "ugly" than 
 *{expand}*, and less prone to typographical errors than plain *{}*. It 
 is inspired using the mnemonic that the character "*" is already used 
 to denote "all items" in other contexts. 

 DETAILED PROPOSAL 
===================

 After two years experience with *{expand}*, this TIP proposes the 
 following amendment to [TIP #157]: 

    1. The officially sanctioned expansion syntax will henceforth be 
       *{*}*, in replacement of the previous *{expand}*. 

    2. The usage of both *{expand}* and *{}* will be deprecated. 
       However, both idioms will remain enabled as alternatives. 

    3. This is a syntax-only change. 

 COMPATIBILITY 
===============

 Note that removing *{expand}* and/or *{}* will break code that users 
 might already have in production, and so cannot be done in an 8.* 
 release. They will be removed in Tcl 9.0 though, so user code should 
 not make use of them in order to ensure that future portability issues 
 are minimized. 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] CFV: TIP 283

[miguel <ms...@us...>]

miguel wrote:
> As promised, here's the call for votes on
> 
> TIP #283: Modify Ensemble Command Resolution Behaviour

As both author and sponsor of the TIP, I would like to suspend the vote 
and withdraw the tip pending a clarification of the issues raised.

The patch was prepared and tested with the patch in [Bug 1577492], and 
submitted to a vote. That bugfix was later reverted for reasons 
independent of this TIP.

The adaptation of this TIP's implementation to function without that 
patch caused the [clock] auto initialisation to fail. That issue is easy 
enough to fix, but it worked as a canary. The failure has uncovered 
deeper issues that need to be thought about and resolved properly before 
considering this modification to the ensemble's resolution behaviour.

Should a withdrawal not be possible during a vote, I herewith change my 
vote to "NO". In any case, I expect to resubmit a similar TIP in the 
near future, in time for 8.5 consideration.

Please accept my apologies.

Miguel

Re: [TCLCORE] TIP #290: Registration of Custom Error Handler Scripts

[Eckhard L. <ec...@we...>]

Lars Hellstr=F6m schrieb:
> It still doesn't describe the ::tcl::seterrorhandler command very much=20
> (syntax, return value, etc.). Nor is there much said about the handler=20
> command itself (With which arguments is it called? Is there any way in=20
> which it can quell the error?)
>
> One would also want the bulleted list after "The changes in the=20
> execution engine should be done so that:" to be followed by an=20
> explanation of how you mean to meet these conditions. For example, it=20
> is stated that the ::errorInfo and ::errorCode variables are updated.=20
> Does this mean that e.g. any write traces on these variables would=20
> fire differently with the TIP mechanisms in place than without them?

I updated the specification again. Hope that these questions are=20
answered now...

> Is there meant to be any interaction with the event loop? Having a=20
> Tk-based debugger probably means running the event loop (probably via=20
> [vwait]), and as far as I can tell this error handling mechanism is=20
> then turned off. However, the rest of the application (channel events,=20
> GUI events, [after] scripts) would continue to run, and do so without=20
> the "protection" of an error handler. This could be considered=20
> undesirable.
Good point... I didn't consider the event loop so far.
It would mean to be able to trigger the error handler again in event=20
loop scripts (e.g. in "after" code) , if it runs already at the same=20
time. Currently it can be only run once at a time - if errors in the=20
same Interp are thrown during the handler runs, they are handled as=20
usual. This is however different from the behaviour in different threads=20
since there are other Interp's.

>> I thought about a [trace set errorcmd] or [trace add errorcmd].
>
> I'd go for [trace add error].
I'd rather go for [trace set error], because it's only one command.
[trace add error] could mean that the script is run in addition to the=20
usual implementation (which is not the case) or that there can be more=20
scripts registered.
Technically, this wouldn't be a problem, but it makes things more=20
complicated than necessary. In general, one custom handler is enough -=20
it's again up to the implementor of this handler to call other procedures=
.

>> Probably you're right regarding the interface to this from a Tcl'ers=20
>> point of view. But the internal execution mechanism is different...
>
> More different than an execution trace is from a variable trace?

The error handler is to be run whenever the return code of the current=20
command is TCL_ERROR. I think that is maybe simpler than the "execution=20
trace" mechanism...

>> No, if they are rethrown, a new error is generated which is not=20
>> considered to be caught (if not caught elsewhere above, of course).
>
> Yes, but the rethrowing of an error could take place very far from=20
> where it originally happened.=20

It doesn't matter where it is thrown or rethrown. As soon as it appears,=20
it is trapped (provided, the -uncaught flag is set). That's the whole=20
point of this TIP.

> With something like http://wiki.tcl.tk/using, you don't get the=20
> requested chance to debug errors that happen within the [using], since=20
> that command catches and rethrows errors.
That's a rather special case. Set the -caught flag to trap caught=20
errors. This can be done dynamically during program run from somewhere...



Eckhard

Re: [TCLCORE] CFV: TIP 283

[Donald G P. <dg...@ni...>]

Kevin Kenny wrote:
> (2) This is the only chance that we'll get to do it right;

Yes, which is why it is important to actually get it right.

> (3) The [info level] issue is very much a red herring.  The only code
>     broken by the change is [info level] within a procedure that is
>     a member of an ensemble.  

Ah, but there is no special command type known as "member of an 
ensemble".  A key feature of ensembles is that they can dispatch by name 
to any command at all, whether or not that command was initially 
designed for the purpose of being the target of an ensemble subcommand.

I think your analysis would be correct if ensemble subcommand targets
were something new, like the methods proposed by TIP 257, that could 
never be reached except via new features only in 8.5.  That's not the case.

As I understand the current state of TIP 283, it creates a new situation 
where a proc can no longer rely on prior assumptions about what [uplevel 
1 [info level 0]] will do.  That's worth either correcting, or embracing 
and declaring in huge bold letters in the proposal as an incompatibility.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] CFV: TIP 283

[<ke...@cr...>]

I'm not yet changing my YES vote on 283.

(1) The [info level] part of the change is backed out; resolution
    of the ensemble subcommand doesn't depend on it.

(2) This is the only chance that we'll get to do it right; once ensembles
    are out in a general release, we won't get to change their semantics
    without breaking script-level compatibility.

(3) The [info level] issue is very much a red herring.  The only code
    broken by the change is [info level] within a procedure that is
    a member of an ensemble.  That is to say, it's new code that's
    dependent on 8.5.  Pripr to the freeze for beta 1, we're supposed
    to be allowed to break new features.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [TCLCORE] CFV: TIP 283

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

Miguel wrote:
> As promised, here's the call for votes on
> TIP #283: Modify Ensemble Command Resolution Behaviour

TIP #283: NO.

[ I was going to vote PRESENT on this one, since I didn't
  understand the full ramifications.  I *still* don't understand
  the full ramifications, but it's starting to look like it's
  not such a great idea; it opens up a barrel of worms that's
  perhaps better left closed. ]


--Joe English

  jen...@fl...

Re: [TCLCORE] CFV: TIP 283

[Andreas K. <and...@ac...>]

> As promised, here's the call for votes on
>
> TIP #283: Modify Ensemble Command Resolution Behaviour
>
> This is something of "8.5 or never", it modifies the semantics before
> ensembles are officially released. Functionality of code that followed
> recommended practice (fully qualify everything) is unchanged.

TIP #283: NO

The ickyness and breakages regarding [info level 0] which were found with the
implementation after the vote started make me very uneasy to let this through
before this has been sorted.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [TCLCORE] TIP #292: Allow Unquoted Strings in Expressions

[Brian G. <bgr...@mo...>]

Donald G Porter wrote:
> Brian Griffin wrote:
>   
>>  Change the expression parser to accept unquoted words that are not 
>>  function names as strings. Modify /EqualityExpr/ to reject unqoted 
>>  strings for "*==*", but allow them for "*eq*". 
>>     
>
> There is no longer an "EqualityExpr" routine to modify.
>   

My mistake.  I glanced at 8.4 code instead of HEAD.  The point is to 
move the error check up a level in the parse tree.

-Brian

Re: [TCLCORE] TIP #292: Allow Unquoted Strings in Expressions

[Brian G. <bgr...@mo...>]

Larry McVoy wrote:
> On Thu, Nov 02, 2006 at 04:24:21PM +0000, dr...@hw... wrote:
>   
>> Brian Griffin <bgr...@mo...> wrote:
>>     
>>>  ABSTRACT 
>>> ==========
>>>
>>>  This TIP proposes allowing unquoted words to be recognized as strings 
>>>  in expressions (*expr*, *if*, *while*). 
>>>
>>>       
>> I would much prefer that unquoted words be recognized as variable
>> names.  The single most common mistake I make when programming
>> in TCL is to omit the $ before variable names in expr.
>>     

I would attribute this kind of mistake to "thinking in C" rather then a 
short coming of Tcl.  I also make the mistake of putting {} around if 
conditions in C, but I'm not going to petition the C standards body to 
accept {} in place of () because of my forgetfulness.


>
> I tend to agree.  And while we're there, is there really any need to
> preserve the fact that you can do
>
> 	set {silly variable name!} "some string"
>
> Wouldn't life be simpler if there was a 
>
> 	tcp configure c-variable-names true
>   

No, it wouldn't!  Again, Tcl is not C!

The point is that the current situation is inconsistent. 

    set foo ASTRING               ;# legal syntax
    set foo "ASTRING"           ;# legal syntax
    if {$foo eq "ASTRING"}  ;# legal syntax
    if {$foo eq ASTRING}     ;# illegal syntax!

This is odd and goes against the EIAS basis of Tcl.  Either accept 
unquoted string in expressions or require quotes everywhere else in 
Tcl.  A third option is to divorce expr from "if", "while", and "for" 
commands, replacing it with a more Tclish conditional expression evaluator.

-Brian

Re: [TCLCORE] TIP #292: Allow Unquoted Strings in Expressions

[<lm...@bi...>]

On Thu, Nov 02, 2006 at 04:24:21PM +0000, dr...@hw... wrote:
> Brian Griffin <bgr...@mo...> wrote:
> > 
> >  ABSTRACT 
> > ==========
> > 
> >  This TIP proposes allowing unquoted words to be recognized as strings 
> >  in expressions (*expr*, *if*, *while*). 
> > 
> 
> I would much prefer that unquoted words be recognized as variable
> names.  The single most common mistake I make when programming
> in TCL is to omit the $ before variable names in expr.

I tend to agree.  And while we're there, is there really any need to
preserve the fact that you can do

	set {silly variable name!} "some string"

Wouldn't life be simpler if there was a 

	tcp configure c-variable-names true

?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] TIP #292: Allow Unquoted Strings in Expressions

[<dr...@hw...>]

Brian Griffin <bgriffin=40model.com> wrote:
>=20
>  ABSTRACT=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
>  This TIP proposes allowing unquoted words to be recognized as strings=
=20
>  in expressions (*expr*, *if*, *while*).=20
>=20

I would much prefer that unquoted words be recognized as variable
names.  The single most common mistake I make when programming
in TCL is to omit the =24 before variable names in expr.

--
D. Richard Hipp  <drh=40hwaci.com>

Re: [TCLCORE] TIP #290: Registration of Custom Error Handler Scripts

[<Lar...@re...>]

2006-11-02 kl. 14.34 skrev Eckhard Lehmann:
>
>>
>>>  SPECIFICATION
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> [...]
>>
>> IMHO, this is not a specification, but rather a ChangeLog.
>
> I know.. sorry, I did'nt TIP before ;-). Its updated and hopefully=20
> better now.

It still doesn't describe the ::tcl::seterrorhandler command very much=20=

(syntax, return value, etc.). Nor is there much said about the handler=20=

command itself (With which arguments is it called? Is there any way in=20=

which it can quell the error?)

One would also want the bulleted list after "The changes in the=20
execution engine should be done so that:" to be followed by an=20
explanation of how you mean to meet these conditions. For example, it=20
is stated that the ::errorInfo and ::errorCode variables are updated.=20
Does this mean that e.g. any write traces on these variables would fire=20=

differently with the TIP mechanisms in place than without them?

Is there meant to be any interaction with the event loop? Having a=20
Tk-based debugger probably means running the event loop (probably via=20
[vwait]), and as far as I can tell this error handling mechanism is=20
then turned off. However, the rest of the application (channel events,=20=

GUI events, [after] scripts) would continue to run, and do so without=20
the "protection" of an error handler. This could be considered=20
undesirable.

>> Attempting to recreate a functionality description from the=20
>> information
>> given, it seems like these error handlers would be called immediately
>> when the error is thrown, just like e.g. a variable trace is called
>> immediately when that variable is accessed. In view of that, it might
>> perhaps be more appropriate to fully integrate this into the [trace]
>> command (especially since this would provide established mechanisms=20=

>> for
>> introspection and handler deletion).
>
> I thought about a [trace set errorcmd] or [trace add errorcmd].

I'd go for [trace add error].

> Probably you're right regarding the interface to this from a Tcl'ers=20=

> point of view. But the internal execution mechanism is different...

More different than an execution trace is from a variable trace?

>> (Even counting [catch]es could be handled using execution traces,
>> if one trusts the user not to rename the [catch] command.) Speed is =
of
>> course an issue, but if that is the main reason for this feature then
>> the TIP should say so.
>
> As for the [catch]'es - I don't know how to capture them in a=20
> leavestep trace.

No, a *leavestep* trace could be a bit roundabout. I'd do that bit by=20
putting *enter* and *leave* traces on [catch] that increment/decrement=20=

a variable.

> Its not obvious or easy, if possible at all. The speed issue is=20
> included in the TIP now.
>
>>
>> The distinction between caught and uncaught errors also seem a bit
>> hazy. Many errors are caught (by control structures and the like) =
just
>> to be rethrown, but it seems as the mechanism proposed here would
>> simply consider them to be caught.
>
> No, if they are rethrown, a new error is generated which is not=20
> considered to be caught (if not caught elsewhere above, of course).

Yes, but the rethrowing of an error could take place very far from=20
where it originally happened. With something like=20
http://wiki.tcl.tk/using, you don't get the requested chance to debug=20
errors that happen within the [using], since that command catches and=20
rethrows errors.

Lars Hellstr=F6m=

Re: [TCLCORE] TIP #292: Allow Unquoted Strings in Expressions

[Donald G P. <dg...@ni...>]

Brian Griffin wrote:
>  TIP #292: ALLOW UNQUOTED STRINGS IN EXPRESSIONS 
> =================================================

I think this is basically a good idea, though it must
be done carefully.  This topic came up in discussions
about TIP 282.  See those messages for some things to consider.

I'd be happier if the two TIPs were rolled into one.

>  Tcl-Version:  8.5

Just IMHO, getting this done for 8.5 is a fantasy.

>  Change the expression parser to accept unquoted words that are not 
>  function names as strings. Modify /EqualityExpr/ to reject unqoted 
>  strings for "*==*", but allow them for "*eq*". 

There is no longer an "EqualityExpr" routine to modify.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] =?iso-8859-15?q?TIP_=23290=3A_Registration_of_Custom_Er?= =?iso-8859-15?q?ror_Handler_Scripts?=

[Eckhard L. <ec...@we...>]

> -----Urspr=FCngliche Nachricht-----
> Von: Lars Hellstr=F6m <Lar...@re...>
> Gesendet: 01.11.06 21:10:29
> An: tcl...@li...
> Betreff: Re: [TCLCORE] TIP #290: Registration of Custom Error Handler Sc=
ripts


> 2006-11-01 kl. 15.02 skrev Eckhard Lehmann:
> >  This TIP proposes the possibility to register custom scripts or
> >  commands in the usual Tcl event handler style as error handlers.
>=20
> Does "event" here have anything to do with the event loop=3F

No, it has not. It's just the same "format" like commands for fileevent, w=
indow event and so on.

>=20
> >  SPECIFICATION
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> [...]
>=20
> IMHO, this is not a specification, but rather a ChangeLog.

I know.. sorry, I did'nt TIP before ;-). Its updated and hopefully better =
now.

> Attempting to recreate a functionality description from the information=20
> given, it seems like these error handlers would be called immediately=20
> when the error is thrown, just like e.g. a variable trace is called=20
> immediately when that variable is accessed. In view of that, it might=20
> perhaps be more appropriate to fully integrate this into the [trace]=20
> command (especially since this would provide established mechanisms for=20
> introspection and handler deletion).

I thought about a [trace set errorcmd] or [trace add errorcmd]. Probably y=
ou're right regarding the interface to this from a Tcl'ers point of view.=20
But the internal execution mechanism is different... it's not a "normal" t=
race, which runs when all the other traces are executed, but only when the=
re was an error. In fact, it is called after the command execution, if nec=
essary as determined by the catch level and -caught/-uncaught flags.

> Come to think of it, how much of this isn't already made possible by=20
> [trace add execution]=3F If you do [trace add execution main leavestep=20
> handler], where [main] is the main procedure of your program and=20
> [handler] is your designated error handler, then this handler will=20
> indeed be called whenever a command completes, and thus be given a=20
> chance to do something for those returns that have an error return=20
> code.=20

I made a section in the TIP explaining my experiences with that. Indeed I =
thought it could be solved this way, but it was somewhat tedious in practi=
ce...

> (Even counting [catch]es could be handled using execution traces,=20
> if one trusts the user not to rename the [catch] command.) Speed is of=20
> course an issue, but if that is the main reason for this feature then=20
> the TIP should say so.

As for the [catch]'es - I don't know how to capture them in a leavestep tr=
ace. Its not obvious or easy, if possible at all. The speed issue is inclu=
ded in the TIP now.

>=20
> The distinction between caught and uncaught errors also seem a bit=20
> hazy. Many errors are caught (by control structures and the like) just=20
> to be rethrown, but it seems as the mechanism proposed here would=20
> simply consider them to be caught.=20

No, if they are rethrown, a new error is generated which is not considered=
 to be caught (if not caught elsewhere above, of course).

> That is probably not what a user=20
> would expect, and a control structure implementor would want a=20
> mechanism for saying "this [catch] is not to count as catching errors".

The custom command can be run on either caught errors or uncaught errors, =
or both (depending on the -caught/-uncaught flags given to the registratio=
n command). Everything else is up to the implementor of the registered com=
mand (checking ::errorCode and ::errorInfo etc.). I think that is appropri=
ate...


Eckhard

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Viren-Scan f=FCr Ihren PC! Jetzt f=FCr jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/=3Fmc=3D022222

[TCLCORE] TIP #292: Allow Unquoted Strings in Expressions

[Brian G. <bgr...@mo...>]

 TIP #292: ALLOW UNQUOTED STRINGS IN EXPRESSIONS 
=================================================
 Version:      $Revision: 1.1 $
 Author:       Brian Griffin <bgriffin_at_model.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.5
 Vote:         Pending
 Created:      Wednesday, 01 November 2006
 URL:          http://purl.org/tcl/tip/292.html
 WebEdit:      http://purl.org/tcl/tip/edit/292
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 This TIP proposes allowing unquoted words to be recognized as strings 
 in expressions (*expr*, *if*, *while*). 

 RATIONALE 
===========

 Currently the following fails with a syntax error: 

       set foo bar
       expr {$foo eq bar}

 This seems antithetical to the EIAS Tao of Tcl. The *set* command does 
 not require the quotes, so why should *expr*, especially since the 
 operands of the *eq* and *ne* operators are treated as strings. It also 
 seems reasonable for the *==* and *!=* operators to reject unquoted 
 strings as not a valid operand. This provides some enforcement for 
 numerical vs. string comparison by forcing the use of quotes to convert 
 the numeric *==* to a string equality test. 

 The rationale for making such a change is it will make complex code a 
 bit easier to read. For example, I can: 

           set var ENUM_VALUE_ONE
   
           switch $var {
                   ENUM_VALUE_ZERO { ... }
                   ENUM_VALUE_ONE  { ... }
                   default { ... }
           }
   
           if {[lsearch $supplied_values ENUM_VALUE_ONE] >= 0} { ... }
   
           if {[string equals $var ENUM_VALUE_ONE]} { ... }

 but I must: 

           if {$var eq "ENUM_VALUE_ONE"} { ... }

 which could lead someone reading the code to incorrectly conclude that 
 ENUM_VALUE_ONE is not the same thing as "ENUM_VALUE_ONE" or miss the 
 fact that they are the same, especially when using a syntax 
 highlighting editor. 

 PROPOSED CHANGE 
=================

 Change the expression parser to accept unquoted words that are not 
 function names as strings. Modify /EqualityExpr/ to reject unqoted 
 strings for "*==*", but allow them for "*eq*". 

 DRAFT IMPLEMENTATION 
======================

 None, at the moment. 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

[Arjen M. <arj...@wl...>]

Steve Landers wrote:

> 
> ABSTRACT 
>==========
>
> This TIP proposes adding the *platform* package to the Tcl core sources 
> and to install it automatically, similar to what is currently done with 
> the *tcltest* package. 
>
>  
>
Will this package distinguish between Windows, Cygwin and MinGW/Msys?
These platforms are indistinguishable via  tcl_platform and sometimes you
really need to know which one you are at - for instance to invoke external
programs or to find out what other facilities are available.

(See: http://wiki.tcl.tk/1649)

Regards,

Arjen

Re: [TCLCORE] CFV: TIP 283

[<dg...@ni...>]

Quoting miguel <ms...@us...>:
> TIP #283: Modify Ensemble Command Resolution Behaviour

283: NO

While I welcome the attempt to address the issues
raised in Tcl Bug 1436096, this proposal solves those
issues by exposing TCL_EVAL_INVOKE style command
dispatch to scripts not really prepared for all that implies.
The attempts to finish the implementation patch have exposed
these problems.

We ought to be exploding/cleaning up/eliminating semi-magical
internals stuff like TCL_EVAL_INVOKE, not letting them loose
on script programmers.

A revised proposal that addressed the same problems but
in a cleaner way with more thorough testing I believe I could
support.  This just doesn't seem ready yet.  I'm not confident
we've even discovered all the potential difficulties yet.

DGP

Re: [TCLCORE] TIP #291: Add the 'platform' Package to Tcl

[Steve L. <st...@di...>]

On 02/11/2006, at 2:25 AM, Joe English wrote:

>
> Steve Landers wrote:
>>
>>  TIP #291: ADD THE 'PLATFORM' PACKAGE TO TCL
>> [...]
>>  This TIP proposes adding the *platform* package to the Tcl core  
>> sources
>>  and to install it automatically, similar to what is currently  
>> done with
>>  the *tcltest* package.
>
>
> This would be an excellent candidate for tcllib, but I don't
> believe it belongs in the core.
>
> Putting it in tcllib will make it available for all Tcl versions,
> not just 8.5a<mumble> and up.
>
> Porting Tcl to a new Unix-like platform is usually pretty easy --
> if the target is even vaguely POSIX-like, 'configure; make; make
> install' tends to Just Work.  However, devising a suitable set
> of heuristics for [platform::identify] and [platform::generic]
> requires a great deal of knowledge and experience about the
> target OS.  Consequently, [platform::identify] will need to
> evolve more quickly than the core release schedule will allow;
> putting it in tcllib instead of the core will make that easier.

Good points Joe, but I don't see this as an "either/or" situation.

I'm more than happy for platform to go into tcllib and evolve  
quicker, but strong believe that it needs to go into the core as  
well, so developers can rely on it being present.

Remember that the TIP authors are at the pointy-end of delivery multi- 
platform distributions and extensions - and only too aware of the  
problems that entails.

Steve

Re: [TCLCORE] TIP #290: Registration of Custom Error Handler Scripts

[Eckhard L. <ec...@we...>]

Robert Seeger schrieb:
> The spec is a little vague on a number of issues. Specifically, the 
> ones that I've had bite me in the past for other types of APIs are:
Ok, I should update the Specification and state more clearly how these 
issues are solved.
> * There doesn't appear to be a way to find out what the current 
> registered error handler is.
With the current patch, call [tcl::seterrorhandler] withoud arguments. 
This gives you what is registered currently.
> * There doesn't appear to be a way to unregister an error handler or, 
> to look at it another way, to set the error handler back to the default
Again with the current patch, call [tcl::seterrorhandler {}] to 
unregister any previously set handler.

I am not sure whether [tcl::seterrorhandler] is the right place/command 
to register the custom handler... (but this is for sure the easiest 
thing to change). If someone has a better idea, please let me know.


Eckhard