Why does Tcl inadvertantly recognize a "{" inside a comment?!?!?
James C. Bach
I had a "bug" that has just driven me crazy for about 15 minutes . . .
and, as it turns-out, it seems to be a "bug" in Tcl itself . . .
NOT my code.
I had a perfectly working "foreach" loop . . .
as I added some code, looking for a string containing a "{" character,
I added a comment mentioning that we're looking for "bla bla {".
Booom . . . I thusly get a "missing close-brace" error dialog. . .
I hunt around the new code I added, trying to find where I had ooops'd,
and after fiddling-around, decided it was all OK. I deleted the "{"
from the comment (it is a line that starts with a "#" sign, not a
comment
after a chunk of code), and all was well.
WHY on earth does Tcl get confused just because this "special character"
is present inside something that is obviously a comment?!?!?
BTW, I'm using Tcl v8.2 on Win95 . . .
Also, one work-around I found was to place a closing brace "}" at the
end of the comment line . . . to fake-out Tcl's erroneous brace-counter;
it looks odd, but at least I can have my comment show that I'm looking
for "bla bla {" in the code below.
--
James C. (Jim) Bach I am Saber of Borg.
Sr. Project Engineer Resistance is V/I!
Elect'l Simulation & Analysis Prepare to be simulated!
Delphi Delco Electronics Systems ***ERROR "ALG_SINGULAR_JACOBIAN"***
Kokomo, IN, USA (765)-451-0455 Node/subsystem with no connection
http://eit.delcoelect.com/~jcbach to the reference (collective).
mailto:jcb...@eng.delcoelect.com Oh . . . never mind!
Don Porter
> WHY on earth does Tcl get confused just because this "special character"
> is present inside something that is obviously a comment?!?!?
For a full discussion, please see
http://purl.org/thecliff/tcl/wiki/462.html
The answer to WHY is that Tcl has no reserved words and no builtin
language constructs. Tcl has only commands. All Tcl commands are
on an equal footing. This makes it very easy to extend Tcl with
new commands and replacements for existing commands. It also means
the Tcl interpreter has no idea that [proc] happens to be a command
which creates new commands, or that one of the arguments to the
[foreach] command is going to be a Tcl script. Without that kind of
contextual knowledge, it is not possible for the Tcl interpreter
to decide what strings are "obviously" a comment, rather than just
a data value.
Instead the Tcl interpreter parses scripts by the very simple rules
documented in the Tcl(n) man page. Rule 5 governs the treatment
of braces as quoting characters.
--
| Don Porter, D.Sc. Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
|______________________________________________________________________|
Andreas Leitgeb
yet another one stumbling over the shortcoming of #-style comments ...
Bryan Oakley
news:3816FB1D...@eng.delcoelect.com...
> WHY on earth does Tcl get confused just because this "special character"
> is present inside something that is obviously a comment?!?!?
It is a side effect of the fundamental design of tcl. It is because of this
feature that one can do something like this:
if {$whatever} {return; # we're done}
If it weren't for the way tcl parses data, the above would have to be
written on several lines.
That, in and of itself, isn't justification for it. It merely points out
that the feature can be useful.
There was a large discussion on this issue within the last month. If you
really want to get all the skinny on this feature, check your favorite
newsgroup archive.
Roy Terry
Also, I suspect all the responses saying that it's a great
feature may not be welcome either.
Here's how I've made peace with the claims that the documentation
is correct:
The body of a procedure is simply an argument to the proc command.
Therefore NEVER refer to words inside the body of a procedures as
commands. If you obey this rule then the documentation is indeed
correct. You can prove this by typing
# {
to the Tcl shell and notice that the unbalanced { is ignored.
-Roy
"James C. Bach" wrote:
>
> I had a "bug" that has just driven me crazy for about 15 minutes . . .
> and, as it turns-out, it seems to be a "bug" in Tcl itself . . .
> NOT my code.
>
> I had a perfectly working "foreach" loop . . .
> as I added some code, looking for a string containing a "{" character,
> I added a comment mentioning that we're looking for "bla bla {".
> Booom . . . I thusly get a "missing close-brace" error dialog. . .
> I hunt around the new code I added, trying to find where I had ooops'd,
> and after fiddling-around, decided it was all OK. I deleted the "{"
> from the comment (it is a line that starts with a "#" sign, not a
> comment
> after a chunk of code), and all was well.
>
> WHY on earth does Tcl get confused just because this "special character"
> is present inside something that is obviously a comment?!?!?
>
Andreas Leitgeb
> This behavior is extremely annoying to new-comers to Tcl.
> Also, I suspect all the responses saying that it's a great
> feature may not be welcome either.
I totally agree.
It is a major design-flaw of #-style-comments, that they "behave"
differently inside or outside of braced blocks.
Of course, this is not exactly correct, because not the comment's
behaviour is different, but rather there is an gross inconsistency between
the algorithm that finds the matching close-brace and the way single
braces are handled when parsing ("executing") a comment.
The solution is NOT to change the algorithm for finding the matching
close-brace (as most new-comers think), but rather make #-parsing
consistent with it.
If #-comments would generally enforce balanced braces, then it would be
much clearer. It would be possible then to comment-out a whole
proc-definition with only one #-char, but on the other hand:
# if 0 {
blah
# }
would behave differently than it does now.
This, of course, would break lots of legacy-code, and therefore
has no chance of ever getting done. (although other changes, that tcl
has undergone so far were not so keen on keeping backwards-compatibility)
For the originator of this thread (and originators of similar threads),
consistent brace-handling inside #-comments would very likely have avoided
the confusion.
PS: End of January I'll take part in a perl-class, after that I'll decide
for myself, whether Tcl is still the "lesser evil" or not ;-)
laurent....@cgi.ca
>
> PS: End of January I'll take part in a perl-class, after that I'll decide
> for myself, whether Tcl is still the "lesser evil" or not ;-)
>
Please let us know.
L
--
Penguin Power! Nothing I say reflects the views of my employer
Laurent Duperval mailto:laurent....@cgi.ca
CGI - FWFM Project Phone: (514) 350-3368
Stefaan A Eeckels
Andreas Leitgeb <a...@logic.at> writes:
> James C. Bach <jcb...@eng.delcoelect.com> wrote:
>> I added a comment mentioning that we're looking for "bla bla {".
>
block somewhere.
James needed only 15 minutes to get it. Pretty darn good,
I'd say.
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
In a world where everyone uses an alias, one's real identity is
the best disguise.
James C. Bach
> [foreach] command is going to be a Tcl script. Without that kind of
> contextual knowledge, it is not possible for the Tcl interpreter
> to decide what strings are "obviously" a comment, rather than just
> a data value.
>
> Instead the Tcl interpreter parses scripts by the very simple rules
> documented in the Tcl(n) man page. Rule 5 governs the treatment
> of braces as quoting characters.
According to Ousterhout's book:
Commands:
Commands are separated by newlines or semicolons. For example:
set a 24
set b 15
is a script with two commands separated by a newline character.
Comments:
If the first nonblank character if a command is #, the # and
ALL THE CHARACTERS FOLLOWING IT UP THROUGH THE NEXT NEWLINE are
treated as a comment and discarded.
So, when I create a chunk of code that reads:
set A [list Fe Fi Fo Fum]
#
# Write the contents to the screen, preceeded with "{".
#
foreach AA $A {
#
# Preceed each entry with "{" character.
#
puts "\{$AA"
}
it should spit-out:
{Fe
{Fi
{Fo
{Fum
Instead, I get:
Error in startup script: missing close-brace
while executing
"foreach AA $A"
Clearly the # signs in the above are comments . . . they each start on
a new line . . . the first non-blank character is a #, and all the
characters after it (on that line), including the "{" are supposed to
be construed as insignificant drivval (i.e. ignored) . . .
like one is used to in Basic, Perl, Unix script languages, etc.
The 'problem' is that the stuff inside the { } of the "foreach" loop
is actually a blob of stuff passed-into the "foreach" function for
parsing later . . . it's not interpreted in-place, like we see it.
The "{" in the 1st block of comments is interpretted correctly . . .
the "{" is ignored . . . the trouble is the "{" that's within the {}
that defines the guts of the foreach loop.
I must not be the only one who thinks this way . . . who interprets the
wording the way I do . . . the person who wrote the "Tcl Server" mode
for XEmacs colorizes my code the way I think it should work :-)
Don Porter
>> Instead the Tcl interpreter parses scripts by the very simple rules
>> documented in the Tcl(n) man page. Rule 5 governs the treatment
>> of braces as quoting characters.
[ Snip Ousterhout excerpt ]
James C. Bach <jcb...@eng.delcoelect.com> wrote:
> So, when I create a chunk of code that reads:
> set A [list Fe Fi Fo Fum]
> #
> # Write the contents to the screen, preceeded with "{".
> #
> foreach AA $A {
> #
> # Preceed each entry with "{" character.
> #
> puts "\{$AA"
> }
...
> The 'problem' is that the stuff inside the { } of the "foreach" loop
> is actually a blob of stuff passed-into the "foreach" function for
> parsing later . . . it's not interpreted in-place, like we see it.
So you do understand brace quoting. You just don't like it.
> I must not be the only one who thinks this way .
No, this confusion arises often, usually with people new to Tcl who have
previously used other languages which use a preprocessor or some
mechanism depending on special interpretation of certain "key words" to
strip comments. Tcl doesn't work that way.
In Tcl, [foreach] is just another command. It happens to take three
arguments. If you quote the third argument using an open curly brace,
you must follow the rules of brace quoting. I notice you did not
include any excerpts from Ousterhout on correct methods of brace
quoting. That's where you need to look.
I see that you backspace-quoted the open brace in the [puts] command.
> puts "\{$AA"
Why did you do that? It is a perfectly valid Tcl command without that
quoting:
puts "{$AA"
However, it lies inside the brace-quoted third argument to [foreach].
So the backspace-quoting is necessary in that context.
Backspace-quoting of the open brace inside the comment is necessary for
the exact same reason.
Donal K. Fellows
Andreas Leitgeb <a...@logic.at> wrote:
> It is a major design-flaw of #-style-comments, that they "behave"
> differently inside or outside of braced blocks.
Not *this* hobby-horse again! The problem is working out exactly
which braced thingy is a block of code (where you might want to treat
the # character specially) and which thingy isn't (where it is not a
good idea to do so for a great many reasons, backward compatability
being not least among them.)
"Real" comments are easily done with a pre-processor of some kind
(trivial to implement!) Anything else comes unstuck somewhere. I
think it is a small price to pay for being able to introduce
completely new commands and redefine existing ones.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
Don Porter
> "Real" comments are easily done with a pre-processor of some kind
> (trivial to implement!)
Just how trivial is it?
proc source {filename} {
set f [open $filename r]
set script [read $f]
close $f
# pre-process $script however you like
eval $script
}
This (plus error handling) is close, but I don't think it will handle
[info script] inside the evaluation of $script correctly. Is there
any way to do that using a [proc]? Or must replacements for [source]
be coded in C? Is this a weakness in the core that should be fixed?
Bryan Kelly
RE:
>Comments:
>If the first nonblank character if a command is #, the # and
>ALL THE CHARACTERS FOLLOWING IT UP THROUGH THE NEXT NEWLINE are
>treated as a comment and discarded.
I started a thread on this not long ago, and it was obvious that I was not
the first, and you will not be the last.
I really like Expect and TCL, but this is a tremendous problem that the
authors and followers will not admit to. If you are willing to engage and
debate the point, there will be hoards of people telling you that this
action is great and should be kept and fixing it would break other stuff,
and all kinds of garbage. (Just watch the responses to this post.)
In my opinion, and in the opinions of quite a few others, CRAP!!!! To
evaluate a brace within a comment and fail a script because of a misplaced
brace in a comment is pure garbage. And as I quoted from your post, the
documents say they won't be evaluated. Doesn't matter. All braces seem to
be evaluated.
HOWEVER: That is the way it is and you are going to just have to live with
it. When you want to comment out a section because you introduced a nesting
error in your latest version, don't comment it out, you must cut it out
completely. If you really want that brace in the output statement, then
black-slash it (I think that was mentioned).
Good luck (as he ducks and runs for cover),
Bryan
Cameron Laird
In article <NMLT3.22729$23.11...@typ11.nn.bcandid.com>,
Bryan Kelly <kel...@brevard.net> wrote:
.
[strong words]
.
.
>it. When you want to comment out a section because you introduced a nesting
>error in your latest version, don't comment it out, you must cut it out
>completely. If you really want that brace in the output statement, then
.
.
I illustrate an alternative:
proc do {} {
some stuff
more stuff
a block of {
things
}
if 0 {
a block {
to be commented out
}
}
ending stuff
}
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX
Andreas Leitgeb
you quoted the wrong part of my posting ...
> which braced thingy is a block of code (...) and which thingy isn't ...
This is not the issue ...
the new-comers' inability to realize that _all_ braced thingies
are primarily _not_ code: that is the issue.
from new-comers' point of view the formulation: "where tcl expects (...)
a command" is almost never correctly grasped. the only reason, why there
are not even more "#-bug" postings is that many of the newcomers happen
to stumble over such a thread before they happen to get into the
situation of "commenting out a brace".
The choice is between having at least one such thread pending all the time
(as it happens now), versus adding some (redundant) remark/reminder about
the nature of braced blocks and its consequence for the parsing of #'s to
the No.1-language-bible (the manpage for "Tcl" ;-)
The reason, why I think that this is the source of the problem, is that
I've never read anyone complain about a #-comment not being ignored in a
NON-script-context. (so they DID read the "where a command is expected",
but missed its point.)
The switch-body-#ers are a different pair of shoes ;-)
> "Real" comments are easily done with a pre-processor of some kind
> (trivial to implement!)
see other followup for the "triviality" of pre-processing ...
I'd love, if it really were that easy to re-program "source"
with a tcl-proc.
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Bryan Oakley
news:7vn3rf$bvc$1...@m1.cs.man.ac.uk...
> In article <7v9aem$nri$1...@scesie13.sie.siemens.at>,
> Andreas Leitgeb <a...@logic.at> wrote:
> > It is a major design-flaw of #-style-comments, that they "behave"
> > differently inside or outside of braced blocks.
> [...]
>
> Not *this* hobby-horse again! The problem is working out exactly
> which braced thingy is a block of code (where you might want to treat
> the # character specially) and which thingy isn't (where it is not a
> good idea to do so for a great many reasons, backward compatability
> being not least among them.)
>
> think it is a small price to pay for being able to introduce
> completely new commands and redefine existing ones.
And, of course, people are free to use a preprocessor for their code if they
wish. Nothing in the rulebook prevents that. That's the part of the debate
that gets me. Why don't people who want C-like comments just use cpp on
their source code? Voila! Instant "C-like" comments. As well as #defines and
all of the other C-isms.
I know some of the answers -- it's not portable or requires an extra step,
but I suspect the vast majority of people who want this are working on code
that isn't released publicly anyway, so how they markup their code is their
own business. And with wrapping becoming more popular, and thus requiring an
extra step to finalize the code, it's not really much of a burden to run cpp
just before running the wrapping process.
Bryan Oakley
news:NMLT3.22729$23.11...@typ11.nn.bcandid.com...
> I really like Expect and TCL, but this is a tremendous problem that the
> authors and followers will not admit to.
How can it be considered a tremendous problem if (picks a number out of thin
air) half a million programmers over a decade have peacefully co-existed
with the current commenting scheme? A minor problem to people new to the
language, perhaps, but I fail to see how it is a *tremendous problem".
Face it -- the commenting scheme isn't perfect, but it almost certainly
isn't going to change unless *you* or someone else who feels it is a
tremendous problem comes up with something noticibly better. Not merely
different, but _better_. And not just an idea for something better, but
actual code to implement it.
In the mean time, perhaps the best solution is to use cpp on your own code,
then you can use C-style comments wherever you like. Problem solved.
Seriously -- is there some reason you don't do this? If the built-in
comments are an impediment to you doing your job, you really should seek out
a pre-processor.
Don Porter
> if 0 {
> a block {
> to be commented out
> }
> }
> ending stuff
> }
That "alternative" doesn't achieve the stated goal of allowing a
non-escaped open brace inside a "comment." People complain about
proc do {} {
# {
}
raising an error because Tcl requires balanced braces inside words
quoted by braces.
Replacing '#' comments with 'if 0' "comments" doesn't change that.
The following code will also raise an error.
proc do {} {
if 0 {
{
}
}
Tcl works the same way in both cases. It's the user's *expectations*
which are adjusted. The "alternative" is not an alternative at all,
but a way of removing the comment red herring from the discussion.
The confusion is not about comments at all, but about brace quoting.
Don Porter
>> "Real" comments are easily done with a pre-processor of some kind
>> (trivial to implement!)
Don Porter <d...@cam.nist.gov> wrote:
> proc source {filename} {
> set f [open $filename r]
> set script [read $f]
> close $f
> # pre-process $script however you like
> eval $script
> }
>
> This (plus error handling) is close, but I don't think it will handle
> [info script] inside the evaluation of $script correctly.
Answering my own question, I suppose one could re-define the [info]
command before evaluating the script, and define it back afterwards.
In my book, that takes it out of "trivial" range, but it's doable.
Now, if only the Tcl library evaluated an initialization file in the
user's home directory, we could make everyone happy. The tclsh
application evaluates ~/.tclshrc, but only in interactive mode.
If the Tcl library always evaluated ~/.tclrc, even when embedded in
an application other than tclsh, then those who wanted pre-processor
style comments could put a "trivial" redefinition of [source] in
their ~/.tclrc file and see how it works for them.
Bryan Kelly
Hey, nice name there. Where did you pick it up? <grin>
I am going to have to disagree with you on a few points.
RE:
>
>How can it be considered a tremendous problem if (picks a number out of
thin
>air) half a million programmers over a decade have peacefully co-existed
>with the current commenting scheme? A minor problem to people new to the
>language, perhaps, but I fail to see how it is a *tremendous problem".
>
I hold that, No, a half million do not peacefully co-exist. I don't keep up
with this news group regularly, but every time I do tune in, there is a
thread on comments and braces. Right now, I count at least three separate
threads. (could it be four, I think I saw one more that came in as I was
writing.)
The ideas are not new. Just ignore everything after the comment symbol. As
I mentioned in another thread, all assemblers, FORTRAN, Pascal, all versions
of Basic, and others I don't know about do not process code that is in a
comment. The authors of TCL had to expect extra effort to introduce this
defect.
What,..., defect? Yes. Look at all the agony it has caused. I have read
the comments and I don't see that processing the braces in a comment line
has provided any advantage.
>
>In the mean time, perhaps the best solution is to use cpp on your own code,
>then you can use C-style comments wherever you like.
If I am going to run a pre-processor, when why run a interpreter? Crumm.
I'll just run a full blown compiler and be done with it. I don't consider
that a viable alternative for a nano-second.
When I am developing code, I work incrementally. If I am building a
complicated loop, I will make the loop do its looping without doing anything
inside but telling me how its looping. That way I verify that the loop is
correct and don't worry about the contents yet. In the same manner, if I
introduce a defect (or am hunting down someone else's defect), I like to cut
out code by commenting it and test a smaller part. When I have a nesting
problem with unbalanced braces, this doesn't work. It should work. It does
for every other language. Why should the tcl developers spend extra effort
to introduce this odd ball behavior?
One more item, (referencing comments elsewhere to not call them comments) if
the comments have their name changed to something else, the rose will smell
the same. If the # character mostly acts like a comment, people will think
of it as a comment no matter what the documents say. The griping and
complaining will continue.
Bryan
Alexandre Ferrieux
>
> Now, if only the Tcl library evaluated an initialization file in the
> user's home directory, we could make everyone happy. The tclsh
> application evaluates ~/.tclshrc, but only in interactive mode.
> If the Tcl library always evaluated ~/.tclrc, even when embedded in
> an application other than tclsh, then those who wanted pre-processor
> style comments could put a "trivial" redefinition of [source] in
> their ~/.tclrc file and see how it works for them.
Oh, but this is easy to emulate: write a few-liner shell script, name
it "tclsh" (same for "wish"), put it in the PATH.
In this script you'll say somthing like:
#! /bin/sh
rc=$HOME/.tclrc
if [ -r $rc ]
then
exec true-tclsh $rc "$@"
else
exec true-tclsh "$@"
fi
Of course, the .tclrc must then end with:
set scr [lindex $argv 0]
set argv [lrange $argv 1 end]
incr argc -1
source $scr
-Alex
Andreas Leitgeb
>> Now, if only the Tcl library evaluated an initialization file in the
>> user's home directory, we could make everyone happy. The tclsh
>> application evaluates ~/.tclshrc, but only in interactive mode.
>> If the Tcl library always evaluated ~/.tclrc, even when embedded in
>> an application other than tclsh, then those who wanted pre-processor
>> style comments could put a "trivial" redefinition of [source] in
>> their ~/.tclrc file and see how it works for them.
to be spread that silently rely on certain "features" in the users
home-directory ... such as a to-be-preprocessed prog, that relies
on .tclrc to define the pre-processor ...
[ having ~/.tclrc "auto-sourced" ]
> #! /bin/sh
> rc=$HOME/.tclrc
> if [ -r $rc ]
> then
> exec true-tclsh $rc "$@"
> ...
... and say goodbye to interactive tclsh-sessions ...
or is there a way, to tell tclsh to re-enter interactive-mode
(from within the script) if a script has been passed to tclsh ?
Bryan Oakley
> Good Day Bryan,
> Hey, nice name there. Where did you pick it up? <grin>
I don't know. Some days it seems like I've had it my whole life.
> I am going to have to disagree with you on a few points.
Great! I worry about people who agree with everything I say.
James C. Bach
> So you do understand brace quoting. You just don't like it.
ding ding ding :-)
Of course, if the text-editor I'm using (Xemacs) would colorize the
code the way Tcl interprets the code . . . then I'd instantly see that
I'm going to step on a land-mine . . . and I wouldn't be such a whiner
:-)
Does anyone out there use a syntax-colorizing editor that correctly
catches this 'nuance' of Tcl??? If so, what's the name of it, so I
might consider switching . . . I'm currently in the process of
evaluating programming editors for use in writing code in the unique
language of our electrical simulator (where I'll have to write the
colorization rules myself) . . . and I'm going to be sure that the
editor I pick does a good job with Tcl/Tk as well . . . since the
simulator's macro language is a superset of Tcl/Tk . . .
FWIW . . . regarding syntax colorization nuances . . .
So far I've collected demo copies of 10 different 'programmers editors',
all of which claim to do syntax colorization and user-customizable
menus. I've installed and fiddled-with 3 of them . . . looking soley
at the colorization ability of each . . . only 1 (so far) does exactly
what I want . . . CodeWright . . . SlickEdit and UltraEdit miss the
mark ONLY because there is a certain category of words (system 'units')
that I only want colorized when they appear after another certain word.
Only CodeWright (of the 3 I've tested so far) let me define the words
in the wordlists as multiple words surrounded with "quotes" . . .
for instance, I want to colorize "var v" . . . which, in this simulator,
means "system matrix VARiable called V". In UltraEdit and SlickEdit
I have to define "var" and "v" separately, and thus, any occurance of
either gets colorized . . but there are other occurances of 'v' in
the code that do not need to be colorized . . .
Jeffrey Hobbs
...
> Does anyone out there use a syntax-colorizing editor that correctly
> catches this 'nuance' of Tcl??? If so, what's the name of it, so I
I use the colorization in emacs with satisfaction. Most here are
comfy with that. There are some here that really like CodeWright.
Others still stick with vi (of course, we wonder about their sanity
in general...).
--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.
Alexandre Ferrieux
>
> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> >> Now, if only the Tcl library evaluated an initialization file in the
> >> user's home directory, we could make everyone happy.
> >>
Ahem... You're quoting Don her. Why don't you write his name instead ?
;-)
> the approach is good, but it's likely to cause lots of programs
> to be spread that silently rely on certain "features" in the users
> home-directory ... such as a to-be-preprocessed prog, that relies
> on .tclrc to define the pre-processor ...
I have some sympathy for this remark. I only wanted to tackle the
technical challenge, without thinking about the politics. Thanks for
waking me up !
So yes, my preference would go instead to saying
#! /bin/sh
#\
exec my-special-tclsh-with-rc-file "$@"
at the beginning of all the scripts that need it. Yes, this must be in
the exec header because otherwise the greedy compilation would choke on
the first unbalanced #...{ before the preprocessor code gets a chance to
run.
> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> [ having ~/.tclrc "auto-sourced" ]
> > #! /bin/sh
> > rc=$HOME/.tclrc
> > if [ -r $rc ]
> > then
> > exec true-tclsh $rc "$@"
> > ...
> ... and say goodbye to interactive tclsh-sessions ...
Okay, this code needs some improvements, like checking the no-argument
(interactive) case.
> or is there a way, to tell tclsh to re-enter interactive-mode
> (from within the script) if a script has been passed to tclsh ?
You can somewhat emulate that with an [eval] loop. But a better
approach in this context would be instead to start it in interactive
mode directly, and rely on the existing .tclshrc to source the .tclrc
(possibly conditionally, with some env variable or whatever) !
> Hi! I'm a signature virus! Copy me into your signature file to help me spread!
I like this one :)))
-Alex
Martin Tharby Jones
> Of course, if the text-editor I'm using (Xemacs) would colorize the
> code the way Tcl interprets the code . . . then I'd instantly see that
> I'm going to step on a land-mine . . . and I wouldn't be such a whiner
> :-)
>
> Does anyone out there use a syntax-colorizing editor that correctly
> catches this 'nuance' of Tcl??? If so, what's the name of it, so I
> might consider switching . . . <snip>
Have you considered NEdit? The highlighting is done using regular
expressions so is easy to customize. The supplied pattern for comments is
simplistic: from "#" to end of line so it will not show badly placed
comments. Can anyone think of a regular expression that matches the start
of a command constraint on comments? it's got me stumped!
> NEdit Version 5.0.2
> March 11, 1998
>
> Copyright (c) 1992, 1993, 1994, 1996, 1997, 1998
> Universities Research Association, Inc.
> All rights reserved.
>
> NEdit was written by Mark Edel, Joy Kyriakopulos, Arnulfo
> Zepeda-Navratil, Suresh Ravoor, Donna Reid, and Jeff Kallenbach, at
> Fermi National Accelerator Laboratory*.
>
> The regular expression matching routines used in NEdit are adapted
> (with permission) from original code written by Henry Spencer at the
> University of Toronto.
>
> Syntax highlighting patterns were contributed by: Simon T. MacDonald,
> Maurice Leysens, Matt Majka, Alfred Smeenk, Alain Fargues, Christopher
> Conrad, Scott Markinson, Konrad Bernloehr, Ivan Herman, Patrice Venant,
> Christian Denat, Philippe Couton, Max Vohlken, and Markus
> Schwarzenberg.
>
> NEdit sources, executables, additional documentation, and contributed
> software are available from ftp.fnal.gov in the /pub/nedit directory.
>
> Send questions or comments to: nedit_...@fnal.gov.
>
> Mark Edel
> ed...@fnal.gov
> Fermi National Accelerator Laboratory
> P.O. Box 500
> Batavia, IL 60148
--
Martin Jones RDEL
Western Road,
E-mail: martin...@rdel.co.uk Bracknell,
Telephone: +44 (0)1344 385279 Berkshire, RG12 1RG,
Fax: +44 (0)1344 868829 England.
Stefaan A Eeckels
"James C. Bach" <jcb...@eng.delcoelect.com> writes:
>
> Does anyone out there use a syntax-colorizing editor that correctly
> catches this 'nuance' of Tcl??? If so, what's the name of it, so I
> might consider switching . . .
appear in comments, by making them look like the "TODO" stuff.
Below are the relevant lines from the "tcl.syn" file:
---------cut here--------------
sy match tclTodo contained "\s*{\s**"
sy match tclTodo contained "\s*}\s*"
sy keyword tclTodo contained TODO
sy keyword tclTodo contained FIXME
sy keyword tclTodo contained XXX
sy region tclComment start="^\s*\#" end="$" contains=tclTodo
sy region tclComment start=/;\s*\#/hs=s+1 end="$" contains=tclTodo
...
hi link tclTodo Todo
---------cut here--------------
It's enough to draw my attention to the braces when I'm commenting
out code.
Stefaan A Eeckels
Jeffrey Hobbs <jeffre...@scriptics.com> writes:
>
> I use the colorization in emacs with satisfaction. Most here are
> comfy with that. There are some here that really like CodeWright.
> Others still stick with vi (of course, we wonder about their sanity
> in general...).
Donal K. Fellows
> engage and debate the point, there will be hoards of people telling
> you that this action is great and should be kept and fixing it would
> break other stuff, and all kinds of garbage. (Just watch the
> responses to this post.)
You can always put your own pre-processing stage in (there are several
examples of this in assorted DejaNews threads.) Otherwise, how
exactly do you propose "fixing" it while still preserving the many
other good properties of the language?
> In my opinion, and in the opinions of quite a few others, CRAP!!!!
> To evaluate a brace within a comment and fail a script because of a
> misplaced brace in a comment is pure garbage. And as I quoted from
> your post, the documents say they won't be evaluated. Doesn't
> matter. All braces seem to be evaluated.
No. The following Tcl script is *valid*. Type it in at the prompt or
put in a file and [source] it and it *will* work.
# {{{{{{{{
puts wibble
# }{}{{}}{}}}
puts foobar
The problem that most of the people who complain about this issue have
(and I note that this problem is *not* part of the universal Tcl
experience) is that they expect Tcl quoting to be more like that found
in other languages. They seem to expect that Tcl "thinks" about their
code in exactly the same way that they do. What puzzles me is why
they get so worked up when they find this isn't so...
laurent....@cgi.ca
> I use the colorization in emacs with satisfaction. Most here are
> comfy with that. There are some here that really like CodeWright.
> Others still stick with vi (of course, we wonder about their sanity
> in general...).
>
Yeah, they should really be using Vim (http://www.vim.org/)
Paul Duffin
>
> or is there a way, to tell tclsh to re-enter interactive-mode
> (from within the script) if a script has been passed to tclsh ?
>
I once created a version of tclsh which would allow you to reenter
interactive mode after your program had been executed. What I did was
simply test the value of "tcl_interactive" after the file had been
sourced and if it was set to 1 I jumped over the exit to the
Tcl_SourceRCFile.
This all worked perfectly, as part of a system to replace Tcl's event
loop (or lack of one) with Tk's event loop when Tk was dynamically
loaded. Still unsure as to the best way to handle the event loop issue.
--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880
Donal K. Fellows
Martin Tharby Jones <martin...@rrds.co.uk> wrote:
> "James C. Bach" wrote:
>> Does anyone out there use a syntax-colorizing editor that correctly
>> catches this 'nuance' of Tcl??? If so, what's the name of it, so I
>
> Have you considered NEdit? The highlighting is done using regular
> expressions so is easy to customize. The supplied pattern for
> comments is simplistic: from "#" to end of line so it will not show
> badly placed comments. Can anyone think of a regular expression that
> matches the start of a command constraint on comments? it's got me
> stumped!
Try looking at http://www.cs.man.ac.uk/~fellowsd/tcl/tcl-font.el which
is a more sophisticated colourizer for emacs (all versions I can lay
my hands on easily) and which has appreciably better understanding of
when something is a comment and when it isn't. Not that it is perfect
though - perfection is at best incredibly difficult...
Gawain Lavers
I have to admit, I'm getting hooked on Nedit. The commands are so
simple and cover everything I need to do, as opposed to emacs, where the
commands cover a million things I'll never do and are thusly an order of
magnitude more complicated. Still, the highlighting bugs me. Have you
noticed that specifying a color (#ffffff for example) is considered the
start of a comment. And what to do about multi line strings?
Especially if they contain scripts for later evaluation...
lvi...@cas.org
According to Gawain Lavers <gaw...@torque.com>:
:I have to admit, I'm getting hooked on Nedit. The commands are so
I have never used Nedit - not even certain where to find Nedit (someone
want to provide me a URL? I'll add an entry to the software catalog).
I don't know if it is platform independant or specific (if specific and
it doesn't work on Solaris, I won't be able to test it out...)
:magnitude more complicated. Still, the highlighting bugs me. Have you
:noticed that specifying a color (#ffffff for example) is considered the
:start of a comment. And what to do about multi line strings?
I see similar problems with other syntax oriented programs like a2ps (which
pretty prints text to PostScript). What do you do when your data looks
just like code - oh wait, that's the whole reason for this thread <smile>?
If people were willing to code "like other languages" then I would say
"just surround the color strings with quotes" - which would help in
some cases - wouldn't help if someone wanted to code colorize code being
stored in a list or string, but otherwise...
--
<URL: mailto:lvi...@cas.org> Quote: Pikachu, I choose you!
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Donal K. Fellows
Gawain Lavers <gaw...@torque.com> wrote:
> I have to admit, I'm getting hooked on Nedit. The commands are so
> commands cover a million things I'll never do and are thusly an order of
> noticed that specifying a color (#ffffff for example) is considered the
> start of a comment. And what to do about multi line strings?
Hah! Emacs always could handle multi-line strings, and my highlighter
gets comments (almost[*]) right, and certainly far better than the
default scheme which was based on something utterly different...
Donal.
[* Completely right is probably not possible with a reasonable amount
of effort. It is even possible it is not possible to solve without
a solution to the Halting Problem... ]
Darren New
> [* Completely right is probably not possible with a reasonable amount
> of effort. It is even possible it is not possible to solve without
> a solution to the Halting Problem... ]
If someone were to come up with a 100% reliable way of colorizing comments,
you could just plug that algorithm into Tcl to ignore braces inside
comments. Then you wouldn't need to colorize them to catch mismatched
braces.
proc x {} {
# This is a comment
}
$proc y {} {
# Is this a comment?
}
It'll never happen.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Java leads to JavaScript,
JavaScript leads to Flash,
Flash leads to ... Suffering.
Martin Tharby Jones
> According to Gawain Lavers <gaw...@torque.com>:
> :I have to admit, I'm getting hooked on Nedit. The commands are so
>
> I have never used Nedit - not even certain where to find Nedit (someone
> want to provide me a URL? I'll add an entry to the software catalog).
>
http://www.fnal.gov/fermitools/abstracts/nedit/abstract.html
> I don't know if it is platform independant or specific (if specific and
> it doesn't work on Solaris, I won't be able to test it out...)
Uni*/X11 and windoze I think.
Jan Nijtmans
> I have never used Nedit - not even certain where to find Nedit (someone
> want to provide me a URL?
http://www-pat.fnal.gov/nirvana/nedit.html
> I'll add an entry to the software catalog).
> I don't know if it is platform independant or specific (if specific and
> it doesn't work on Solaris, I won't be able to test it out...)
Many precompiled binaries are available, for Solaris as well.
--
Jan Nijtmans, CMG Arnhem B.V.
email: j.nij...@chello.nl (private)
jan.ni...@cmg.nl (work)
url: http://purl.oclc.org/net/nijtmans/
Donal K. Fellows
<boa...@vignette.com> writes
>Why don't people who want C-like comments just use cpp on
>their source code?
Because cpp is pretty horrible itself. But the general point is taken
as intended. Anyone that wants "proper" comments can use a separate
parsing stage to strip them out. And liberal application of "make" can
make stripping out those comments effectively automatic. Or you could
use the following code...
rename ::source ::original_source
proc source {filename} {
if {
[file exist $filename] &&
[string equal .tclp [file extension $filename]]
} then {
# Watch out for arbitrary OS filename length restrictions...
set newfile $filename_temporary
preprocess $filename $newfile
set filename $newfile
}
uplevel [list ::original_source $filename]
if {[info exist newfile] && [file exist $newfile]} {
file delete $newfile
}
}
proc preprocess {infile outfile {pat "\n#\[^\n]*\n"} {rep "\n"}} {
set fin [open $infile r]
set len [file size $infile]
regsub -all $pat [read $fin $len] $rep data
close $fin
set fout [open $outfile w]
puts -nonewline $fout $data
close $fout
}
Donal.
--
Donal K. Fellows (at home)
--
FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!!
Donal K. Fellows
<kel...@brevard.net> writes
>I hold that, No, a half million do not peacefully co-exist.
But quite a lot of us do. Just because you think there is a problem
doesn't mean that everyone does. If you have a concrete suggestion on
how to change things (i.e. some code) then feel free to post it and we
can have a discussion on that. However, it is the opinion of many in
this group that any change is going to be very difficult to get right...
>I don't keep up
>with this news group regularly, but every time I do tune in, there is a
>thread on comments and braces. Right now, I count at least three separate
>threads. (could it be four, I think I saw one more that came in as I was
>writing.)
And it is usually the same few people that are clamouring for change and
the same bunch of people saying it isn't necessary. :^)