funny tcl bug…

[aotto1968]

Hi, put code down in a "extra2.test" file and call it with :

tclsh extra2.test 1 or 2 or 3

===============================
lassign $argv num

if { $num == 1 } {

puts 1

# } elseif { $num == 2 } {
#
# puts 2

} else {

puts 99

}
=================================

> tclsh extra2.test 1
1

> tclsh extra2.test 2
!! nothing !!

> tclsh extra2.test 3
99


→ ha… ha… ha…

[heinrichmartin]

On Monday, August 29, 2022 at 8:37:51 AM UTC+2, aotto wrote:
> tclsh extra2.test 1 or 2 or 3
>
> ===============================
> lassign $argv num
>
> if { $num == 1 } {
>
> puts 1
>
> # } elseif { $num == 2 } {
> #
> # puts 2
>
> } else {
>
> puts 99
>
> }
> =================================
>
> > tclsh extra2.test 1
> 1
>
> > tclsh extra2.test 2
> !! nothing !!
>
> > tclsh extra2.test 3
> 99
>
>
> → ha… ha… ha…

That is not a bug. Tcl works as expected. But the expectation varies: comments are _not_ parsed first ...

Your 2nd argument to [if], i.e. the first code block, ends just before elseif, because of rule #6 of the dodekalogue.
Within that code block, you have commented out the last line (that is empty anyway).
Inside the branch { $num == 2 }, all non-empty lines are commented out.

A few notes:
* [if] and friends are ordinary commands in Tcl; you can even override them (but be warned: don't!).
* Tcl comments need not be the first non-space character of a line (but the first character of the first word when Tcl expects a command).
* I use [if 0 { ... }] to comment out code blocks temporarily. Still, there is no true inline comment like /* ... */ in C.
* The behavior does _not_ depend on using $argv.
* Tcl has a switch command.

[aotto1968]

declare a BUG to a FEATURE makes your programmer-live much more easy ;-)

[Ralf Fassel]

* aotto1968 <aott...@t-online.de>

| declare a BUG to a FEATURE makes your programmer-live much more easy ;-)

Not understanding the rules of the programming language you work with
makes your programmer-life much harder.

R'

[Siri Cruise]

In article <tehmrq$vjot$2...@dont-email.me>,

aotto1968 <aott...@t-online.de> wrote:

> Hi, put code down in a "extra2.test" file and call it with :
>
> tclsh extra2.test 1 or 2 or 3
>
> ===============================
> lassign $argv num

I've never been clear when the first argument is in argv or taken
as stdin so I start with something like

if {[lindex $argv 0]=="-"]} {set argv [lrange $argv 1 end]}

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|¥
Discordia: not just a religion but also a parody. This post / ¥
I am an Andrea Chen sockpuppet. insults Islam. Mohammed

[Gerald Lester]

This behavior is clearly defined in the rules of Tcl syntax -- may I
strongly suggest you go back and read them until you internalize them
well enough to see why this is NOT A BUG.


--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

[Rich]

aotto1968 <aott...@t-online.de> wrote:
> On 29.08.22 09:06, heinrichmartin wrote:
>> On Monday, August 29, 2022 at 8:37:51 AM UTC+2, aotto wrote:
>>> tclsh extra2.test 1 or 2 or 3
>>>
>>> ===============================
>>> lassign $argv num
>>>
>>> if { $num == 1 } {
>>>
>>> puts 1
>>>
>>> # } elseif { $num == 2 } {
>>> #
>>> # puts 2
>>>
>>> } else {
>>>
>>> puts 99
>>>
>>> }
>>> =================================
>>

>> That is not a bug. Tcl works as expected. But the expectation
>> varies: comments are _not_ parsed first ...
>>
>> Your 2nd argument to [if], i.e. the first code block, ends just
>> before elseif, because of rule #6 of the dodekalogue. Within that
>> code block, you have commented out the last line (that is empty
>> anyway). Inside the branch { $num == 2 }, all non-empty lines are
>> commented out.
>

> declare a BUG to a FEATURE makes your programmer-live much more easy ;-)

However it is not a bug. Perhaps reformatting your code a bit might
make this fact more clear.

Here is how Tcl sees your code:

if { $num == 1 } {
puts 1
#
} elseif { $num == 2 } {
#
# puts 2

} else {

puts 99

}

Note how the empty comment just after puts 1 is actually inside the
"block" belonging to the 'then' part of the if clause.

Tcl is not Bash, # characters, anywhere on a line, do not comment out
the rest of the line. # is only recognized as a comment when, as per
rule 10, it appears where Tcl is expecting the first character of the
first word of a command. Because of rule 6 (braces) your puts 1 and #
are part of the "then" body of the if clause.

You should read the 12 rules. You can find them in the Tcl man page,
or here online: http://www.tcl-lang.org/man/tcl8.6/TclCmd/Tcl.htm

[Tau]

To be fair, the only editor that color codes this correctly is komodo.
Both emacs and vim will mislead you.

But I guess, this should count as an editor bug...

[aotto1968]

Be honest, the TCL specification was "designed" to make the example below NOT-A-BUG …

I thing it is clear that 99.99% of all programmers in the world (with and without TCL knowledge)
will define this example below as a DESIGN-BUG and the 0.000000000001% of all coders who require this
"code-after-comment" feature are still not born ;-)


mfg

[Rich]

aotto1968 <aott...@t-online.de> wrote:
>
> Be honest, the TCL specification was "designed" to make the example

> below NOT-A-BUG ?

Not at all. The TCL specification documents how the TCL parser parses
TCL source code. The design of that parser was set out by John
Ousterhout circa 1988 when he designed TCL. The parser is deliberately
simple because TCL, circa 1988, was intended to be a small extension
language to be incorporated into a larger project. What you term
"NOT-A-BUG" is just a direct consequence of that deliberately simple
parser.

> I thing it is clear that 99.99% of all programmers in the world (with
> and without TCL knowledge) will define this example below as a
> DESIGN-BUG and the 0.000000000001% of all coders who require this
> "code-after-comment" feature are still not born ;-)

99.99% of programmers will learn the rules of the language before
jumpinng to "that's a bug".

[aotto1968]

You don't understand why I post this TCL-BUG.

It is not just the simple example-code it is also a "comment-out-block".
To comment out a code-block is widely used for testing, etc.
If you always have to count-the-{ and step deep into code-flaw-pitfall it is
not good.

mfg

[Gerald Lester]

On 8/29/22 13:31, aotto1968 wrote:
> On 29.08.22 19:57, Rich wrote:
>> aotto1968 <aott...@t-online.de> wrote:
>>>
>>> Be honest, the TCL specification was "designed" to make the example
>>> below NOT-A-BUG ?
>>
>> Not at all.  The TCL specification documents how the TCL parser parses
>> TCL source code.  The design of that parser was set out by John
>> Ousterhout circa 1988 when he designed TCL.  The parser is deliberately
>> simple because TCL, circa 1988, was intended to be a small extension
>> language to be incorporated into a larger project.  What you term
>> "NOT-A-BUG" is just a direct consequence of that deliberately simple
>> parser.
>>
>>> I thing it is clear that 99.99% of all programmers in the world (with
>>> and without TCL knowledge) will define this example below as a
>>> DESIGN-BUG and the 0.000000000001% of all coders who require this
>>> "code-after-comment" feature are still not born ;-)
>>
>> 99.99% of programmers will learn the rules of the language before
>> jumpinng to "that's a bug".
>
> You don't understand why I post this TCL-BUG.

No, we do understand -- Tcl does not work like the other languages you
learned, therefore Tcl is broken.

[Tau]

https://stackoverflow.com/q/5833969/4769561
It seems, you are not the first one to be bitten by this behavior. As for how to comment out blocks of code easily, that's an interesting question. I don't know of a single Tcl ide that can do this reliably. If anyone knows, do share!

[heinrichmartin]

On Monday, August 29, 2022 at 8:50:12 PM UTC+2, Tau wrote:
> I don't know of a single Tcl ide that can do this reliably.

Tcl is an interpreted language. Every Tcl word might be evaluated as code on discretion of the command (other words are expressions, strings, ...); therefore, an IDE can only know that for well-known commands, or it requires some sort of configuration or annotation (beyond pure Tcl).

Btw, Tcl is interpreted at runtime, but it per-compiles code and runs quite fast for that reason - a great trade-off imo.

[Tau]

Yeah, thinking more about this, with context-dependent
comments it's pretty much impossible to write a general
purpose comment-uncomment function.

https://wiki.tcl-lang.org/page/Why+can+I+not+place+unmatched+braces+in+Tcl+comments

Watch out for those switch statements too...

[Helmut Giese]

Hi,

>You don't understand why I post this TCL-BUG.
>
>It is not just the simple example-code it is also a "comment-out-block".
>To comment out a code-block is widely used for testing, etc.
>If you always have to count-the-{ and step deep into code-flaw-pitfall it is
>not good.
>
>mfg

as someone else already suggested: I 'comment out' code by using an
if 0 {
...
}
block if it is more than 2 or 3 lines of code or optionally an
if 0 {
...
} else {
...
}
block to be able to quckly switch between 2 versions.
HTH
Helmut

[Rich]

Due to the way the TCL parser works, in this particular instance, a
"comment out block" using "#" characters does not work. Comment
characters in Tcl work differently than in Bash or other languages that
use # as a line comment character. They have worked this way in TCL
since circa 1988. They are not likely to change now, 34 or so years
later.

[Alex P]

Tcl's way of commenting is perhaps its main freak that has been scared away most of potential Tclers. Those who are able to overcome it have a chance to live in Tcl world long and happily. Others leave.

https://wiki.tcl-lang.org/page/comment

[Rich]

Every language has its own idiosyncrasies. Those who learn those
idiosyncrasies remain, those who can not adapt to something different
from what they already know leave.

Your statement could be applied to just about every language, as nearly
all of them have at least one bit of their syntax that is surprisingly
different from how what appears to be similar syntax works in other
languages.

[Alex P]

Excuse me for the typo: not "has been scared away" but "has scared away" of course.

---

Rich, you are absolutely right, esp. on Tcl, as this language is much disregarded and proportionally underestimated.

Just I got a feeling from this discussion that Otto is passing now through a hard time when he should decide - be with or without Tcl. Every time, it's a decision one takes for oneself.

---

Otto, nevertheless, if you refer to works (zum mindesten) of your compatriot Paul Obermeier, you would possibly try and master Tcl/Tk as Paul did.

And, please, don't use your abbreviation "mfg" in English (or nearly:) audience, it can be misunderstood. Just speak and write it in Deutsch.

Mit freundlichen Grüßen.

[et4]

On 8/29/2022 1:05 PM, Rich wrote:

>
> Due to the way the TCL parser works, in this particular instance, a
> "comment out block" using "#" characters does not work. Comment
> characters in Tcl work differently than in Bash or other languages that
> use # as a line comment character. They have worked this way in TCL
> since circa 1988. They are not likely to change now, 34 or so years
> later.

True, however, the manual entry on rule 10 could be improved. The problem here is with the clause:


... then the hash character and the characters that follow it, up through the next newline, are treated as a comment and ignored.


At minimum, it could say, "up through the next newline or the end of the script, whichever comes first". However, I doubt that new tcl programmers would fully appreciate the distinction.

Here the script comment didn't have a newline, and so the OP assumed it to mean the newline at the end of the line, not just inside the braced script.

Brevity seems to have been foremost with rule 10. There are some issues that could be addressed there directly, rather than deferring to other rules, such as what do braces in comments do? What about quotes and square brackets. And what of backslash escapes?

I've got my own rule(s) of thumb I go by to stay out of trouble:



1. Avoid {}'s in comments. When used, pair on the same line and { before }

2. Use short on the line comments: ;# comment ...

3. \ escape braces inside quotes

4. use if 0 {...} to comment out larger code blocks.



The other way I remain mostly trouble free is by using code template/macro's that my editor supports. My multi-branch if template gets all the bracing boilerplate correct before I begin to flesh out the variable pieces. Here's the template:

if { cond } {
dothis
} elseif { cond } {
dothis
} elseif { cond } {
dothis
} else {
dothis
}

My editor also knows enough about tcl to be able to jump back and forth between matching pairs, across lines, and with some inside double quotes that are escaped. But it too would fail on the OPs example.

[Rich]

et4 <tcl...@rocketship1.me> wrote:
> On 8/29/2022 1:05 PM, Rich wrote:
>
>>
>> Due to the way the TCL parser works, in this particular instance, a
>> "comment out block" using "#" characters does not work. Comment
>> characters in Tcl work differently than in Bash or other languages that
>> use # as a line comment character. They have worked this way in TCL
>> since circa 1988. They are not likely to change now, 34 or so years
>> later.
>
> True, however, the manual entry on rule 10 could be improved.

It does require understanding a fair bit more of the overall context of
the other rules to fully recognize what it is describing.

> The problem here is with the clause:
>
>
> ... then the hash character and the characters that follow it, up through
> the next newline, are treated as a comment and ignored.

Yes, in part because understanding what that clause means requires
realizing that this leading clause is of critical importance:

If a hash character ("#") appears at a point where Tcl is expecting
the first character of the first word of a command

To fully understand this clause requires recognizing that in the OP's
code structure, that troublesome # is not recognized as a command until
after the processing of rule 6 (braces) is complete. And it is the
brace processing that results in the # becoming an empty comment inside
the "then" branch of the if. Had OP not tried to comment out a valid
bit of if branch code, he might instead have hit the "missmatched brace
in comment" error that also confuses many early TCL'ers.

> At minimum, it could say, "up through the next newline or the end of
> the script, whichever comes first". However, I doubt that new tcl
> programmers would fully appreciate the distinction.

True. Better might be to add a statement to the effect of: "comment
recognition occurs after the brace processing of rule 6 has been
completed." But even something like that requires a fair amount of
contextual understanding of the other rules of TCL to recognize the
real meaning that it is attempting to convey. There may not be any
good way to write something up without becoming a very wordy tome.

[et4]

On 8/30/2022 12:24 PM, Rich wrote:

> et4 <tclnews@...> wrote:
>> On 8/29/2022 1:05 PM, Rich wrote:

>
> It does require understanding a fair bit more of the overall context of
> the other rules to fully recognize what it is describing.

Yes, and that can be quite difficult. I've been reading the rules for >20 years now, and I'm still not certain about them all. For example, does rule number imply precedence? Do I apply all the rules in sequence, 1-12? Rule 10 is after rule 6 on bracing and that is after rule 2: the [if] body is whatever [if] wants it to be. Throw in the recursion, and it gets quite complicated.

So, it's not quite so simple as "you just have to read the rules, there's only 12 of them". The rules try to explain in English a rather complex parsing algorithm, and one that isn't taught in CS compiler courses. When I wrote compilers, I was able to stand on the shoulders of the yacc/lex giants. But tcl's parser is a very different animal.

>
> True. Better might be to add a statement to the effect of: "comment
> recognition occurs after the brace processing of rule 6 has been
> completed." But even something like that requires a fair amount of
> contextual understanding of the other rules of TCL to recognize the
> real meaning that it is attempting to convey. There may not be any
> good way to write something up without becoming a very wordy tome.
>

I often jump right to the examples sections in the manual. Perhaps some additional examples with the 12 rules would help w/o creating too much of a tome.

[aotto1968]

Hi,

This are MY rules for the new TCL

1) add a simple pre-processor to TCL like CPP for C and add all the missing features like "(real)-comment" to top of this this
pre-processor
2) after preprocessing the OLD-Tcl parser get always "valid" TCL code
2) to activate a NEW featur use the new "pragma ?feature?" command
3) every TCL-Source-File is read with *source* and source is able to analyze the *pragma* and chose the proper pre-processor
4) A *pragma* is only valid WITHIN the singe source-file currently read (ease mix OLD and NEW style code)

example add block-comment #* … *# :

---------------------------------------
pragma new-style-comment

lassign $argv num

if { $num == 1 } {

puts 1

#*
} elseif { $num == 2 } {

puts 2
*#

} else {

puts 99

}
--------------------------------------

this generate a valid tcl code like

---------------------------------------
pragma new-style-comment

lassign $argv num

if { $num == 1 } {

puts 1

(5 EMPTY lines, just to get the TCL-Line-Number counting right ;-)



} else {

puts 99

}
--------------------------------------

on top of the "pragma/pre-processor" a lot of usfull features can be added WITHOUT touching the TCL-Parser

mfg

[Christian Gollwitzer]

Am 31.08.22 um 18:18 schrieb aotto1968:

> Hi,
>
> This are MY rules for the new TCL
>

[....]

Well then have fun implementing it and come back when it is ready.

Christian

[Gerald Lester]

+100,000

[Colin Macleod]

Alex P <apls...@gmail.com> wrote in
news:6fda5d67-0469-46be...@googlegroups.com:

>
> And, please, don't use your abbreviation "mfg" in English (or
> nearly:) audience, it can be misunderstood. Just speak and write it
> in Deutsch.
>
> Mit freundlichen Grüßen.
>

I have often wondered what "mfg" meant, now at last I know :-)

[heinrichmartin]

Just a few thoughts:
* A TIP is the expected way to draft a suggestion. (That includes a draft implementation as Christian wrote.)
* A pre-processor might indeed fix the "issue", i.e. ease the learning curve for inexperienced Tcl'ers, but it increases the complexity of the setup/dependencies.
* I can think of an implementation in pure Tcl, i.e. rewrite [source]. (One must probably fiddle with the call stack and the file name ...)
* I like the #* ... *# syntax as a "natural" extension of Tcl comments.
* Concerning "pragma":
** My guts feeling prefers #pragma.
** What is the position of #pragma in the file? The specification should consider a possible shebang.
** I'd vote against "new-style-comment", why not "enable-block-comment"?

On Wednesday, August 31, 2022 at 10:04:04 PM UTC+2, Gerald Lester wrote:
> On 8/31/22 14:38, Christian Gollwitzer wrote:
> > Am 31.08.22 um 18:18 schrieb aotto1968:

> >> This are MY rules for the new TCL

> > Well then have fun implementing it and come back when it is ready.

> +100,000

I am not a particular communications pro, but I try to not fall for the first possible interpretation - this usually helps not to escalate.

> This are MY rules for the new TCL

"Your rules suck." vs. "I have an idea for improvement."

> Well then have fun implementing it and come back when it is ready.

(with sarcasm) "Get your things together before bothering us." vs. "Luckily Tcl is open source. Please share your work."

> mfg

"middleaged fat guy" vs. "mother f***ing genius" ;-) (Both from a web source for abbreviations.)

[Rich]

Colin Macleod <c...@erehwon.gro> wrote:
> Alex P <apls...@gmail.com> wrote in
> news:6fda5d67-0469-46be...@googlegroups.com:
>>
>> And, please, don't use your abbreviation "mfg" in English (or
>> nearly:) audience, it can be misunderstood. Just speak and write it
>> in Deutsch.
>>

>> Mit freundlichen Gr????en.

>>
>
> I have often wondered what "mfg" meant, now at last I know :-)

Same. I had thought it likely did not mean its common English
expansion: "manufacturing", but did not know the Deutsch usage.

[aotto1968]

just a limerick, core question in TCL:

> how to comment-out a code block without lose(delete) and without create a huge hidden code bug?

if {$isPointer} {
if {$isOut} {
if {$isCast} {
lappend CALL_PRE_MAPPING $at $av NormalizePtrNull "${av}_val"
lappend CALL_POST_MAPPING $at $av NormalizePtr "${av}_val"
set av [Filter_Ref ${av}_val]
set isCast no
if 0 {
# \} elseif \{exists2($name,"force-error-return") && [lindex $::ATTRIBUTE($name,force-error-return) 1] eq $av} \{
# lappend CALL_PRE_MAPPING $at $av ErrorForceReturn "${av}_val"
# lappend CALL_POST_MAPPING $at $av ErrorForceReturn "${av}_val"
# continue
}
} else {
switch -regexp $at {
ME_BNP {
lappend CALL_POST_MAPPING $at $av ByteArray_Write "${av}_ptr"
lappend args [Filter_Out ${av}_ptr]; set av [Filter_Out ${av}_size]
}
default { set av [Filter_Out $av] }
}
}
...

On 29.08.22 08:37, aotto1968 wrote:
>
> Hi, put code down in a "extra2.test" file and call it with :
>

> tclsh extra2.test 1 or 2 or 3
>
> ===============================

> lassign $argv num
>
> if { $num == 1 } {
>
>   puts 1
>

[aotto1968]

As is thought → Code is BROKEN, TCL comment BUG

> sbin/meta/tcl_MqC.tcl -lc
Main from sbin/meta/tcl_MqC.tcl
pInit -> ::PRINT<0>, ::ONDEBUG<0>, ::VERBOSE<0>, ::FILTER<no>, meta<.liblcconfig.meta> |
can't read "name": no such variable
while executing
"pNameMqS $name"
(file ".../lib_MqC.tcl" line 233)
invoked from within
"source .../lib_MqC.tcl"
("uplevel" body line 1)
invoked from within
"uplevel source [file join $::env(NHI1_HOME) sbin meta $a]"
(procedure "pSource" line 3)
invoked from within
"pSource lib_MqC.tcl tcl_MqS.tcl lib_DX.tcl"
("uplevel" body line 3)
invoked from within
"uplevel $init"
(procedure "pInit" line 383)
invoked from within
"pInit tcl MqC {

pSource lib_MqC.tcl tcl_MqS.tcl lib_DX.tcl

if {$LibPkg eq "MqMsgque"} {
p_func_arg_name_DEFAULT fEvent ..."
(file ".../tcl_MqC.tcl" line 18)

[heinrichmartin]

On Monday, September 5, 2022 at 9:46:47 AM UTC+2, aotto wrote:
> > how to comment-out a code block without lose(delete) and without create a huge hidden code bug?

> if 0 {
> # \} elseif \{exists2($name,"force-error-return") && [lindex $::ATTRIBUTE($name,force-error-return) 1] eq $av} \{
> # lappend CALL_PRE_MAPPING $at $av ErrorForceReturn "${av}_val"
> # lappend CALL_POST_MAPPING $at $av ErrorForceReturn "${av}_val"
> # continue
> }

Indeed, commenting out parts of code branches (e.g. if or switch) is not a beauty. There are other options beyond Tcl:
* actually remove that part; later restore it from version control
* backup the file locally, then remove the part
* cut the part and paste/backup it in another file/editor/email

Also, it seems odd (and possible wrong) that 3 out of 4 braces are escaped on the elseif-line. I assume, I'd remove or escape the first one only and add a temporary close brace at the end.

if 0 {
# \} elseif {exists2($name,"force-error-return") && [lindex $::ATTRIBUTE($name,force-error-return) 1] eq $av} {
# lappend CALL_PRE_MAPPING $at $av ErrorForceReturn "${av}_val"
# lappend CALL_POST_MAPPING $at $av ErrorForceReturn "${av}_val"
# continue

# REMOVE ME }
}

[Alex P]

In alited editor, comment & uncomment actions do the proper commenting out,
by this pattern:

set num 2

if { $num == 1 } {
puts 1

# #\} elseif #\{ $num == 2 #\} #\{

# puts 2
} else {
puts 99
}

Thus, the braces don't mess the testing up.

The alited's uncommenting restores the original code:

set num 2

if { $num == 1 } {
puts 1

} elseif { $num == 2 } {

puts 2
} else {
puts 99
}

Details here:
https://aplsimple.github.io/en/tcl/alited/

Thank you all who participated in the discussion, alited profiting from it.