Tcl 7.3 bug
l...@nshade.uah.ualberta.ca
but Tcl does not like comments in procedures when the comment
applies to a command/structure that has unequal open braces than
closing braces. For example consider the following "test"
procedure:
proc test {v1 v2} {
# if {$v1==$v2} {
if {$v1!=$v2} {
return 0
}
return 1
}
Running this Tcl code will produce "missing close brace" error.
If the rightmost opening brace in the commented IF command is
removed, Tcl runs wthout any problems.
I'm wondering, does the new version 7.4b2 fix this problem, or
is the bug still in there.
Also, do you know where one should send an email message
in case a Tcl bug is found (besides posting it here)?
I wanted to send a message to Mr. John Ousterhout, but
I could not find his email address in the Tcl/Tk book.
Thanks.
Lad
email: l...@nshade.uah.ualberta.ca
Michael Salmon
l...@nshade.uah.ualberta.ca writes:
|> I'm not sure whether I'm the first one to discover this bug or not,
|> but Tcl does not like comments in procedures when the comment
|> applies to a command/structure that has unequal open braces than
|> closing braces.
There has been much discusion here about whether this is a bug or not.
Tcl requires that lists are always correct regardless of whether they
are in comments or not. IMHO this is a trivial restriction that should
be documented rather the same as the restriction that in C comments
cannot contain */.
--
Michael Salmon
#include <standard.disclaimer>
#include <witty.saying>
#include <fancy.pseudo.graphics>
Ericsson Telecom AB
Stockholm
lad
>
>A poster asks if anybody knows about the "bug" where if a commented
>out line ends with a {, then the comment keeps going until the
>matching } is read. The short answer, of course, is that it's not
>a bug, because it's supposed to work that way. On the other hand,
>how often do new users have to trip over a particular language quirk
>before it gets classified as a design bug?
>
For sure I did not ask anyone whether anyone could confirm THIS bug
because I test my code before I tell about any discovered bugs!
If I post and inform someone, I do not ask anyone about confirming
my findings.
Second, it HAS to be regarded as a bug since the docs do not
say anything about not being able to comment Tcl code in
procs because if the SAME code is used outside any proc,
Tcl does not complain. So if it is supposed to WORK THAT
WAY, then WHY DOES IT WORK when the same commented-out code is
outside of any proc??!! According to your logic it SHOULD
NOT WORK that way, but alas it does. Those of us who have
programmed for many years in other non-Tcl languages know how
important it is to comment-out some code. But who am I to
tell experts like you that regards ability to comment
out any development code as some particular language quirk.
BTW, if you had looked into the Tcl C source code, you would have found
out that this particular language quirk could have been avoided
with a simple While loop and possibly one IF statement.
Lad
Clarance Howatt
>
>In article <3fka5q$k...@quartz.ucs.ualberta.ca>
>lad writes:
>[...] innocent reply
>|> BTW, if you had looked into the Tcl C source code, you would have found
>|> out that this particular language quirk could have been avoided
>|> with a simple While loop and possibly one IF statement.
>
>Tcl is moderately slow as it is so I am against adding a while loop and
>an if statement to a central portion of the interpretter. You can
>perhaps let us know what the performance degradation is.
Actually, I would say that the degradation would not be that bad (can
be as few as 2 additional opcodes depending on a compiler and its
option settings) to check for '#' char and continue if it is
not (implemented by a simple If statement). Also, the code
for jumping over the comment strings would run much faster since
this would require only one While loop inside the If statement
previously mentioned. Of course one would have to check
for a command terminator char -- newline or semi-colon, but
this comparison would need to be done in the If statement block
for '#' char, so this comparison would not degrade the performance,
unless a '#' char is found.
But once the Tcl procs' code is debugged, the unnecessary code
(the one that is commented out) would be removed, so there won't
be that much of performance degradation, only the first
If statement would slow down the script execution.
I could modify my version of Tcl, but I do not want to stray
away from the official release of Tcl. However, what I might
do is to include the code bounded by #ifdef and #endif
precompiler directives.
Lad
Clarance Howatt
>
>It's possibly a design flaw, but it is not a BUG.
>
>The problem is that the parser cannot know, at parse time, whether a given
>list (string in {}) is just a string, or if it's going to be *at some
>later time* interpreted as tcl code.
>
>
>Try this scenario on for size. Suppose I want to define a new "proc"
>command, called "myproc", that adds the new procedure to a list
>(associative array) of procedures that I've defined. Easy:
>
>proc myproc {procname args body} {
> global Myprocs
> set Myprocs($procname) [list $args $body]
> proc $procname $args $body
>}
>
>Now, if the parser has added a special case so that the following "works":
>
>proc x {a} {
> # if {this is commented out} {
> if {the real stuff} {
> do something
> }
>}
>
>then it won't work when I change it to
>
>myproc x {a} {
> # if {this is commented out} {
> if {the real stuff} {
> do something
> }
>}
>
>On the other hand, if it does work with "myproc" (and therefore, with
>ANY command), then there will be no way I can really put a # into a
>string at the beginning of a line (think about it). E.g.,
>
>set a {this is a string with a
># and some stuff in {braces}}
>
Your example is quite interesting!! You are absolutely right
that it won't be possible to print out any items after a '#'
at beginning of a line *if* the chars after the '#' are
discarded! However, if these chars are not discarded and
only the brace count is ignored, then you'll be able to
to ***print the starting '#' char and chars that follow***.
Therefore, it IS possible to put a '#' into a string at the
beginning of a line and at the same time to treat the
1st '#' char as a comment char for an executable code!!
Thus the currently modified Tcl *DOES* execute your code:
myproc x {a} {
# if {this is commented out} {
if {the real stuff} {
do something
}
}
without any problems and at the same time
Myprocs(x) is expanded into the following string
(bounded here by double quotes):
"a \n#\ \ if\ \{this\ is\ commented\ out\}\ \{\n\ \ if\ \{the\
real\ stuff\}\ \{\n\ \ \ \ do\ something\n\ \ \}\n"
Notice that newline, space, and brace chars are preceeded
(escaped) with backslashes.
The reason that the printout appears like this is that
there is unequal number of openning and closing braces
when the code is treated as a list of items where
'#' does not act as a comment.
So if I delete the openning brace on the comment line,
Myprocs(x) variable will be printed out like this:
a {
# if {this is commented out}
if {the real stuff} {
do something
}
}
Notice that there are no escape backslashes and that the '#'
is printed out, so Tcl can handle any lists which lines
start with '#' chars.
Going to your following example:
set g {some string
# and some stuff in {braces}}
would not work if it were executed outside of any proc
body of code, ie, by itself as "set" command since the
TclEval recognizes '#' at the beginning of a command line as
a comment char. The following error will be generated:
"Missing close brace".
However, if this code is placed inside a proc command
code segment, like this:
proc test {} {
global g
set g {some string
# and some stuff in {braces}}
}
}
and then "test" command is executed, g will contain the
following string (a list) that spans 2 lines:
some string
# and some stuff in {braces}}
Notice here that I had to use EXTRA closing bracket because
the extra closing bracket IS ignored during proc execution.
However, this extra closing brace does appear in the
contents of g variable!
Therefore, the only limitation for my modified version of Tcl
is that I do not use unequal number opening and closing braces
in the commented code (if it is eventaully used as a list
of elements). However, if I *NEED* to use unequal number
of opening and closing braces in one comment, ie, IF
command, then I *HAVE* to include a commented-out closing
brace at appropriate location. Thus the 1st example could
be modified as:
myproc x {a} {
# if {this is commented out} {
if {the real stuff} {
do something
}
# }
}
to assign the following value to Myprocs(x):
a {
# if {this is commented out} {
if {the real stuff} {
do something
}
# }
}
So if I need to comment-out a code inside a code, I can do
it, and at the same time '#' char will be passed to the list
for further manipulation, even code execution in which case
the commented-out code will not be executed, ie, the 2nd
element of Myprocs(x) list is code (another list) that
can be executed but the 1st IF command will not be evaluated!
The Tcl modification is a little bit longer than 5 lines, 20
lines to be exact. However, I think that it can be
shorter, but as long as it works for me, I'm not changing
it.
Lad
John Ousterhout
|> A poster asks if anybody knows about the "bug" where if a commented
|> out line ends with a {, then the comment keeps going until the
|> matching } is read. The short answer, of course, is that it's not
|> a bug, because it's supposed to work that way. On the other hand,
|> how often do new users have to trip over a particular language quirk
|> before it gets classified as a design bug?
|>
All of the mail on this topic really boils down to the following question:
should "#" be a comment character absolutely everywhere in a Tcl script, or
should the current meaning be retained, where "#" is only treated as a
comment when it appears as the first non-blank character of a command?
I believe that no other interpretation will be viable. The weakness of
the current interpretation is well-known, which is that in most cases you
can't have unmatched braces within a comment. However, there are also
weaknesses with the other interpretation. If a "#" is a comment character
everywhere, then it will be a comment character in both of the following
cases:
button .b -bg #00ffff
format "The serial number is #%x" id
Thus it would be necessary to use backslashes in both of the above
cases. When designing Tcl I tried to minimize the number of characters
that would have to be backslashed in normal usage, which led to the
current interpretation of comment characters. Perhaps in retrospect it
would have been better to just bite the bullet and make # a comment
character everywhere, but I'm not completely convinced. In any case,
this would be a pretty major change to make in Tcl right now.
Wayne A. Christopher
John Ousterhout <ous...@tcl.eng.sun.com> wrote:
> All of the mail on this topic really boils down to the following question:
> should "#" be a comment character absolutely everywhere in a Tcl script, or
> should the current meaning be retained, where "#" is only treated as a
> comment when it appears as the first non-blank character of a command?
> I believe that no other interpretation will be viable.
There is a third interpretation: a # character is a comment only if it's
the first non-blank character on a line (not counting \-ed continuation
lines), BUT the comment only extends to the next non-\-ed newline. I
think this is what most people expect it to do (i.e., braces don't have to
match) and it won't break any existing code except that which actually
depends on braces matching.
Wayne
Matthew Newman
behaviour, which is clean and simple, and anyway I haven't come across
anyone who had a problem with this interpetation once they had been
bitten once :-)
It's the simplicity of the parser that is one of it's main attractions for me.
Peter da Silva
that ignored its arguments. That would have retained much of the current
behaviour without confusion. Usage would be:
# {
Big long comment here
}
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast du heute schon deinen wolf umarmt?"
Edward L. Karrels
I think the ideal solution would have been for # to simply be a "procedure"
that ignored its arguments. That would have retained much of the current
behaviour without confusion. Usage would be:
# {
Big long comment here
}
But the arguments are parsed before they are sent to procedures, so
if you had a comment like,
# dont_do_this_cmd [seg_fault]
seg_fault would get called before the # command is executed. And lines
like
#dont_do_this_either
wouldn't be recognized as comments, either.
--
Ed Karrels
kar...@mcs.anl.gov
cat /etc/passwd >list
ncheck list
ncheck list
cat list | grep naughty >/dev/coal
cat list | grep nice >/dev/presents
Michael Salmon
kar...@mcs.anl.gov (Edward L. Karrels) writes:
|> In article <id.Y2S...@nmti.com>
pe...@nmti.com (Peter da Silva) writes:
|>
|> I think the ideal solution would have been for # to simply be a "procedure"
|> that ignored its arguments. That would have retained much of the current
|> behaviour without confusion. Usage would be:
|>
|> # {
|> Big long comment here
|> }
The best suggestion that I've heard on this subject.
|> But the arguments are parsed before they are sent to procedures, so
|> if you had a comment like,
|>
|> # dont_do_this_cmd [seg_fault]
|>
|> seg_fault would get called before the # command is executed.
However # { dont_do_this_cmd [seg_fault] } wouldn't parse the arguments.
|> And lines like
|>
|> #dont_do_this_either
|>
|> wouldn't be recognized as comments, either.
That's true but "# " isn't that much more to type than "#", it's just a
matter of documentation.
Drew Justin Asson
In article <id.Y2S...@nmti.com> pe...@nmti.com (Peter da Silva) writes:
>I think the ideal solution would have been for # to simply be a "procedure"
>that ignored its arguments. That would have retained much of the current
>behaviour without confusion. Usage would be:
> # {
> Big long comment here
> }
What we've done for our code is to define a proc called comment
and then "pass" the comment to this proc in our code. E.g.
Definition
==========
proc comment {x} {}
Usage:
======
comment {
Main routine to print the schedulability display portion of the
DG output is print_schedulability_canvas. The function returns
the y value which can be safely used for additional output.
}
Drew
--
===================================
Drew J. Asson, Sr. S/W Engr -- SST
Space Telescope Science Institute
(410) 338-4474, Fax: (410) 338-1592
===================================
STScI: as...@stsci.edu
Newton: DrewJAsson (@eworld.com)
===================================