From Newsgroup: comp.lang.tcl

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

I'm now thinking about those places like lindex where an argument is
end-2 and stuff like that.

That's a DSL that could do with being generalised.

In the Discussion section of TIP 676 I said:

Some of the string and list-related commands already support a restricted
form of numeric expressions for indices, e.g. [lindex $list end-2]. This
could be generalised in future by having them temporarily define end as
the appropriate value and run the = processing on index arguments.
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/16/2025 4:11 AM, Tristan Wibberley wrote:

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except as noted in
the sig.

What does that mean?

Regarding your concern about why there are various ways to use a variable:

see man tcl if on linux and read and understand the 12 rules in details, experiment based on what you find there.

I suspect you missed the point of the message. While there are Tcl
commands that currently accept a variable name or a variable value, you
cannot mix and match them willy-nilly. But the proposed solutions would, AFAICT, allow one to write "x + $x" to end up with a value of 2*x. That
is something I have not seen elsewhere and may end up doing more harm
than good.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 16/12/2025 14:17, Colin Macleod wrote:

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

I'm now thinking about those places like lindex where an argument is
end-2 and stuff like that.

That's a DSL that could do with being generalised.

In the Discussion section of TIP 676 I said:

Some of the string and list-related commands already support a restricted
form of numeric expressions for indices, e.g. [lindex $list end-2]. This
could be generalised in future by having them temporarily define end as
the appropriate value and run the = processing on index arguments.

That's a mere implementation choice, though, I feel it should be somehow present in the user experience such as with a sigil. I'm currently
sleeping on it, how to make a very general system with the right properties.

[] doesn't look okay because (a) it requires clumsy cursor moving, and
(b) it is not deferred. obvious deferring method {[= end-1]} feels like
too much to type but it does look good as an idiom.

Maybe it's okay because when you do it a lot, a quasiscript block will
let you use a sigil instead for equivalent functionality but happier
inputting and the quasiscript block will be implementable as just
another library feature that rewrites a script to long form.

lindex $l {[= end-1]}

This is an obvious pattern that can eventually be taken to be regular.
and it can be supported in such commands by literally failing to parse
the old format then falling back to merely executing [undefer 2 {{var
value} ...} $expression]. 'undefer' might itself be a complication of
'proc {level vars expression} { uplevel $levels withvars $vars return $expression }' to get the right dynamic closure but it also cries out
for some sort of standardised structured error callback especially so quasiscripts can patch the error elements to undo their rewrites.

.c create somewidget {[= left+10]} {[= right-10]} ...

set myshorts {{l left} {r right}}
qs= $myshorts -- .c create somewidget =l+10 =r-10 ...


qs= {{l left} {r right}} -- {
.c create somewidget =l+10 ...
.c create somewidget =l+20 ...
.c create somewidget =r-10 ...
}

there is a need to specify compound relations and apply a solver from
time to time (even for simple layout things, or especially), all deferred.

I think it can be supported with the above form. I wonder how to handle
errors - the expression will be slightly different at execution time
than in the script.

Still, I think = is the wrong symbol.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except as noted in
the sig.

On 16/12/2025 16:39, saito wrote:

While there are Tcl
commands that currently accept a variable name or a variable value, you cannot mix and match them willy-nilly. But the proposed solutions would, AFAICT, allow one to write "x + $x" to end up with a value of 2*x. That
is something I have not seen elsewhere and may end up doing more harm
than good.

I agree.

I just posted elsewhere to this thread a fairly general deferred
expression method that only uses barewords for variable references (call
them "free indeterminates" from the perspective of the expression, or
perhaps you can get away with "context-bound indeterminates" from the perspective of the point of their eventual evaluation without any prefix
being added to bind them to Tcl variables).
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/15/2025 9:59 PM, clt.to.davebr@dfgh.net wrote:

I'm not sure it is a good idea to include single character function names in the base TCL set.
Things like:

proc a {...

are too useful at the command line.

For example I have my own take on a expr I call uexpr (it does math with units like ft sec kg watt ... etc).

package require uexpr

exposes the uexpr command at the global level.
There is an option in the uexpr pkgIndex.tcl for:

package require uexpr=

that aliases = to uexpr for convienence at the command line (= 3ft+6in=cm returns "106.68 cm")
However when I write a package "calc" to format calculations to generade .pdf files using pdflatex
and uexpr, I require uexpr, and use the canonical uexpr name in the package code
because the = alias might be preempted for some other purpose at the command line.

I think single character command names are too useful at the command line to be "taken" by the base TCL language or a widely used package.

daveb

This is a valid concern. It is at least as valid as the main objection to $(...) that of colliding with the invisible array name.

I suppose to be fully compatible, = would need to be defined in a namespace. =::= comes to mind, but that's likely as bad on the eyes as a cluttered expr command.

I would think that any package developer with their own namespace could import = into it, but only the top level app developer would likely have the freedom to import into the global namespace.

I hadn't given it much thought before, but my choice of : may be better or worse in this regard, since I'm not even sure how one would encode it into a namespace. AFAIK, extra : characters, as in ::::aglobal are allowed and the extra pair ignored. But what about an odd number. Can I have ::ns::: as the name : inside namespace ns?

I guess any new command can cause a problem. When I wrote up the TIP that became lseq, I wanted to call it range, since it was to implement the python range function in Tcl. I realized it was likely to collide, so I then suggested rangeof, especially since it would be used a lot with foreach. So, foreach i [rangeof ...] seemed to run smoothly. We ended up with lseq so it could begin with an l, and seq since it was implemented as a sequence, not a true list.

Changing Tcl is really hard to do and keep everyone happy.

-et

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/16/2025 6:17 AM, Colin Macleod wrote:

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

I'm now thinking about those places like lindex where an argument is
end-2 and stuff like that.

That's a DSL that could do with being generalised.

In the Discussion section of TIP 676 I said:

Some of the string and list-related commands already support a restricted
form of numeric expressions for indices, e.g. [lindex $list end-2]. This
could be generalised in future by having them temporarily define end as
the appropriate value and run the = processing on index arguments.

When I worked on modified index expressions (using my numerical expression C function) I had to address the end issue. I still don't fully understand how end is encoded, but I originally thought that end was always the same as list/string length - 1. But that's not the case. Some commands treat end differently, such as linsert. If you look at the coding of an index in GetEndOffsetFromObj you will see how end is done.

I may be wrong, but I believe the reason for this is so the caller can decide how to use end in a calculation. I did eventually get it to work, but that was long enough ago that I've now forgotten how it works, just that it was very confusing to me at the time.

-et

--- Synchronet 3.21a-Linux NewsLink 1.2