tcl-core Mailing List for Tcl

>
>  ACKNOWLEDGEMENTS
> ==================
>
>  This TIP is dedicated to Alexandre Ferrieux, who's known to have
>  written that I should prioritize TIPping things over participating in
>  tcl-core discussions. ;-)

:D

Though I don't remember wording it exactly that way, I don't regret
it, that TIP is a good synthesis !
Congrats,

-Alex

  TIP #387: UNIFIED YIELD COMMAND SYNTAX
========================================
  Version:      $Revision: 1.3 $
  Author:       Lars Hellström <Lars.Hellstrom_at_residenset.net>
  State:        Draft
  Type:         Project
  Tcl-Version:  8.6
  Vote:         Pending
  Created:      Monday, 30 May 2011
  URL:          http://www.tcl.tk/cgi-bin/tct/tip/387.html
  Post-History:

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

  ABSTRACT
==========

  This document describes the /syntax/ of a unified *yield* command,
  which is designed so that it can combine all features of the various
  yield-related commands proposed during 2010.

  NOTE
------

  This should not be taken as a proposal to necessarily provide all the
  mentioned features right now, but rather as a roadmap to make a command
  into which they /could/ all be fitted. The purpose is to avoid choosing
  a direction that would get really awkward in the future.

  GENERAL CONSIDERATIONS
========================

  It is accepted as given that the present syntax of the *yield* command,
  namely

        *yield* ?/value/?

  should continue to be valid. It is also desirable to control all
  additional features through options placed before the /value/, since
  that makes it possible to let an *interp alias* supply them.

  What is important given those constraints is that one must be able to
  determine whether the final argument is a /value/ or not solely from
  looking at the previous arguments, since any option name is also a
  perfectly valid /value/ for *yield* to return to the coroutine-caller.
  This can be accomplished through the rule that every option must
  consist of at least two words (typically -name and value); a word after
  an option is then known to be the /value/ if it is the very last word
  of the command, and known to be the first word of another option if it
  not the very last word of the command. (By contrast, an attempt to get
  by with a *--* end-of-options option would become very complicated and
  error-prone.)

  The overall command syntax would thus be similar to that of *return*
  (options before an optional value), although there is no need to
  reproduce any of return's options in *yield*, as all such functionality
  can be attained by yielding to *return*.

  POSSIBLE OPTIONS
==================

  We identify the following options: *-arguments*, *-delivery* and *-to*.
  These are described below:

  ARGUMENT SPECIFIERS
---------------------

  The option

        *-arguments* /argspec/

  would be used to specify a *proc*-style list of arguments for the
  coroutine-command. As mentioned in [TIP #372], *yieldm* can then be
  defined as:

       interp alias {} yieldm {} yield -arguments args

  whereas the default for *-arguments* is *{arg ""}*, as:

       yield -arguments {{arg ""}}

  explicitly says the coroutine-command should have one optional argument
  /arg/ with default value the empty string.

  The idea is that if the arguments supplied to the coroutine-command do
  not match the /argspec/, then the coroutine-command should throw an
  appropriate error rather than resuming the coroutine. In that case, the
  coroutine state does not change, and in particular the
  coroutine-command continues to use the same /argspec/.

  For the purpose of further discussion below, the elements in the
  /argspec/ list will be called *formal parameters* of the
  coroutine-command.

  YIELDING TO
-------------

  The *-to* option provides the functionality of the *yieldto* command,
  and has the syntax:

        *-to* /cmdname/ ?/arg .../?

  always absorbing all remaining arguments of the *yield* command; a
  precedent for this may be found in for example the *-join* option of
  the *glob* command. In order to meet the "at least two words"
  requirement for *yield* options, the /cmdname/ argument is mandatory,
  but this is quite natural since it is anyway to be resolved already by
  *yield*.

  Note that behavior like yielding and throwing an error can be performed
  by yielding to *return*:

       yield -to return -code error -errorcode DEMO "Just an example"

  *-code* and *-errorcode* here are not options of *yield*, but of
  *return*, although the impression is probably close to that of having
  them options of *yield* directly.

  ARGUMENT DELIVERY
-------------------

  An issue where no obvious solution presented itself was that of how
  arguments supplied to the coroutine-command should be made available in
  the coroutine. This proposal suggest that a *-delivery* option could be
  used to control this, and that the word after *-delivery* is a /mode/
  keyword which selects whether the arguments should be provided as a
  list, a dictionary, in variables, or whatever. The following is a list
  of possible forms of this option.

  The supported modes will be one of: *dict*, *first*, *flat*, *same* and
  *vars*. These are described below. (Note that different modes need not
  have the same number of argument words.)

  DICTIONARY DELIVERY

        *-delivery dict*

  The return value of *yield* is a dictionary, with one entry for each
  formal parameter, the entries appearing in the same order as in the
  *-arguments* /argspec/, and the values filled in as they would be for a
  *proc* call. The latter implies that /default values are filled in for
  missing optional arguments/; this preserves the invariant for the
  caller that specifying the default value for an optional argument is
  the same as omitting that argument.

  Thus, for the demonstration code:

     proc demo {delivery} {
        set last ""
        foreach argspec {
           foo {{arg ""}} {{arg ""}} args {foo args}
        } {
           set last [yield -arguments $argspec -delivery $delivery $last]
        }
        return $last
     }

  one can get this interactive session:

     % coroutine C demo dict
     % C "a b"
     foo {a b}
     % C "a b"
     arg {a b}
     % C
     arg {}
     % C "a b"
     args {{a b}}
     % C "a b"
     foo {a b} args {}

  FLAT DELIVERY

  It is not unreasonable to also expect a mode that delivers just the
  list of formal parameter values, e.g.

        *-delivery list*

  but this can be obtained from

       dict values [yield -delivery dict ...]

  since the *dict* mode is specified as putting the entries in the right
  order.

  Instead there is another take on returning a list of arguments that
  provides extra functionality:

        *-delivery flat*

  The return value of *yield* is the list of arguments of the
  coroutine-command, regardless of *-arguments* /argspec/. This is the
  *yield* counterpart of *info level 0*, providing full introspection
  into the arguments, but also leaving parsing entirely up to the
  programmer.

  With the same sequence of calls as above, one gets

     % coroutine C demo flat
     % C "a b"
     {a b}
     % C "a b"
     {a b}
     % C
     % C "a b"
     {a b}
     % C "a b"
     {a b}

  DELIVERY TO LOCAL VARIABLES

        *-delivery vars* /varlist/

  The /varlist/ must be a list with one element for each formal
  parameter. The values of the formal parameters are assigned, in
  sequence, to the variables named in the /varlist/. The return value is
  an empty string.

  Of course, most of the time one would use the same names as in the
  /argspec/, so it is reasonable to have a shorthand for this:

        *-delivery same*

  The main reason to do otherwise is if both the procedure *yield*ing and
  the coroutine-command has an *args* argument, since that is a magical
  name. Hiding implementation details from users can also be a reason to
  specify a different /varlist/.

  A further possibility that has been suggested would be:

        *-delivery array* /arrname/

  for dumping the arguments as entries in an array. This can however be
  accomplished through

     array set $arrname [yield -delivery dict ...]

  which is probably easy enough.

  SIMPLE DELIVERY

  Finally, there is:

        *-delivery first*

  The return value is the value of the first formal parameter, or an
  empty string if there are no formal parameters; values of additional
  formal parameters are discarded. /This is the default./

  This may seem a strange mode of delivery, and an even stranger thing to
  have as default, but it is what one must have if the [TIP #372]
  examples of varying the /argspec/ should work as claimed there. With
  the same demo as before, one gets:

     % coroutine C demo first
     % C "a b" ; # -arguments foo
     a b
     % C "a b" ; # -arguments {{arg ""}}
     a b
     % C       ; # -arguments {{arg ""}}
     % C "a b" ; # -arguments args
     {a b}
     % C "a b" ; # -arguments {foo args}
     a b

  An alternative which is perhaps more convenient, but also more
  complicated, is to have the default *-delivery* depend on the number of
  formal parameters. It is then likely that one for the case of more than
  one formal parameter would want Yet Another delivery mode...

  REFERENCE IMPLEMENTATION
==========================

  None yet.

  OTHER COMMANDS
================

  If coroutines are going to have *proc*-style argspecs, then it will
  probably make sense for *info args* and *info default* to operate on
  coroutine-commands as well as procedures.

  ACKNOWLEDGEMENTS
==================

  This TIP is dedicated to Alexandre Ferrieux, who's known to have
  written that I should prioritize TIPping things over participating in
  tcl-core discussions. ;-)

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

  This document has been placed in the public domain.

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

  TIP AutoGenerator - written by Donal K. Fellows

Available now, the first RC's for Tcl/Tk 8.5.10:

   ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.10rc0-src.tar.gz
   ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tk8.5.10rc0-src.tar.gz

These are release candidates in name only.  They clearly lack
some of the polish necessary to become the actual releases (notes,
changes, website readiness).  They're posted as part of an exercise
dusting off my release-generation tools and skills, and testing out
their adaptation from the CVS to the fossil foundation.  These RC
releases are also a signal that I'm wanting to get to 8.5.10 releases,
so raise your demands for any revisions that need to go into these
releases here and now.

Feel free to dust off your own RC testing and reporting skills, finding
and fixing the defects that need solving before release.

Those who track the fossil timelines will see that there are branches
named "core-8-5-10-rc" from which I am generating these releases.  For
now, please leave commits and merges onto that branch to me.  Commit
your fixes meant for 8.5.10 onto core-8-5-branch, and I'll merge them
over.  With time and practice I may revise or relax that later.

Thanks all!

PS For those wanting to ask "where's an 8.6 release?"  I'll say that I
prefer to make stable and dev releases close together in time.  Makes it
easier in the release note for 8.6b2 to just say "includes all bug fixes
in 8.5.10".  So you can take this signal of pending 8.5.10 to be a
pre-signal of 8.6b2 as well.  If that signals a bunch of you to make a
mad TIP race, so be it.

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

On 17/05/2011 17:20, Brian Griffin wrote:
> Assuming *all* Tcl/Tk commands that are looking for numbers call
> Tcl_GetIntFromObj(interp, objPtr, intPtr) or similar, would it be
> reasonable if these calls all performed an [expr objPtr]?  Then one
> could write:
>
> 	set val [lindex $ra {$j + 1}]
> or
> 	set val [lindex $ra {$j + $i}]
> or
> 	set val [string range $str 0 {$n / 2}]
>
> I would think this would be very tclish.

But it would be difficult to compile the simple existing cases like:

    set val [lindex $ra $j]

That difficulty of compilation is a symptom of the semantics being a
mess. Yes, we could have done this originally (and everyone would be
writing {$j} in that case) but that opportunity is long gone.

Donal.

On 05/26/2011 11:03 AM, Donald G Porter wrote:
> Brian Griffin wrote:
>> Assuming *all* Tcl/Tk commands that are looking for numbers call
>> Tcl_GetIntFromObj(interp, objPtr, intPtr) or similar, would it be
>> reasonable if these calls all performed an [expr objPtr]?
>
> When the command procedure for a command is written, the author already
> has available the free choice on how to interpret the arguments passed
> in.  In particular, the author can choose whether they would rather
> call Tcl_ExprDoubleObj() instead of Tcl_GetDoubleFromObj().
>
> You appear to be suggesting only that several of Tcl's built-in commands
> might be revised to make the Expr*Obj choice instead of the Get*FromObj
> choice currently coded.
>

And I'm not really sanguine about that - at least without careful
discussion of the security implications. It's a whole new, unexplored,
vector for code injection attacks. For surely where you expect "25.0"
someone someday will inject "[exec rm -fr /]"

-- 
73 de ke9tv/2, Kevin

Brian Griffin wrote:
> Assuming *all* Tcl/Tk commands that are looking for numbers call
> Tcl_GetIntFromObj(interp, objPtr, intPtr) or similar, would it be
> reasonable if these calls all performed an [expr objPtr]? 

When the command procedure for a command is written, the author already
has available the free choice on how to interpret the arguments passed
in.  In particular, the author can choose whether they would rather
call Tcl_ExprDoubleObj() instead of Tcl_GetDoubleFromObj().

You appear to be suggesting only that several of Tcl's built-in commands
might be revised to make the Expr*Obj choice instead of the Get*FromObj
choice currently coded.

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

On 18/05/2011 16:22, Donal K. Fellows wrote:
> This is a Call For Votes on TIP #381.

The TIP's Accepted 3/0/0.

For: DKF, JE, KBK
Against: nobody
Present: nobody

Donal.

I've applied the tip 282 patch on TCL 8.5.8 (compilation of 8.6b1 didn't 
work with cygwin / mingw)

expr {
     "x"=1+1;
     "y"=2+2;
}

expr {"x"=("y"=0)}
expr {"x"="y"=0}

work as expected.

FM

Le 22/05/2011 18:31, Will Duquette a écrit :
> This is precisely what I had in mind when I wrote TIP 282.
>

2011/5/23 Frédéric Bonnet <fre...@fr...>:
> Y'all,
>
> I've found a couple of hours to implement a quick proof of concept for infix
> math expressions in Tcl, following the discussion on expr shorthand syntax.
> The trick is to recognize numbers as valid command names and use a builtin
> ObjCmd that accepts the following argument list: "number ?operator
> number...?".
>
> Once the below patch is applied, Tcl will accept infix operators +-*/ with
> Smalltalk-style left-to-right evaluation (i.e. there is no operator
> precedence):
>
> % 1 + 2
> 3
>
> % 1 + 2.0
> 3.0
>
> % 1 + 2 * 3
> 9
>
> % 1 + [2 * 3]
> 7
>
> Overhead relative to expr is around 10-20%, given that there is no bytecode
> compilation.
>
> Some implementation details:
>
> - Tcl_GetCommandFromObj tries to recognize command names as numbers in case
> regular resolution fails. In this case it returns the builtin command
> TclMathExprObjCmd
> - TclMathExprObjCmd uses ExecuteExtendedBinaryMathOp for calculus
>


Just curious, was the tcltest suite run against this?

On 23 May 2011, at 19:17, Frédéric Bonnet wrote:


> I've found a couple of hours to implement a quick proof of concept for infix math expressions in Tcl, following the discussion on expr shorthand syntax. The trick is to recognize numbers as valid command names and use a builtin ObjCmd that accepts the following argument list: "number ?operator number...?".
> 
> Overhead relative to expr is around 10-20%, given that there is no bytecode compilation.

This is very impressive for the effort put in, and a great validation for this approach.

Perhaps the TIP could be reopened with this implementation added. Also the comment at the end should be removed (or appended). This TIP does *not* require changes to Tcl's golden rules.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
http://travellingsalesman.mobi - 10000km & The world's most arctic startups

Y'all,

I've found a couple of hours to implement a quick proof of concept for infix 
math expressions in Tcl, following the discussion on expr shorthand syntax. The 
trick is to recognize numbers as valid command names and use a builtin ObjCmd 
that accepts the following argument list: "number ?operator number...?".

Once the below patch is applied, Tcl will accept infix operators +-*/ with 
Smalltalk-style left-to-right evaluation (i.e. there is no operator precedence):

% 1 + 2
3

% 1 + 2.0
3.0

% 1 + 2 * 3
9

% 1 + [2 * 3]
7

Overhead relative to expr is around 10-20%, given that there is no bytecode 
compilation.

Some implementation details:

- Tcl_GetCommandFromObj tries to recognize command names as numbers in case 
regular resolution fails. In this case it returns the builtin command 
TclMathExprObjCmd
- TclMathExprObjCmd uses ExecuteExtendedBinaryMathOp for calculus



Cheers, Fred

2011/5/22 Lars Hellström <Lar...@re...>:
> OK, here's the critique I promised. First, what I wrote back in December.
> (Some of this stuff clearly should have been posted more quickly.)

Yeah. Thinking far ahead is totally wasted when you take five months to send.

>>  (1) at this point in the discussion, I wonder where this aggressive
>> tone comes from. If it is from ignoring your provious proposal,
>
> Rest asssured that it is not. I'm quite used to thinking so far ahead that
> many of my insights get ignored mainly because others aren't ready to grasp
> them yet.
>
> Seroiusly, I am.

Ah. Then you'll be relieved to notice that the amount of time that
you'll waste with mere mortals like me is, by definition, finite.

> [...] the two primitives are of similar power as
> language extensions. Their main difference lies in how convenient they are
> for the (script-level) user.

How mild, after all this. Sigh.

>
> And that difference is /huge/.
>

Yes. You are right, and I am sincere. I think your proposal is clearly
superior to mine, regardless of your peculiar ways.
The reason I went for the lower-level / sharper knife approach was
sheer laziness: it was what Miguel kindly wrote in 30 minutes after a
quick chat, and clearly shines more in implementation simplicity than
usability.

Please update the TIP (be it by direct e-mail to Donal), including the
Author list.

-Alex

If we propose adding := can we at least consider adding it as a statement rather than an operator? I would also prefer if it was a declaration statement rather than assignment. It could even be used to declare new functions, which might make it a bit more interesting. 

Apologies for top-posting. iPhone is my only email access at present. 

Neil

On 22 May 2011, at 09:57, Alexandre Ferrieux <ale...@gm...> wrote:

> On Sun, May 22, 2011 at 9:59 AM, Donal K. Fellows
> <don...@ma...> wrote:
>> 
>> Perhaps we should separate
>> the debate on new RHS operators for lists and dicts from adding
>> assignment (and sequencing, which only makes sense with assignment).
> 
> Right. Changed the subject to dive into the latter.
> 
> Regarding the fact that the assignment operator (let's call it ":=", a
> grey bikeshed will suffice for now) breaks the "single interception
> point" nature of [set], I beg to differ:
> 
> First, [set] is not alone but surrounded with [lappend], [dict
> lappend] etc. So, a sure-fire interception of assignment involves
> exec-tracing many primitives anyway, with a terrible perf impact
> (those assignments being turned from dedicated BC ops into generic
> evalStk calls).
> 
> Second, we could very well introduce [:=] as a kind of "readmacro",
> ie as a preprocessing step on the AST produced by the expr parser,
> replacing (the AST for)
> 
>     LHS:=RHS
> 
> with (the AST for)
> 
>     set LHS [expr {RHS}]
> 
> (or even [set LHS [expr {RHS}]] if we want to allow := in subexprs)
> 
> This would have the effect of:
> 
>    - direct generation of efficient BC (storeScalar/ArrayStk) when
> [set] is not redefined
> 
>    - compile-epoch bumping and traceable generation of a regular call
> to [set] when it is redefined.
> 
> -Alex
> 
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its 
> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
> developers boost performance applications - including clusters. 
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

OK, here's the critique I promised. First, what I wrote back in December. 
(Some of this stuff clearly should have been posted more quickly.)

Alexandre Ferrieux skrev 2010-12-06 16.46:
> 2010/12/6 Lars Hellström<Lar...@re...>:
>> Alexandre Ferrieux skrev 2010-12-05 23.24:
>>>
>>>    TIP #383: INJECTING CODE INTO SUSPENDED COROUTINES
>>
>> Having previously (on this list) suggested something similar, I'd liketo
>> request additional rationale for some design decisions.
>
> Sorry for missing it; but why didn't it make it to TIP status ?

Because writing a TIP is (IMHO) a certain commitment to also seeing it 
through to implementation. In this case, I would hardly be the best 
qualified to make that implementation, and at the moment I'd rather spend 
what time I have for this kind of work to figure out a solution to Tk bug 
#3028676 ([proc iterate {after 0 {after idle iterate}}] is broken under 
Cocoa).

Moreover, the last time I mentioned the suggestion was within the context 
of the "wouldn't it be better to collect all coroutine-related commands in 
an ensemble?" sub-discussion of the discussion of the [yield*] TIPs, where 
I made a list of things that could go into such an ensemble. Quoting 
myself from 2010-08-11:

>>>
Unrelatedly, it would be interesting to see a full proposal for what a 
coroutine ensemble could look like. Calling the base command [coro] to 
avoid direct clashes with existing users of [coroutine] (and following the 
tradition of [chan]), some obvious commands would be

   coro create ...      -- the existing [coroutine]
   coro current         -- the existing [info coroutine]
   coro exists $name    -- check whether $name is a coro
                           (introspection is good for debugging)

and, unless [yield] gets reformed,

   coro yield $value    -- the existing [yield]

but that's mostly an orthogonal issue (although using an ensemble makes it 
less intrusive to provide several variants of yielding).

Another thing I think would be useful for debugging is

   coro eval $name $script  -- switch to the $name coroutine context,
                               evaluate the $script, switch back and
                               return the result.

For example, if you're trying to debug a coroutine and wonders what @#%%@ 
value is in the local variable state, then

   coro eval a_coroutine {set state}

would give you the answer. Similarly

   coro eval a_coroutine {info frame -1}

(or maybe that should be info frame 0) would tell you the position of the 
[yield] at which the coroutine is currently suspended.
>>>

Dropping out of that discussion to go TIP [coro eval] hardly seems like 
the natural course of action to me.

But for this discussion, it might be better to call the alternative 
command [coeval].

Also, some description of what this [coeval] looks like to the coroutine 
might be useful. Consider that [yield], to a pre-NRE Tcl script, looks 
like the ultimate "mystery command": You pass a value in, you get 
something back, but there is a huge internal state which you cannot 
inspect. The command may take a long time to run, it obviously evals some 
Tcl scripts ([info cmdcount] goes up), and it can change the global 
interpreter state. However, it does not (before this TIP) change the local 
state, so it is as if it would only call Tcl_EvalObjEx with the 
TCL_EVAL_GLOBAL flag set. But when a script is [coeval]ed, it should look 
to the corotuine as if [yield] evaluated that script without 
TCL_EVAL_GLOBAL set.

>> Why on earth do you separate "code injection" and resumption, instead of
>> making the new command be like [uplevel]? It results in a script level
>> interface that seems unnecessarily bulky and cumbersome!
>
> Two things:
>
>   (1) at this point in the discussion, I wonder where this aggressive
> tone comes from. If it is from ignoring your provious proposal,

Rest asssured that it is not. I'm quite used to thinking so far ahead that 
many of my insights get ignored mainly because others aren't ready to 
grasp them yet.

Seroiusly, I am.

> again
> find my apologies for simply overlooking it.

Rather, the tone came from a combination of three sources.

1: Sheer astonishment at how awkward the proposed feature would be to use 
for its stated primary purpose.

2: My general stress level at the time the TIP arrived in my mailbox 
(high, and rising).

3: That this TIP shared many characteristics with some that in the past 
(and IMO) had been approved without enough scrutiny. Somewhat simplicity 
stated, the pattern has been "I'm one of The Powers That Be, this is what 
I've already implemented (see source for more details), and you just 
initial here and here." Merely that the basic functionality is cool and 
that the author is a TCT member (or whatever) doesn't mean that the first 
interface design he came up with is optimal, but apparently it makes it 
hard for his peers to say "no, that's not fully baked yet, sorry."

>
>   (2) to answer the question, we aimed for maximal generality: by
> separating resumption, we also account for a situation where we want
> to "put a breakpoint" on the coroutine's reentry pooint, but want the
> program's logic to flow normally until this resumption occurs, instead
> of forcing it.

Ah, but then I must retort: Why didn't you put that use case in the TIP? ;-)

And unfortunately your proposal doesn't quite work the way that this "put 
a breakpoint" metaphor would suggest. If you [coinject a_coroutine yield] 
and then [coroutine debug_run main], then what happens is not that your 
program runs until it calls [a_coroutine] and then [yield]s so that 
control returns to you at the prompt, but rather that [a_coroutine] 
immediately [yield]s to [debug_run], sending back to [debug_run] whatever 
value it was trying to pass to [a_coroutine]. In order to make the 
breakpoint take effect, you'd needto [coinject a_coroutine yieldto yield] 
(unless the call to [a_coroutine] comes from another coroutine called from 
[debug_run], in which case it'd have to be [coinject a_coroutine yieldto 
yieldto yield], etc.).

The alternative approach to "breakpoints at a coroutine", which already 
happens to be available, is to temporarily replace the coroutine command:

   rename a_coroutine ::somens::a_coroutine
   proc a_coroutine args {
      rename a_coroutine ""
      rename ::somens::a_coroutine a_coroutine
      ::yield [::list "CORO BREAKPOINT TRAP" a_coroutine $args]
   }

The same idea can be used to emulate the argument-juggling capabilities of 
[coinject] using [coeval], so the two primitives are of similar power as 
language extensions. Their main difference lies in how convenient they are 
for the (script-level) user.

And that difference is /huge/.

Consider the problem of inspecting the local variable foo of a_coroutine. 
To do that using [coeval], one would

   coeval a_coroutine {set foo}

That's about as easy as it can get, isn't it?

Now, how would one go about doing the same thing using [coinject]?

Take some time to think about it...







A solution appears below, but first try to figure it out by yourself...










And when you've found a solution, think it through again to see if there 
is something you've missed...







Ready?



OK, here's the answer:

   coinject a_coroutine apply {resumearg {
      catch {
         uplevel 1 {set foo}
      } res dict
      tailcall yieldto ::return -opts $dict $res
   } ::}
   a_coroutine


Not exactly a phrase that comes naturally when typing in things at the 
prompt, is it?

Forgot the [catch]? Well, then [a_coroutine] errors out should foo be 
undefined or an array; there'll be nothing left for you to debug.

Forgot the [uplevel]? No harm done, but all your typing was for naught.

Forgot the [tailcall]? *Better pray* you don't need to access any other 
variable, because the lambda is still on the coroutine's call stack!

Forgot the :: on ::return? You probably won't notice, until the day when 
it matters...



>
>>>       1. "where" is the coro (at which yield site)? and
>>>       2. what are the values of its local variables?
>>
>> Neither of those usages benefit from actually resuming the coroutine. AFAIR,
>> switching to the *context* of a coroutine and *continuing* execution in it
>> are two different things at the C level.
>
> These are just two examples, that are indeed read-only, and could
> possibly work without resuming, like [info level ...], but with much
> less generality than what execution provides.

No, that's not what I mean. My point is that context switches 
(SAVE_CONTEXT, RESTORE_CONTEXT) are separate from resuming execution where 
the coroutine yielded, at least conceptually. (In terms of actual 
implementation the latter seems to consist of updating iPtr->execEnvPtr 
and returning, so it sort of vanishes by getting folded into the NRE 
trampoline.) Still, there is nothing that requires one to switch to the 
coroutine's original execEnvPtr, is there? One might just as well create a 
brand new one to house evaluation of the code one injects into the 
coroutine (and only that code).

[end of stuff written back in December]

I currently don't think the easiest way to implement [coeval] would 
involve creating a new execEnv, but doing that is a trick that may well 
come in handy some day.

>>>    primitive. The idea is to force a resumption of the coro along with an
>>>    "immediate execution of extra code" directive, where the extra code

Judging from the implementation, it is not so much a special "directive" 
as simply an item being pushed upon the NRE execution stack, which seems 
much preferable (I don't think anyone wants more flags for how to eval 
code or resolve commands) ...

>>>    says "dump the call stack with *info level* and *info frame*", or "dump
>>>    the locals", etc.
>>
>> But care must be taken to immediately yeild again.
>
> Yes, as precisely explained 10 lines later ;-)

... but why is this exec stack item designed in a way that makes the main 
use-case is so complicated? Having /it/ do the equivalent of the necessary 
yield would be much simpler.

>> Why inject a command rather than a script? The latter seems much more
>> convenient for debugging (e.g. it offers variable and command substitution in
>> the coroutine context). Is it just the need to juggle the $resumearg?
>
> Yes, just for that reason. That is open to discussion, as hinted at
> under "Reference Implementation".

I can understand that the TIP is vague at this point. Several of the 
schemes discussed for coroutine argument passing would be *very hard* to 
combine with code injections that insist on juggling the arguments first. 
Even such a basic matter as figuring out whether the coroutine did a 
[yield] or a [yieldm] is nontrivial, and in order for a code injection to 
not horribly break things, it has to make sure it leaves the 
coroutine-command expecting the right number of arguments. The example I 
gave above won't work if [a_coroutine] had [yieldm]ed.

The issue can also be viewed from a more theoretical angle. Remember the 
big discussion where coroutines were compared to other primitives for 
"non-hierarchic code execution"? In the LISP family of languages, people 
rather tend to use continuations, and the new primitive introduced is 
call-with-current-continuation (call-cc). This works by wrapping up the 
current contents of the execution stack as a function with one argument -- 
that argument serving as a placeholder for the result expected from 
call-with-current-continuation -- and handing this anonymous function (the 
/continuation/) over to the argument of call-with-current-continuation, to 
deal with as it pleases. This model is rather foreign to Tcl and was 
therefore not imitated, but a [yield]ed coroutine is in principle a 
continuation. One reason to oppose coroutine-commands with multiple 
arguments may have been the desire to preserve this correspondence.

With that in mind, it seems clear to me that [coinject] is essentially a 
compose-continuation-with command; while it does not create continuations 
(it only works on existing coroutine-commands), it modifies them by 
performing function composition of the continuation with some other 
function (specified as a command prefix). This makes sense (but might well 
be a triviality) in LISP. In Tcl, it is not at all clear what it means, 
because Tcl doesn't have a standard function composition operation[*]; 
crafting a resumearg interface is equivalent to defining[**] such an 
operation! For one, that is not easy (and as a task quite different from 
implementing coroutines in the first place, so people good at one need not 
be good at the other). For another, it is something that we already can do 
by temporarily [rename]ing the coroutine-command.

The point is: Since continuations aren't very practical as an abstraction 
in Tcl, then why should one expect a command that is 
compose-continuation-with to be practical?

[*] Tcl is of course perfectly able to use the result of one function as 
argument to another, but that's f(g(x)) whereas composition of functions 
is (f \circ g)(x). Tcl has no native way of representing the latter. [proc 
circ {f g x} {{*}$f [{*}$g x]}] comes close, but is not quite there.

[**] Composition is easy as long as all your functions take exactly one 
argument, but becomes much trickier when they can take several. I could 
show you what the underlying formalisms are if asked to, but they're kind 
of ugly.

> As for subst in the coro context, use [eval] to the same effect. No
> need to burn witches.

The need for a probe wrapper already places us in a position where 
substitution is available. Or to put it another way: [coinject a_coroutine 
eval $script] is unlikely to be what anyone wants. Some kind of [codo] in 
terms of which [coeval] would be

   proc coeval {coro script} {codo $coro eval $script}

is of course possible, but on the other hand one can conversely do

   proc codo {coro args} {coeval $coro $args}

Tclers generally know how to [list]-quote, when necessary.

>>>    Note that:
>>>
>>>       1. Resumption itself must be done separately, by calling /coroname/
>>>          later,
>>>
>>>       2. If *coroinject* is called several times on the same /coroname/
>>>          before resuming it, the commands pile up in LIFO order.
>>
>> Seems complex. What happens if one of the injections [yield] -- will the
>> remaining ones stay in the queue until the next resumption?
>
> That's what the current implementation does, because it makes it
> incredibly simple (look at the cvs diff).

Yes, when one looks at the implementation it is easy to see what happens. 
It's not so easy to grasp it from the given description; my initial 
interpretation of the above was closer to something you probably would 
have described as FIFO order. I agree that the way multiple injections are 
combined is the natural way to handle this, but remain very skeptical 
towards [coinject].

> No strong opinion here, apart from the fact that allowing for
> accumulation is the only way to be modular (ie different parts of the
> code independently inject their own "breakpoints" instead of
> overwriting each other).

What technically happens is that each [coinject] pushes something onto the 
execution stack of the coroutine (which is equivalent to composing the 
continuation counterpart of the coroutine with a function you want to 
execute before it).

>> It should be noted that a "fully transparent injection" here _doesn't_mean
>> "peek into the coroutine to figure out what it's up to" (as was the
>> motivating use-case) but rather "make a one-shot [trace add execution C
>> enter] that executes in the coroutine context".
>
> Again, the spirit is to _generalize_. We've only glimpsed the space of
> possibilities opened by a very simple C-level addition. We're
> purposefully *not* restricting ourselves to the first two examples.

Well, "man muss immer generalisieren" as Jacobi said, but being general is 
no excuse for a tool to have "shoot user in foot" as default mode of 
operation. :-)


Lars Hellström

On May 22, 2011, at 1:57 AM, Alexandre Ferrieux wrote:

> On Sun, May 22, 2011 at 9:59 AM, Donal K. Fellows
> <don...@ma...> wrote:
>> 
>> Perhaps we should separate
>> the debate on new RHS operators for lists and dicts from adding
>> assignment (and sequencing, which only makes sense with assignment).
> 
> Right. Changed the subject to dive into the latter.
> 
> Regarding the fact that the assignment operator (let's call it ":=", a
> grey bikeshed will suffice for now) breaks the "single interception
> point" nature of [set], I beg to differ:
<snip>
> Second, we could very well introduce [:=] as a kind of "readmacro",
> ie as a preprocessing step on the AST produced by the expr parser,
> replacing (the AST for)
> 
>     LHS:=RHS
> 
> with (the AST for)
> 
>     set LHS [expr {RHS}]

This is precisely what I had in mind when I wrote TIP 282.

FWIW.

Will

> 
> (or even [set LHS [expr {RHS}]] if we want to allow := in subexprs)
> 
> This would have the effect of:
> 
>    - direct generation of efficient BC (storeScalar/ArrayStk) when
> [set] is not redefined
> 
>    - compile-epoch bumping and traceable generation of a regular call
> to [set] when it is redefined.
> 
> -Alex
> 
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its 
> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
> developers boost performance applications - including clusters. 
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


Mr. Will Duquette, OP
will -at- wjduquette dot com  
http://foothills.wjduquette.com/blog

So, that is the value of adding the = operator to TCL (which I did about 10 years ago and donated to the TCL group - it was not used then).
Your example becomes:

expr {x(abs) = [winfo x [winfo parent $win]]+[winfo x $win]}
expr {y(abs) = [winfo y [winfo parent $win]]+[winfo y $win]}

So, I agree with the idea of having an assignment operator in the expr command (I also added matrix algebra operators, complex numbers, and waveforms as well). The solution you show completely violates the simplicity of a TCL command being a list of words with the first word the command. It truly makes TCL much harder to use. Having thousands of user's that are currently using TCL with our products I would find many problems adopting a version of TCL that so perverts the underlying simplicity of the language. I truly hope you do not do that. Create either a new command using TCL syntax or extend the expr command to be more useful but do not change the basis of the language - please...

Regards
David


David W. Smith
Synopsys Scientist
 
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124

Voice: 503.547.6467
Main:  503.547.6000
Cell:    503.560.5389
FAX:   503.547.6906
Email: dav...@sy...
http://www.synopsys.com
 
Saber Accelerates Robust Design
Predictable. Repeatable. Reliable. Proven.

-----Original Message-----
From: Florent Merlet [mailto:pos...@fl...] 
Sent: Sunday, May 22, 2011 8:37 AM
To: David Smith; tcl...@li...
Subject: Re: [TCLCORE] Some expr sillyness

Le 22/05/2011 12:53, David Smith a écrit :
> I agree. I have been using and shipping product using tcl an tk since the late 90's. Tcl's value has been simplicity and regularity. If I want complexity and obfuscation I can always use perl. A lot of the ideas I see being proposed for tcl (such as this) seem like either medalling or a desire for a completely new language. Please do not forget what makes tcl special and do not turn it into a Frankenstein of a language.
>
> Regards
> David
> ----------------------
If you don't want complexity and obfuscation, do expr as usual.

The problem is that, sometimes, the usual way lead to complexity and obfuscation, and that is the reason of this discussion.

Compare
##################################################
     set x(abs) [expr {[winfo x [winfo parent $win]]+[winfo x $win]}]
     set y(abs) [expr {[winfo y [winfo parent $win]]+[winfo y $win]}] #################################################
With :
######################################
expr {
     x(abs)=winfo("x",winfo("parent",$win))+winfo("x",$win);
     y(abs)=winfo("y",winfo("parent",$win))+winfo("y",$win);
}
######################################

And compare (from wiki convex hull)
###############################################################
     for {set i 0} {$i < $count} {incr i} {
         set coords [.c coords point$i]
         set x [expr {int(([lindex $coords 0] + [lindex $coords 2]) / 2)}]
         set y [expr {int(([lindex $coords 1] + [lindex $coords 3]) / 2)}]
         set y [expr {$h - $y}]
         lappend indexes $i
         lappend points [list $x $y]
         if {$y < [lindex $points $pivot 1]} {
             set pivot $i
         }
     }
###############################################################
With :
###############################################################
     for {set i 0} {$i < $count} {incr i} {
         expr {  coords = [.c coords point$i];
             x  = int(($coords{0}+$coords{2}) /2);
             y  = int(($coords{1}+$coords{3}) /2);
             y  = $h-$y;
             lappend("indexes", $i);
             lappend("points", ($x, $y));
             $y < $points{$pivot,1} ? pivot=$i:;}
     }
################################################################

Where is the "obfuscation" ?
> ----- Original Message -----
> From: Kristoffer Lawson [mailto:se...@sc...]
> Sent: Sunday, May 22, 2011 02:48 AM
> To: Donal K. Fellows<don...@ma...>
> Cc: tcl...@li...<tcl...@li...>
> Subject: Re: [TCLCORE] Some expr sillyness
>
>
> This will add a huge level of complexity to Tcl,
Not to Tcl, but to expr {}.
> will force people studying the language to effectively learn two 
> languages,
No, since all the currents practices remain valid, every one who does'nt want to learn deaply expr langage, don't need to do so : just do as usual.
> it will create questions as to why one syntax works in one place and not another (further aggravated by any 9.0 syntax to do expressions) and will increase the difficulty of understanding code, due to its modal nature.
Well, doesn't those questions already arise since there is operators in expr and not at the toplevel parser ?
The response is simple :
As to work metal, we don't use woodworking tools, To process mathematical expressions, we don't use a shell syntax !
Well, if you want to do so, you can, but it's a lot more to write.

Personally, it take me a long time to realize that if {$i+1} work and I have very often written this if {[expr {$i+1}]

The first way is shorter, but both of them work.

> While I do often wish for something shorter for expressions than the full [expr {...}] (and math ops as commands has greatly reduced that pain), the above is unnecessary sugar and will not make Tcl adoption for newcomers any easier at all. For anyone who has a big need for something like this, just let them build or use an extension.
>
An extension mecanism would be great.

FM

Le 22/05/2011 12:53, David Smith a écrit :
> I agree. I have been using and shipping product using tcl an tk since the late 90's. Tcl's value has been simplicity and regularity. If I want complexity and obfuscation I can always use perl. A lot of the ideas I see being proposed for tcl (such as this) seem like either medalling or a desire for a completely new language. Please do not forget what makes tcl special and do not turn it into a Frankenstein of a language.
>
> Regards
> David
> ----------------------
If you don't want complexity and obfuscation, do expr as usual.

The problem is that, sometimes, the usual way lead to complexity and 
obfuscation, and that is the reason of this discussion.

Compare
##################################################
     set x(abs) [expr {[winfo x [winfo parent $win]]+[winfo x $win]}]
     set y(abs) [expr {[winfo y [winfo parent $win]]+[winfo y $win]}]
#################################################
With :
######################################
expr {
     x(abs)=winfo("x",winfo("parent",$win))+winfo("x",$win);
     y(abs)=winfo("y",winfo("parent",$win))+winfo("y",$win);
}
######################################

And compare (from wiki convex hull)
###############################################################
     for {set i 0} {$i < $count} {incr i} {
         set coords [.c coords point$i]
         set x [expr {int(([lindex $coords 0] + [lindex $coords 2]) / 2)}]
         set y [expr {int(([lindex $coords 1] + [lindex $coords 3]) / 2)}]
         set y [expr {$h - $y}]
         lappend indexes $i
         lappend points [list $x $y]
         if {$y < [lindex $points $pivot 1]} {
             set pivot $i
         }
     }
###############################################################
With :
###############################################################
     for {set i 0} {$i < $count} {incr i} {
         expr {  coords = [.c coords point$i];
             x  = int(($coords{0}+$coords{2}) /2);
             y  = int(($coords{1}+$coords{3}) /2);
             y  = $h-$y;
             lappend("indexes", $i);
             lappend("points", ($x, $y));
             $y < $points{$pivot,1} ? pivot=$i:;}
     }
################################################################

Where is the "obfuscation" ?
> ----- Original Message -----
> From: Kristoffer Lawson [mailto:se...@sc...]
> Sent: Sunday, May 22, 2011 02:48 AM
> To: Donal K. Fellows<don...@ma...>
> Cc: tcl...@li...<tcl...@li...>
> Subject: Re: [TCLCORE] Some expr sillyness
>
>
> This will add a huge level of complexity to Tcl,
Not to Tcl, but to expr {}.
> will force people studying the language to effectively learn two languages,
No, since all the currents practices remain valid, every one who does'nt 
want to learn deaply expr langage, don't need to do so : just do as usual.
> it will create questions as to why one syntax works in one place and not another (further aggravated by any 9.0 syntax to do expressions) and will increase the difficulty of understanding code, due to its modal nature.
Well, doesn't those questions already arise since there is operators in 
expr and not at the toplevel parser ?
The response is simple :
As to work metal, we don't use woodworking tools,
To process mathematical expressions, we don't use a shell syntax !
Well, if you want to do so, you can, but it's a lot more to write.

Personally, it take me a long time to realize that
if {$i+1}
work and I have very often written this
if {[expr {$i+1}]

The first way is shorter, but both of them work.

> While I do often wish for something shorter for expressions than the full [expr {...}] (and math ops as commands has greatly reduced that pain), the above is unnecessary sugar and will not make Tcl adoption for newcomers any easier at all. For anyone who has a big need for something like this, just let them build or use an extension.
>
An extension mecanism would be great.

FM

I agree. I have been using and shipping product using tcl an tk since the late 90's. Tcl's value has been simplicity and regularity. If I want complexity and obfuscation I can always use perl. A lot of the ideas I see being proposed for tcl (such as this) seem like either medalling or a desire for a completely new language. Please do not forget what makes tcl special and do not turn it into a Frankenstein of a language. 

Regards
David
--------------------------
David W. Smith
Synopsys Scientist
W: 503.547.6467
M: 650.861.9814

----- Original Message -----
From: Kristoffer Lawson [mailto:se...@sc...]
Sent: Sunday, May 22, 2011 02:48 AM
To: Donal K. Fellows <don...@ma...>
Cc: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] Some expr sillyness


On 22 May 2011, at 10:59, Donal K. Fellows wrote:

> Expressions are already a little language of their own. They have been
> since at least as far back as Tcl's “changes” file goes (early 1990 is
> the first date[*], but that's not the beginning and [expr] already had
> operators then; Tcl 3.0 is the _latest_ that expressions could have been
> introduced). As such, we can put things into here (e.g., to deal with
> lists and dicts) without the same amount of difficulty. I also have
> tremendous sympathy for wanting to find a shorter outer syntax for
> [expr] itself; producing a list of computed values is _very_ verbose.

Yes, I'm aware of this. However currently, while [expr] is a language of its own from the point of view of the actual expressions (ie. bringing infix operators), everything else still follows Tcl's normal rules. Variable and command substitution behave almost exactly as they would outside [expr]. Changing that is a very dangerous path to be taking as you're going beyond the idea of having a small sub-language for doing math operations to one which is effectively a Turing-complete language of its own. Even if you don't bring in all the syntax people have been talking about here, you are still bringing a whole new set of sub-language abilities which look and act completely differently from outside it.

This will add a huge level of complexity to Tcl, will force people studying the language to effectively learn two languages, it will create questions as to why one syntax works in one place and not another (further aggravated by any 9.0 syntax to do expressions) and will increase the difficulty of understanding code, due to its modal nature.

While I do often wish for something shorter for expressions than the full [expr {...}] (and math ops as commands has greatly reduced that pain), the above is unnecessary sugar and will not make Tcl adoption for newcomers any easier at all. For anyone who has a big need for something like this, just let them build or use an extension.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
http://travellingsalesman.mobi - 10000km & The world's most arctic startups


------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

On 22 May 2011, at 10:59, Donal K. Fellows wrote:

> Expressions are already a little language of their own. They have been
> since at least as far back as Tcl's “changes” file goes (early 1990 is
> the first date[*], but that's not the beginning and [expr] already had
> operators then; Tcl 3.0 is the _latest_ that expressions could have been
> introduced). As such, we can put things into here (e.g., to deal with
> lists and dicts) without the same amount of difficulty. I also have
> tremendous sympathy for wanting to find a shorter outer syntax for
> [expr] itself; producing a list of computed values is _very_ verbose.

Yes, I'm aware of this. However currently, while [expr] is a language of its own from the point of view of the actual expressions (ie. bringing infix operators), everything else still follows Tcl's normal rules. Variable and command substitution behave almost exactly as they would outside [expr]. Changing that is a very dangerous path to be taking as you're going beyond the idea of having a small sub-language for doing math operations to one which is effectively a Turing-complete language of its own. Even if you don't bring in all the syntax people have been talking about here, you are still bringing a whole new set of sub-language abilities which look and act completely differently from outside it.

This will add a huge level of complexity to Tcl, will force people studying the language to effectively learn two languages, it will create questions as to why one syntax works in one place and not another (further aggravated by any 9.0 syntax to do expressions) and will increase the difficulty of understanding code, due to its modal nature.

While I do often wish for something shorter for expressions than the full [expr {...}] (and math ops as commands has greatly reduced that pain), the above is unnecessary sugar and will not make Tcl adoption for newcomers any easier at all. For anyone who has a big need for something like this, just let them build or use an extension.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
http://travellingsalesman.mobi - 10000km & The world's most arctic startups

On Sun, May 22, 2011 at 9:59 AM, Donal K. Fellows
<don...@ma...> wrote:
>
>  Perhaps we should separate
> the debate on new RHS operators for lists and dicts from adding
> assignment (and sequencing, which only makes sense with assignment).

Right. Changed the subject to dive into the latter.

Regarding the fact that the assignment operator (let's call it ":=", a
grey bikeshed will suffice for now) breaks the "single interception
point" nature of [set], I beg to differ:

 First, [set] is not alone but surrounded with [lappend], [dict
lappend] etc. So, a sure-fire interception of assignment involves
exec-tracing many primitives anyway, with a terrible perf impact
(those assignments being turned from dedicated BC ops into generic
evalStk calls).

 Second, we could very well introduce [:=] as a kind of "readmacro",
ie as a preprocessing step on the AST produced by the expr parser,
replacing (the AST for)

     LHS:=RHS

with (the AST for)

     set LHS [expr {RHS}]

(or even [set LHS [expr {RHS}]] if we want to allow := in subexprs)

This would have the effect of:

    - direct generation of efficient BC (storeScalar/ArrayStk) when
[set] is not redefined

    - compile-epoch bumping and traceable generation of a regular call
to [set] when it is redefined.

 -Alex

On 21/05/2011 18:04, Kristoffer Lawson wrote:
> I think this, and a lot of other expr-specific syntax is only going
> to make the language horribly confusing. Why does one syntax for vars
> work in expr, and not in the normal interpreter?

There's very little that I would change about non-expression syntax; it
provides a complete set of operations within its own purview. The result
is that some things are perhaps a little wordy on occasion, but I think
that's not a huge problem since it opens the way to doing so much
sophisticated processing at the higher level. Any changes in the syntax
here have to be done very carefully indeed.

Expressions are already a little language of their own. They have been
since at least as far back as Tcl's “changes” file goes (early 1990 is
the first date[*], but that's not the beginning and [expr] already had
operators then; Tcl 3.0 is the _latest_ that expressions could have been
introduced). As such, we can put things into here (e.g., to deal with
lists and dicts) without the same amount of difficulty. I also have
tremendous sympathy for wanting to find a shorter outer syntax for
[expr] itself; producing a list of computed values is _very_ verbose.

On the other hand, there might be good reason to avoid assignment
operators. Currently, Tcl programs change their state by running a
command to do it; if we wish to intercept the state change, we can
intercept commands and know that there's no way around. This is a good
property. Adding an assignment operator changes that. (Before you ask,
[trace] lets us intercept specific state changes, but only on things
that we can name ahead of time.) It also means we have to introduce a
new syntactic/semantic concept to expressions (the Lvalue) which isn't
exactly as trivial as it sounds (it's basic denotation is not a value,
but rather "something you can assign to"). Perhaps we should separate
the debate on new RHS operators for lists and dicts from adding
assignment (and sequencing, which only makes sense with assignment).

Donal.
[* It marks the introduction of [info exists]. ]

On 21 May 2011, at 13:33, Donal K. Fellows wrote:

> 
> No, but that's because I'm talking about doing it in an expression
> context (independent of whether that's introduced by [expr] or some
> other mechanism) only. I can be sure that what I have in mind won't
> break anything for you:

I think this, and a lot of other expr-specific syntax is only going to make the language horribly confusing. Why does one syntax for vars work in expr, and not in the normal interpreter?

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
http://travellingsalesman.mobi - 10000km & The world's most arctic startups

Hello!

	This year I develop debugging tools for Tcl's non-recursive engine as
my Google summer of code project. The project's wiki page is here with
some info: http://wiki.tcl.tk/28334 I would like to write a bit about
the present state of the project and then ask for comments and advice.
The reason I have chosen this list is that some developers may not
subscribe tcl-gsoc.
	The first investigation has shown it's possible to extend Gdb with some
useful commands using Tcl [1]. Sadly, it's a modified Gdb implementation
for vxWorks. Looking for other possibility, I have found a paper of M.
DeJong [2] describing Gdbmi interface usage (thanks to him and M. Sofer,
my mentor, for finding the sources for me). At that moment I could have
also chosen python support built into Gdb:
http://sourceware.org/gdb/wiki/PythonGdb
	I have chosen the latter, since it's actively developed (and Tcl's
Gdbmi is not, according to my knowledge) and built into gdb (so more
closely integrated), and also it's actually used (to implement similar
debugging tools for Python).
	In the repository [3] there is the first implementation of nre-bt
command displaying Tcl call stack contents. To use that code you will
need Gdb 7.3 archer branch (installation instuctions in the repo). It's
merely beginning and much has to be done, but still your comments will
be useful.
	The plan at the moment is as follows:
1) Improve the implementation of nre-bt, surely the output format has to
be changed (what you would like to see there?). It can be connected with
implementing nre-p command enumerated later.
2) Implement nre-f command allowing to select tcl call stack frame (as
in „frame” gdb command). The problem here is to invalidate frames as
they are destroyed, I need to think of it a bit.
3) Implement nre-p command displaying contents of tcl call stack frame.
As before, what should be displayed here?
4) While displaying call stack contents I will make my best to parse the
client data passed to callbacks according to the callback's names. For
that I will have to tabelarize the callbacks and their arguments' types,
so that I could know how to display them. There must be a simple way of
adding new callbacks to my project, so I will think of one, but you
could help me describing in some way the format of the callback's
arguments - will a simple format string suffice? If not, I will prepare
something more complicated, but to design that I need some info.
	Please comment on that and, obviously if you have some free time, test
my code. All new ideas are welcome and I would like to discuss them.

                                                                 Regards

                                                   Krzysztof Kwaśniewski

---
[1]
http://www-kryo.desy.de/documents/vxWorks/V5.4/tornado/unixguide/c-debugger6.html

[2]
http://www.google.com/url?sa=t&source=web&cd=5&ved=0CDcQFjAE&url=http%3A
%2F%2Fwww.tcl.tk%2Fcommunity%2Ftcl2004%2FTcl2003papers%
2Fdejong.pdf&rct=j&q=tcl%
20gdbmi&ei=VKjXTfnmDcqCOq-DkIkH&usg=AFQjCNGIU-2C3SBh_mEJQ5ws-H4hm7t1pQ&cad=rja

[3] http://chiselapp.com/user/krzykwas/repository/nredebug1

 On Fri, 20 May 2011 23:39:05 +0300, Kristoffer Lawson wrote:

> But then again, this syntax is quite consistent with the rest of the
> language, when you understand why it works that way.

 In fact to my understanding the thread was also about how to (cleanly) 
 inject
 in specific contexts a different syntax the would work better for a 
 specific
 task (math). No wonder the C-like or Matlab-like languages are natural 
 choices.
 My point was that if they are chosen it must be done so that
 the programmer is able to write code basically the way he would do in 
 that
 context. Mixing them up with Tcl 'idiosyncrasies' doesn't make Tcl any
 better. "A shoe and a slipper" as we say in italian.

 But I understand your answer: one has to grasp the essence of the 
 language and
 get along with it. Unless you're using LabView, where doing 
 computations can
 be impossible if don't resort to the text control with the Matlab-like 
 shell.

 This might be the punchline of the gigantic thread. And anyone else 
 should
 draw on the extension mechanism to embed something like Octave.

  -- Massimo

RE TIPs 372/375

On 05/21/2011 02:17 AM, Joe English wrote:
>      + Miguel has a working implementation (though by now
>        it may be stale).

AFAIK things work properly. I believe some people are using them, no bug 
reports since the first few days. The underlying machinery looks healthy 
enough.