man page syntax for +script
John Seal
(That's my story, and I'm sticking to it!)
The man pages for [bind] and [comm hook] both describe how you can
either replace the current script or append to it, but they give
slightly different syntaxes. [bind] says
bind tag ?sequence? ?+??script?
and [comm] says
::comm::comm hook event ?+? ?script?
with a space between the + and the script. In fact, both of them seem
to work with or without the space. But the syntax for [comm hook] makes
it appear that the + and the script are separate arguments, and that
caused me some confusion.
I'd successfully appended [bind] scripts before, but yesterday I was
trying to append a [comm hook] and getting the syntax wrong because of
the man page. If you separate the + and the script, it generates a "too
many arguments" error. My investigation led to great enlightenment in
the realization that my success with [bind] in the past was due to sheer
luck, because I fundamentally misunderstood the whole +script syntax!
Always before I'd written something like +[list cmd ...] or +{cmd} and
it worked for, but yesterday I wrote +{cmd "arg"} and it told me I had
extra characters after the close quote. I see why now, but it wasn't
immediately obvious yesterday in the heat of coding! At first I thought
it might be a bug in [comm], but the absence of any reports to that
effect made me think the problem must be a short circuit between the
chair and the keyboard. ;-)
Since I write {script ...} when I want to replace the script, and the
man page syntax makes it look like the + is "outside" the script, I just
naturally wrote +{script ...} and expected it to work. In fact, I
should have written {+script ...} or {+ script ...}, even though that
makes it look like the script is trying to execute [+script] or [+]!
I do think the [comm] man page syntax is wrong, or at least seriously
misleading. The [bind] man page, at first glance, doesn't seem to
permit a space, but since the script can contain whitespace I think it's
implied. As I said, both [comm] and [bind] are perfectly happy with or
without a space between the + and the rest of the script.
And to think, it's another whole month until my vacation....
Gerald W. Lester
> My spring fever continues...
> (That's my story, and I'm sticking to it!)
>
> The man pages for [bind] and [comm hook] both describe how you can
> either replace the current script or append to it, but they give
> slightly different syntaxes. [bind] says
>
> bind tag ?sequence? ?+??script?
>
> and [comm] says
>
> ::comm::comm hook event ?+? ?script?
>
> with a space between the + and the script. In fact, both of them seem
> to work with or without the space. But the syntax for [comm hook] makes
> it appear that the + and the script are separate arguments, and that
> caused me some confusion.
>
>
> I do think the [comm] man page syntax is wrong, or at least seriously
> misleading. The [bind] man page, at first glance, doesn't seem to
> permit a space, but since the script can contain whitespace I think it's
> implied. As I said, both [comm] and [bind] are perfectly happy with or
> without a space between the + and the rest of the script.
The man page may be wrong -- but it is not an issue of syntax, but rather
semantics. Tcl, before 8.5, only has eleven syntax rules and twelve rules
starting with 8.5 -- and "+" ain't one of them.
The plus is a semantic definition that these two unrelated commands put on
their last argument, expr has a very different semantic definition of "+".
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Dan Smart
It is so a question of syntax, and you would be wise to have read the
post before lecturing him. His issues isn't with the semantics of '+'
as applied to those commands: he knows "what putting a + before the
script does" (the semantics), and both commands define the effect
consistently. His issue is with the syntax, "where should he put the +
to get that effect", and the two commands define that inconsistently.
Note: the 11/12 rules of TCL syntax don't cover [expr] expressions
either, or regular expressions for that matter.
Dan "You keep using that word, I do not think it means what you think
it means" Smart
Gerald W. Lester
Dan I strongly suggest that you read his post again with an eye toward what
he is saying. Based on the next sentence in your reply. you have a
distorted view of what is syntax and what is semantics in Tcl. For at least
your benefit, I'm posting a detail explanation here.
> His issues isn't with the semantics of '+' as
> applied to those commands: he knows "what putting a + before the script
> does" (the semantics), and both commands define the effect consistently.
> His issue is with the syntax, "where should he put the + to get that
> effect", and the two commands define that inconsistently.
Where he needs to put the "+" is **NOT** a matter of Tcl syntax -- it is
**STRICTLY** a matter of the semantics that the command applies to its
arguments. Thus the two commands are allowed to define the semantics of the
"+" inconsistently, just as set and list define the semantics of their first
argument "inconsistently".
> Note: the 11/12 rules of TCL syntax don't cover [expr] expressions
> either, or regular expressions for that matter.
Duh -- that is because of how those commands, or any other command, apply a
meaning (or no meaning) to "+" is not a matter of syntax but rather purely
the semantics that each individual command applies to its argument.
In short, Tcl's syntax, all 11/12 rules of it, apply language wide -- and
that is *ALL* that applies language wide. Anything else that appears to is
either coincident or imitation. In fact from one installation/interpreter
(e.g. inside a safe interpreter) to the next you can not really count on all
of the "core" commands being there (e.g. exec may be missing) or have a
different semantics (e.g. proc may have been redefined to provide some type
of tracing or debugging).
Way too often people apply baggage of thinking way more is syntax in Tcl
that is really only semantics to Tcl. I think this is because of the large
amount of syntax other languages have -- this is a personal observation from
years of teaching Tcl and answering questions in the news group.
Don Porter
>> It is so a question of syntax, ...
Gerald W. Lester wrote:
> Way too often people apply baggage of thinking way more is syntax in Tcl
> that is really only semantics to Tcl.
I'll take Dan's side on this one.
Perhaps it's clearer if we explicitly notice there is language
syntax, command syntax, and command semantics.
set var "b"x
is an error because it breaks Tcl language syntax. No command
can look like that.
set var val bogus
is an error because it breaks the syntax of the [set] command.
It supplies too many arguments. The Tcl language permits a command
to take three arguments, but the additional syntax requirements of
[set] disallow it.
set 0 val
is an example where the semantics of [set] might be surprising to users
of langauges that force more semantic interpretation in the language
itself. No matter how much you might thinks "0" looks like an integer,
and is the wrong "type" to be taken as a variable name, Tcl does not
force the issue, and the semantics of the [set] command are to interpret
that argument as a variable name.
Roughly, "syntax" == what formats of input are valid.
"semantics" == what meaning/interpretation is assigned to valid inputs.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Gerald W. Lester
> Dan Smart wrote:
>>> It is so a question of syntax, ...
>
> Gerald W. Lester wrote:
>> Way too often people apply baggage of thinking way more is syntax in Tcl
>> that is really only semantics to Tcl.
>
> I'll take Dan's side on this one.
Don, I understand what you are saying but...
If that is the definition of "syntax" being used, then the original post of
the "disagreement" between the "+script" syntax of the two commands makes
less sense since comparing the syntax of two different commands
(particularly when one is non-core) is like comparing apples and oranges.
The only other possible reading I can get of the OP is a complaint that the
man pages are not the easiest to read docs in the world (which I think we
all agree with) -- but taking that reading leads me to think that the
OP thinks that the comm extension (which one is never mentioned) is part of
the core.
>
> Perhaps it's clearer if we explicitly notice there is language
> syntax, command syntax, and command semantics.
>
> set var "b"x
>
> is an error because it breaks Tcl language syntax. No command
> can look like that.
>
> set var val bogus
>
> is an error because it breaks the syntax of the [set] command.
> It supplies too many arguments. The Tcl language permits a command
> to take three arguments, but the additional syntax requirements of
> [set] disallow it.
>
> set 0 val
>
> is an example where the semantics of [set] might be surprising to users
> of langauges that force more semantic interpretation in the language
> itself. No matter how much you might thinks "0" looks like an integer,
> and is the wrong "type" to be taken as a variable name, Tcl does not
> force the issue, and the semantics of the [set] command are to interpret
> that argument as a variable name.
>
> Roughly, "syntax" == what formats of input are valid.
> "semantics" == what meaning/interpretation is assigned to valid inputs.
>
--
Dan Smart
> I do think the [comm] man page syntax is wrong, or at least seriously
> misleading. The [bind] man page, at first glance, doesn't seem to
> permit a space, but since the script can contain whitespace I think
> it's implied. As I said, both [comm] and [bind] are perfectly happy
> with or without a space between the + and the rest of the script.
If I've read the comm syntax excerpt correctly, they permit passing the
+ as a seperate argument before the script precisely because +{foo bar}
is invalid TCL syntax, and {+foo bar} is confusing and "hides" the '+'.
Hence your example could be written as
::comm::comm hook event + {cmd "arg"}
But that syntax certainly doesn't work with bind.
>
> And to think, it's another whole month until my vacation....
Dan "But I didn't try the comm example" Smart
Dan Smart
I did read his post, I also understand the difference between "syntax"
(how do I have to say something) and "semantics" (what does it mean).
You on the other hand appear more than a little confused.
>
>> His issues isn't with the semantics of '+' as applied to those
>> commands: he knows "what putting a + before the script does" (the
>> semantics), and both commands define the effect consistently. His issue
>> is with the syntax, "where should he put the + to get that effect", and
>> the two commands define that inconsistently.
>
> Where he needs to put the "+" is **NOT** a matter of Tcl syntax -- it
> is **STRICTLY** a matter of the semantics that the command applies to
> its arguments. Thus the two commands are allowed to define the
> semantics of the "+" inconsistently, just as set and list define the
> semantics of their first argument "inconsistently".
I thought I had pointed out that we weren't talking about the syntax of
TCL the language, but the syntax of two commands available (under
certain circumstances) within a tcl interpreter. How commands parse the
individual words that the TCL interpreter passes them as arguments has
nothing to do with TCL syntax, but it is syntax. I'll reiterate for
your benefit, and for any that you've confused, the *semantics* of '+'
for both commands are "append the script that follows", the syntax
question is "where do I place the '+' to get that effect".
Syntax: What are the rules of construction.
Semantics: What does the phrase thus constructed mean.
>
>> Note: the 11/12 rules of TCL syntax don't cover [expr] expressions
>> either, or regular expressions for that matter.
>
> Duh -- that is because of how those commands, or any other command,
> apply a meaning (or no meaning) to "+" is not a matter of syntax but
> rather purely the semantics that each individual command applies to its
> argument.
Both [expr] and [regexp] define the semantics (meanings) of individual
'symbols', and they also define the semantics (meanings) of collections
of 'symbols'. They also both specify a syntax which describes exactly
what constitutes a symbol, and how those symbols may be combined.
Neither syntax is identical to TCL's, although [expr] is very similar.
>
> In short, Tcl's syntax, all 11/12 rules of it, apply language wide --
> and that is *ALL* that applies language wide. Anything else that
> appears to is either coincident or imitation. In fact from one
> installation/interpreter (e.g. inside a safe interpreter) to the next
> you can not really count on all of the "core" commands being there
> (e.g. exec may be missing) or have a different semantics (e.g. proc may
> have been redefined to provide some type of tracing or debugging).
This is of course correct, but largely irrelevant. Having two commands
that expose different syntax to provide the same semantics is ugly,
which is in part what the OP was complaining about.
>
> Way too often people apply baggage of thinking way more is syntax in
> Tcl that is really only semantics to Tcl. I think this is because of
> the large amount of syntax other languages have -- this is a personal
> observation from years of teaching Tcl and answering questions in the
> news group.
I repeat: You *keep* using that word, I don't think it means what you
think it means.
Syntax: How do I say something.
Semantics: What does it mean.
Dan "You killed my father, prepare to die" Smart
Donald Arseneau
> he is saying. Based on the next sentence in your reply. you have a distorted
> view of what is syntax and what is semantics in Tcl.
>
> Where he needs to put the "+" is **NOT** a matter of Tcl syntax -- it is
> **STRICTLY** a matter of the semantics that the command applies to its
> arguments. Thus the two commands are allowed to define the semantics of the
> "+" inconsistently,
No, that is syntax.
If one command appended the script to the binding (as now) and
the other set the binding to "+" and the script, then that would
be a semantic difference.
Whether there is a space between the "+" and the script is
a syntactical difference, given that both commands purport to
do the same thing with the argument(s).
There is a lot more syntax in Tcl than the rules for parsing
what is a Tcl command or script.
I see where you are coming from, with the claim that arguments
are arguments, and each command takes arguments in the same way.
Any differences beyond that are differences in the meaning of the
arguments. But that way of thinking cuts Tcl off at the parser,
as if the commands of Tcl weren't part of the Tcl language.
--
Donald Arseneau as...@triumf.ca
Donald Arseneau
> Where he needs to put the "+" is **NOT** a matter of Tcl syntax -- it is
> **STRICTLY** a matter of the semantics that the command applies to its
> arguments. Thus the two commands are allowed to define the semantics of the
> "+" inconsistently
No, that is syntax.
If one command appended the script to the binding (as now) and
the other set the binding to "+" and the script, then that would
be a semantic difference.
Whether there is a space between the "+" and the script is
a syntactical difference, given that both commands purport to
do the same thing with the argument(s).
There is a lot more syntax in Tcl than the rules for parsing
what is a Tcl command or script.
I see where you are coming from, with the claim that arguments
are arguments, and each command takes arguments in the same way.
Any different treatment of arguments must be semantic. But that
way of thinking cuts Tcl off at the command parser, as if the
commands of Tcl weren't part of the Tcl language. In fact there
are several parsers in Tcl, and the 12 rules only describe one
of them.
--
Donald Arseneau as...@triumf.ca
John Seal
> If I've read the comm syntax excerpt correctly, they permit passing the
> + as a seperate argument before the script
That is what they *say*, but not what they *mean*. I think the syntax
for both should be given as
... ??+?script?
Which (to me, anyway) more clearly indicates that the script is
optional, and can optionally have "+" as a prefix. A space is permitted
too, so the syntax could be ??+?? ?script?, but since scripts implicitly
allow whitespace, even leading and trailing whitespace, I think that
??+?script? covers that case adequately. (Better, in fact, because a
quick check proves that *any* whitespace, including newlines, is
permitted there!)
> precisely because +{foo bar} is invalid TCL syntax,
No, that's legal Tcl syntax for the two words "+{foo" and "bar}":
% list +{foo bar}
+\{foo bar\}
I had successfully used +{oneWordCmd} with [bind]. What happens is that
[bind] strips off the "+" and appends {oneWordCmd} to the chain of
scripts. I was blissfully ignorant of what was actually going on there,
until I tried +{two words}... the "+" hides the "{" from the parser and
the command sees "too many arguments", but it *is* legal Tcl syntax.
Something like +{puts "text"} is *NOT* legal Tcl syntax, though:
% list +{puts "test"}
extra characters after close-quote
> and {+foo bar} is confusing and "hides" the '+'.
Yes, that is confusing to one used to passing {scripts} into other
commands like [if] and [foreach], where such scripts contain Tcl code
only. But as pointed out in other responses, [comm] and [bind] are free
to treat their arguments in any way they like, which includes stripping
optional leading "+" signs from the script.
> Hence your example could be written as
> ::comm::comm hook event + {cmd "arg"}
> But that syntax certainly doesn't work with bind.
And it doesn't work with [comm], either.
> Dan "But I didn't try the comm example" Smart
Woulda, coulda, shoulda....