From Newsgroup: comp.lang.tcl

On 12/14/2025 3:40 AM, Tristan Wibberley wrote:

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15 -extent 30 >> ...
...
...
}

For a command that only accepts numerical arguments in the first 4 positions, why should one need to supply a sigil. The code already calls on a procedure to convert an argument to a pure number. Why not just go further and convert an expression argument to a number. And if it's simply a number, or the output of [expr...], well that will also work, so it's a compatible upgrade.

I'm going to assume you don't really need !-start, but once -start is seen, the next argument also needs to resolve to a number.

However you choose to do this, the = command is designed to do this transformation for you since it does the parsing and gets the values of the variables. If you use expr, you are at risk of exploits unless you brace and add $ sigils.

I'm not proposing that we change tcl all at once. The first step is to address the expr command for it's clutter and safety concerns when called internally. I'm supporting the = command as a foundation for future tcl improvements.

-et99





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/14/2025 6:40 AM, Tristan Wibberley wrote:

I realise I've mixed multiple DSL ideas:

On 14/12/2025 03:28, Tristan Wibberley wrote:

numberish {
cmd1 arg arg $[x+1]
cmd2 arg arg $[y/x]
}

vs

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15 -extent 30 >> ...
...
...
}

Obvs. it might need to be extended with a numberish namespace

I lost the transition from rubberish to numberish :-)

Interesting thread. Working from the assumption that in any/all of the proposed approaches, both "x" as well as "$x" would be interpreted to
refer to the value of "x", I find it odd that one would be able to mix
"x" and "$x" references in the same statement line and be OK. One could imagine how an outsider, a newcomer or someone debugging some old code,
might approach this as some kind of magic trick that must be preserved
and replicated as-is and then told to others as a "Tcl-gotcha." And if
the new convention prevents "$x" from referring to the value of "x",
then we might need to add a few more rules to the language.

While it could work as a package or a module, I am not sure of the value
add, tbh.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <saitology9@gmail.com> posted:

Interesting thread. Working from the assumption that in any/all of the proposed approaches, both "x" as well as "$x" would be interpreted to
refer to the value of "x", I find it odd that one would be able to mix
"x" and "$x" references in the same statement line and be OK.

This is analogous to how one can currently write:
[expr $x * 2]
or
[expr {$x * 2}]
In most cases either will work, but the second is safer and more efficient.

While it could work as a package or a module, I am not sure of the value add, tbh.

For my implementation of TIP 676, I have put the code in the core because
I did not want to duplicate all the definitions of math operators, their precedences and corresponding bytecodes which exist for `expr` but are
not made public; also because I want to byte-compile the command and that appears not to be practical for an extension.
--
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 14/12/2025 23:40, et99 wrote:

On 12/14/2025 3:40 AM, Tristan Wibberley wrote:

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15
-extent 30
...
...
...
}

For a command that only accepts numerical arguments in the first 4
positions, why should one need to supply a sigil.

I thought that was a problem you had with the notation you posted, that
there's no general way to express the calculation needed and the command
had its own language inside it.

I'm just elaborating the breadth of options for solution somewhat. The
idea above is a draft of a fairly nice flavour of alternatives for the
scale of concrete needs that had come up.

I'll carry on in case you agree that's valuable and important.

To give a general notation that's useful for tasks with small
calculations a short prefix sigil is valuable, and if a function for
larger expressions such that there must be whitespace has the same name
as the sigil then it's pretty good.

call numberish "qs!" (for "quasiscript !") or "qs=" (for "quasiscript
=") or qs# {for "quasiscript #"} and you've got yourself a good system
for scripting.

BTW I think "=" is the wrong symbol because its a common relation in mathematics rather than an evaluation, excel kind of got it wrong. But I
don't think its /terrible/. "#" might be better to indicate "a number approximated thusly:"

I'll carry on as if you agree '#' is best.

inside a qs# script every word beginning #, eg "#suffix" is interpreted
exactly as "[# suffix]" and "[# #suffix]" is interpreted as just
"#suffix" would be outside the qs# script so "##suffix" becomes, a
normal word "#suffix", passed through. The sigil is invalid as an
initial element of the expression DSL and immediately after the
expression DSL's open brackets unless it's doubled-up there:

##foo -> foo
#foo+bar -> value of foo plus value of bar
###foo reserved for some special quasiquote quasireference
#x+(#foo) reserved more generally
#x+(##foo) reserved for some special quasiquote quasireference


If your language for "proc '#'" works without spaces for short
expressions and has a useful grouping bracket choice ( so a
subexpression works here or there, then I think it's pretty good because
"qs# { cmd #x-(y+z) #top<bot }" is nice, quick and clear. then you can
convert between that and "cmd [# x - (y + z)] [# top < bot]" freely.

same applies if you stick with = instead of # or !. Thinking it over, #
is best, I think.

I'm not proposing that we change tcl all at once. The first step is to address the expr command for it's clutter and safety concerns when
called internally. I'm supporting the = command as a foundation for
future tcl improvements.

yes, expr is difficult. an alternative through which one can get started
in a similar manner is needed.

I think the use-case of lots of commands with small calculations from a
few variables is also of importance and the semantics and syntax of the
two should coincide usefully, generically, and intuitively.
--
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 15/12/2025 02:49, saito wrote:

On 12/14/2025 6:40 AM, Tristan Wibberley wrote:

I realise I've mixed multiple DSL ideas:


On 14/12/2025 03:28, Tristan Wibberley wrote:

numberish {
   cmd1 arg arg $[x+1]
   cmd2 arg arg $[y/x]
}

vs

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15
-extent 30
...
...
...
}

Obvs. it might need to be extended with a numberish namespace

While it could work as a package or a module, I am not sure of the value
add, tbh.

well, we've already got commands with their own DSLs and special variables.

That's a big annoyance and a source of mistakes that a stringly-typed
scripting language can't afford.

The opportunity is here to ensure they're less warty as we go on which
my sigil-blocks/quasiscript-blocks don't handle right because I just
described them as mapping words directly to [...] equivalents and some
things like "end" need to be interpreted in the command the calculation
is for. (I think another sigil and its quasiscript-block interpreter
could be used to provide an evaluation delay - I will think more about it).

If a new expr-alternative is added it needs to be done so the DSL it
implements is compatible with the needs of quasiscripts such that the regularity of commands that take calculations as arguments can be
improved. Otherwise Tcl and its packages will just either get more warty
or stagnate rather than solidify into a good foundation.

I don't think it's a big challenge but requires a little thought up
front for the [= ...] or [# ...] or whatever to be a finished change.
--
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

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

BTW I think "=" is the wrong symbol because its a common relation in mathematics rather than an evaluation, excel kind of got it wrong. But I don't think its /terrible/. "#" might be better to indicate "a number approximated thusly:"

Unfortunately, while you are quite correct from a mathematics
viewpoint, that ship has long ago sailed for = meaning "evaluate
expression" in programming languages. Using = for "evaluate", while technically wrong mathematically, will fit with the built in
understanding anyone will have from programming languages as far back
as BASIC.

I'll carry on as if you agree '#' is best.

# is problematic because it is already used as the "commenting"
character, so overloading its usage to sometimes also mean "evaluate"
and the remainder mean "comment" would impose a new cognitive load upon readers and writers of code. They would have to disambiguate the two
meanings based on other contextual clues.

The = symbol, at least, has been mis-used to mean 'evaluate' for so
very long that there is no cognitive load for programmers seeing = in
code to have to disambiguate two very different meanings from context
clues. Only actual mathematicians will have some cognitive load in
seeing = used to mean evaluate.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/15/2025 4:18 AM, Colin Macleod wrote:

saito <saitology9@gmail.com> posted:

Interesting thread. Working from the assumption that in any/all of the
proposed approaches, both "x" as well as "$x" would be interpreted to
refer to the value of "x", I find it odd that one would be able to mix
"x" and "$x" references in the same statement line and be OK.

This is analogous to how one can currently write:
[expr $x * 2]
or
[expr {$x * 2}]
In most cases either will work, but the second is safer and more efficient.

My example tried to highlight the pitfalls of treating identically
different combinations of: x, "x", {x}, $x, and perhaps more. I think
this is quite different the semantics of using braces where you learn it
as a core part of Tcl.

A couple of thoughts:
Perhaps I am simply not using expr enough to see how annoying it could be.

Also consider Lua. I believe it started off as a fork of Tcl but I don't remember what the point of contention was. Perhaps this could be another approach. Fork a Better Tcl where "expr" doesn't exist.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 15/12/2025 16:09, Rich wrote:

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

Unfortunately, while you are quite correct from a mathematics
viewpoint, that ship has long ago sailed for = meaning "evaluate
expression" in programming languages. Using = for "evaluate", while technically wrong mathematically, will fit with the built in
understanding anyone will have from programming languages as far back
as BASIC.

tcl uses "set" for that and continues to do so. It is the last sanity remaining.

Haskell (correctly) uses <- and reserves = for a more nuanced definition concept, not for assignment or evaluation.

C uses = for assignment and not for evaluation.

I'll carry on as if you agree '#' is best.

# is problematic because it is already used as the "commenting"
character

Oh Crikey! That just didn't pop into my head! We wouldn't want that as a
sigil because we'd want to keep the space for the last word on a line to
become a comment someday.

The = symbol, at least, has been mis-used to mean 'evaluate' for so
very long that there is no cognitive load for programmers seeing = in
code to have to disambiguate two very different meanings from context
clues. Only actual mathematicians will have some cognitive load in
seeing = used to mean evaluate.

I've only seen it used to mean evaluate in BASIC and Excel. I don't
remember seeing it anywhere else.
--
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 4:08 PM, Tristan Wibberley wrote:

On 15/12/2025 16:09, Rich wrote:

The = symbol, at least, has been mis-used to mean 'evaluate' for so
very long that there is no cognitive load for programmers seeing = in
code to have to disambiguate two very different meanings from context
clues. Only actual mathematicians will have some cognitive load in
seeing = used to mean evaluate.

I've only seen it used to mean evaluate in BASIC and Excel. I don't
remember seeing it anywhere else.

I really like Colin's work is for it's educational value. Anyone truly interested in how expr and procedure compiling work should study his code. It is quite elegant and a demonstration of how the Tcl compiler system works.

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

As to the choice of command symbol:

The version of Colin's = written in pure tcl that I've enhanced uses : instead of the = as I've also implemented my own version of TIP 282 (multiple statements and an assignment operator). To my eyes, a multi-assignment statement that looked like this, seemed to suggest something was missing on the left side:

= a = b = c = 0

and so I prefer

: a = b = c = 0

I also use ' for an on the line statement separator, since the ; would need to be inside braces or the Tcl parser sees it first and abruptly ends the command. This let's me write this on 1 line without needing braces:

: a = 5 ' b = 2 ' a + b # returns 7 with a and b assigned their values

In addition, when one does use braces in a multi-statement multi-line command, it can handle blank lines, newline command separators, and comments starting with # or ;# like so, since it's done as a pre-parse pass:

: {

a = 10 ; b = 20
gather(a,b,max(a,b)) # as the last statement, returns a list as though [list $a $b [expr {max($a,$b)}]

}

where gather is

proc tcl::mathfunc::gather {args} {list {*}$args}


As a pure tcl extension, one is free to modify for one's uses.

However, for Tcl to grow into a more modern language, while still remaining true to it's core, I believe that Colin's C version should be approved for the entire community to benefit from out of the box.

And there's always rename and interp alias if one doesn't like the =

-et

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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

--- 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 15/12/2025 18:12, saito wrote:

On 12/15/2025 4:18 AM, Colin Macleod wrote:

saito <saitology9@gmail.com> posted:

Interesting thread. Working from the assumption that in any/all of the
proposed approaches, both "x" as well as "$x" would be interpreted to
refer to the value of "x", I find it odd that one would be able to mix
"x" and "$x" references in the same statement line and be OK.

This is analogous to how one can currently write:
   [expr $x * 2]
or
   [expr {$x * 2}]
In most cases either will work, but the second is safer and more
efficient.

My example tried to highlight the pitfalls of treating identically
different combinations of: x, "x", {x}, $x, and perhaps more. I think
this is quite different the semantics of using braces where you learn it
as a core part of Tcl.

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. It /must/ be at least partially deferred to interpret at least some names in a dynamic closure
inside the command it's passed to. It suffers from the problem that it's
not /generally/ obvious what DSL it is. It already uses some names
without $ that act like object references yet it's common to expand
variables into the expression using text, even though the expansion is
into a word so it may be an expression segment rather than an object representation. There are many factors that make it ripe for
generalisation with a sigil in a sigil-designated block of code (a quasiscript). Fortunately that can be done in a package to experiment
and get it right.

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.

{} quotes whitespace and prevents commands in [] or variable references
eg $x, from being substituted
"" quotes whitespace but /doesn't/ prevent ...
each might have other effects besides, see man tcl.


x - a letter, can be interpreted by a command
any way the command specifies, including
as a variable reference
"x" - a letter, see above
{x} - a letter, see above
{{x}} - word that's a brace, letter, brace sequence
"{x}" - same
$x - a word from a tcl variable called x
"$x" - a word from a tcl variable called x, the
different notation is just about allowing
spaces into the word around $x but this
example does not take advantage of that
(see "a ${x} b" below)
a${x}b - a string starting a, ending b, with the
string from a tcl variable called x pasted
in the middle.
"a${x}"b" - same
"a ${x} b" - same but with spaces in the resulting word
{$x} - a word that's a dollar followed by an x, can
be interpreted by a command any way the
command specifies
{a $x b} - string starting a, ending b, dollar followed
by x in the middle, some spaces around it,
can be interpreted by a command any way the
command specifies
a{b - a word starting a, ending b, with a brace in the middle
--
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

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