Menu
▾
▴
tcl-core
|
From: Brian G. <bgr...@mo...> - 2006-11-02 10:00:50
|
TIP #292: ALLOW UNQUOTED STRINGS IN EXPRESSIONS ================================================= Version: $Revision: 1.1 $ Author: Brian Griffin <bgriffin_at_model.com> State: Draft Type: Project Tcl-Version: 8.5 Vote: Pending Created: Wednesday, 01 November 2006 URL: http://purl.org/tcl/tip/292.html WebEdit: http://purl.org/tcl/tip/edit/292 Post-History: ------------------------------------------------------------------------- ABSTRACT ========== This TIP proposes allowing unquoted words to be recognized as strings in expressions (*expr*, *if*, *while*). RATIONALE =========== Currently the following fails with a syntax error: set foo bar expr {$foo eq bar} This seems antithetical to the EIAS Tao of Tcl. The *set* command does not require the quotes, so why should *expr*, especially since the operands of the *eq* and *ne* operators are treated as strings. It also seems reasonable for the *==* and *!=* operators to reject unquoted strings as not a valid operand. This provides some enforcement for numerical vs. string comparison by forcing the use of quotes to convert the numeric *==* to a string equality test. The rationale for making such a change is it will make complex code a bit easier to read. For example, I can: set var ENUM_VALUE_ONE switch $var { ENUM_VALUE_ZERO { ... } ENUM_VALUE_ONE { ... } default { ... } } if {[lsearch $supplied_values ENUM_VALUE_ONE] >= 0} { ... } if {[string equals $var ENUM_VALUE_ONE]} { ... } but I must: if {$var eq "ENUM_VALUE_ONE"} { ... } which could lead someone reading the code to incorrectly conclude that ENUM_VALUE_ONE is not the same thing as "ENUM_VALUE_ONE" or miss the fact that they are the same, especially when using a syntax highlighting editor. PROPOSED CHANGE ================= Change the expression parser to accept unquoted words that are not function names as strings. Modify /EqualityExpr/ to reject unqoted strings for "*==*", but allow them for "*eq*". DRAFT IMPLEMENTATION ====================== None, at the moment. COPYRIGHT =========== This document has been placed in the public domain. ------------------------------------------------------------------------- TIP AutoGenerator - written by Donal K. Fellows |
|
From: Donald G P. <dg...@ni...> - 2006-11-02 15:49:54
|
Brian Griffin wrote: > TIP #292: ALLOW UNQUOTED STRINGS IN EXPRESSIONS > ================================================= I think this is basically a good idea, though it must be done carefully. This topic came up in discussions about TIP 282. See those messages for some things to consider. I'd be happier if the two TIPs were rolled into one. > Tcl-Version: 8.5 Just IMHO, getting this done for 8.5 is a fantasy. > Change the expression parser to accept unquoted words that are not > function names as strings. Modify /EqualityExpr/ to reject unqoted > strings for "*==*", but allow them for "*eq*". There is no longer an "EqualityExpr" routine to modify. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Brian G. <bgr...@mo...> - 2006-11-02 17:40:44
|
Donald G Porter wrote: > Brian Griffin wrote: > >> Change the expression parser to accept unquoted words that are not >> function names as strings. Modify /EqualityExpr/ to reject unqoted >> strings for "*==*", but allow them for "*eq*". >> > > There is no longer an "EqualityExpr" routine to modify. > My mistake. I glanced at 8.4 code instead of HEAD. The point is to move the error check up a level in the parse tree. -Brian |
|
From: Brian G. <bgr...@mo...> - 2006-11-03 17:05:25
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Donald G Porter wrote:
<blockquote cite="mid...@ni..." type="cite">
<pre wrap="">Brian Griffin wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> TIP #292: ALLOW UNQUOTED STRINGS IN EXPRESSIONS
=================================================
</pre>
</blockquote>
<pre wrap=""><!---->
I think this is basically a good idea, though it must
be done carefully. This topic came up in discussions
about TIP 282. See those messages for some things to consider.
I'd be happier if the two TIPs were rolled into one.
</pre>
</blockquote>
<br>
This does make sense. I also like TIP 282, but the enhanced syntax
should be disallowed in the conditional commands. The last thing I
want to see is "if {a = $b}" executing without error. This is a good
argument for somehow splitting the semantics of expr from conditional
statements.<br>
<br>
-Brian<br>
</body>
</html>
|
|
From: Will D. <wi...@wj...> - 2006-11-03 19:25:08
|
On Nov 3, 2006, at 9:03 AM, Brian Griffin wrote:
> Donald G Porter wrote:
>> Brian Griffin wrote:
>>> TIP #292: ALLOW UNQUOTED STRINGS IN EXPRESSIONS
>>> =================================================
>> I think this is basically a good idea, though it must be done
>> carefully. This topic came up in discussions about TIP 282. See
>> those messages for some things to consider. I'd be happier if the
>> two TIPs were rolled into one.
>
> This does make sense. I also like TIP 282, but the enhanced syntax
> should be disallowed in the conditional commands. The last thing I
> want to see is "if {a = $b}" executing without error. This is a
> good argument for somehow splitting the semantics of expr from
> conditional statements.
Alternatively, if one used ":=" as the assignment operator for
TIP 282 there'd be no active harm in using the enhanced syntax
in "if" and "while". You *could* write "if {a := $b}" if you
really wanted to, but you'd be much less likely to do it
accidentally.
------------------------------------------------------------------
will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills
|
|
From: Donal K. F. <don...@ma...> - 2006-11-05 22:59:09
|
Will Duquette wrote:
> Alternatively, if one used ":=" as the assignment operator for
> TIP 282 there'd be no active harm in using the enhanced syntax
> in "if" and "while". You *could* write "if {a := $b}" if you
> really wanted to, but you'd be much less likely to do it
> accidentally.
I agree with and strongly support this suggestion. Many years of
experience with C and Java (learning, using, and teaching) tells me that
the "BCPL mistake"[*] is a horrible thing that always leads to trouble.
If we ensure that "=" is not legal, it forces people to choose between
definitely equality (==) and definitely assignment (:=). I've done this
in the past in other languages, and it makes for fewer user errors.
Donal.
[* Many people think this is a problem that came about in the C language
but it really happened in C's grandparent. Or maybe it was in CPL,
the parent language of BCPL, but I can't find any examples of that
online in a quick and not-very-thorough search. ]
|
|
From: Kevin K. <ke...@ac...> - 2006-11-06 03:16:47
|
Donal K. Fellows wrote: > I agree with and strongly support this suggestion. Many years of > experience with C and Java (learning, using, and teaching) tells me that > the "BCPL mistake"[*] is a horrible thing that always leads to trouble. I think we have Fortran to blame for using a single '=' to denote assignment. (Yes, Fortran did use .EQ. to denote equality, so the two could not be confused, but the single '=' gave other language designers bad ideas. Worst was Basic, where the meaning of '=' was context dependent: LET A=B=C did not mean "set B and A both to the value of C," but rather, "test if B is equal to C and set A to the result of the test." I still favour \u2190 for assignment (and \u21D0 could mean [lappend]), but I know in my heart of hearts that the idea is quixotic at best. -- 73 de ke9tv/2, Kevin |
|
From: Arjen M. <arj...@wl...> - 2006-11-06 08:02:06
|
Kevin Kenny wrote: >Donal K. Fellows wrote: > > >>I agree with and strongly support this suggestion. Many years of >>experience with C and Java (learning, using, and teaching) tells me that >>the "BCPL mistake"[*] is a horrible thing that always leads to trouble. >> >> > >I think we have Fortran to blame for using a single '=' to denote >assignment. (Yes, Fortran did use .EQ. to denote equality, so the >two could not be confused, but the single '=' gave other language >designers bad ideas. Worst was Basic, where the meaning of '=' >was context dependent: LET A=B=C did not mean "set B and A both >to the value of C," but rather, "test if B is equal to C and set >A to the result of the test." > >I still favour \u2190 for assignment (and \u21D0 could mean [lappend]), >but I know in my heart of hearts that the idea is quixotic at best. > > Hm, I know too little about the history of language design, but I do know that FORTRAN (pre-77) was rather limited in its choice of characters. This was in the days of punch cards and tapes and wildly varying computer hardware. My guess is that the colon made it into the language with the 77 standard. (And I seem to remember that Algol did use := ...) Regards, Arjen |
|
From: Arjen M. <arj...@wl...> - 2006-11-06 07:53:09
|
Donal K. Fellows wrote:
>Will Duquette wrote:
>
>
>>Alternatively, if one used ":=" as the assignment operator for
>>TIP 282 there'd be no active harm in using the enhanced syntax
>>in "if" and "while". You *could* write "if {a := $b}" if you
>>really wanted to, but you'd be much less likely to do it
>>accidentally.
>>
>>
>
>I agree with and strongly support this suggestion. Many years of
>experience with C and Java (learning, using, and teaching) tells me that
>the "BCPL mistake"[*] is a horrible thing that always leads to trouble.
>If we ensure that "=" is not legal, it forces people to choose between
>definitely equality (==) and definitely assignment (:=). I've done this
>in the past in other languages, and it makes for fewer user errors.
>
>
I agree too. Even though I learned to program with languages that simply
use = for
assignment, I think it is important to clearly distinguish equality and
assignment.
If the syntax allows both in the same context that will inevitably lead
to subtle and therefore
horrible errors.
From a distant past, I remember being puzzled by this code fragment for
hours:
if ( x = 0 ) {
...
} else {
...
}
I could not figure why it would never go into the "true" branch!
(I was under the impression that it was C that caused all this,
but then I know too little about the pedigree of C. Visual Basic has
made an even worse
- IMHO - choice: = can mean assignment AND equality, depending on the
context)
Regards,
Arjen
|
|
From: Will D. <wi...@wj...> - 2006-11-04 15:03:28
|
On Nov 3, 2006, at 11:20 PM, Tim Daly, Jr. wrote: > > On Nov 3, 2006, at 11:06 PM, Larry McVoy wrote: > >>>> But that said, what was wrong with "lexpr"? >>> >>> These things come down to matters of taste, I suppose, >>> but to my eye it looks like a cryptic unixism. >> >> Hmm. Cryptic is bad. But "=" is less cryptic than "lexpr"? >> Not really seeing that line of reasoning but that's just me. I don't see "lexpr" as cryptic--it's an "L-expression", where the meaning of "L" will be well-defined. It's certainly no more cryptic than "lindex"...or than "expr", as far as that goes. > Oooh look, a bikeshed! > > "lexpr" is easier to google than "=", for what it's worth. And it's easier to google. ;-) Will > > Cheers, > Tim > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core ------------------------------------------------------------------ will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills |
|
From: Will D. <wi...@wj...> - 2006-11-03 17:43:05
|
On Nov 3, 2006, at 9:03 AM, Brian Griffin wrote:
> Donald G Porter wrote:
>> Brian Griffin wrote:
>>> TIP #292: ALLOW UNQUOTED STRINGS IN EXPRESSIONS
>>> =================================================
>> I think this is basically a good idea, though it must be done
>> carefully. This topic came up in discussions about TIP 282. See
>> those messages for some things to consider. I'd be happier if the
>> two TIPs were rolled into one.
>
> This does make sense. I also like TIP 282, but the enhanced syntax
> should be disallowed in the conditional commands. The last thing I
> want to see is "if {a = $b}" executing without error. This is a
> good argument for somehow splitting the semantics of expr from
> conditional statements.
The easiest way to split the semantics of the enhanced expr from
conditional statements is to put the enhanced syntax into a different
command and leave [expr] mostly alone.
* [expr] allows unquoted strings in expressions.
* [enhanced_expr] allows unquoted strings in expressions, per this
TIP, and also allows assignments and multiple statements, per
TIP 282.
I used the name "enhanced_expr" for the sake of argument; we'd
want a better name than that.
Now, of course, we're moving 282 even closer to Larry's "L" command
which executes L code in-line.
Will
------------------------------------------------------------------
will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills
|
|
From: <lm...@bi...> - 2006-11-03 18:46:02
|
> * [enhanced_expr] allows unquoted strings in expressions, per this
> TIP, and also allows assignments and multiple statements, per
> TIP 282.
>
> Now, of course, we're moving 282 even closer to Larry's "L" command
> which executes L code in-line.
Except L wants strings to be quoted and identifiers to be C like (which
seems to give Brian fits :) But other than that, yes, seems like there
is a lot of overlap.
We've wacked the L stuff to make L be a proc and it returns the value
of the last statement so you can do all the
if [L {a + b > c << 2}] { ... }
sorts of stuff. If someone can think of a verb that means "expr" that
isn't "expr" but is better than "L" we'll stick it in.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
|
|
From: Jeff H. <je...@ac...> - 2006-11-03 18:55:10
|
Larry McVoy wrote: > sorts of stuff. If someone can think of a verb that means "expr" that > isn't "expr" but is better than "L" we'll stick it in. lexpr. And you pronouce it "leper". ;) Jeff |
|
From: <lm...@bi...> - 2006-11-03 18:56:55
|
On Fri, Nov 03, 2006 at 10:53:49AM -0800, Jeff Hobbs wrote:
> Larry McVoy wrote:
> > sorts of stuff. If someone can think of a verb that means "expr" that
> > isn't "expr" but is better than "L" we'll stick it in.
>
> lexpr. And you pronouce it "leper". ;)
Very funny tclguy.
So this is an alias for L --poly { .... }, right? I.e., you want any
assignments to just autocreate variables without whining, correct?
And no type checking.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
|
|
From: Will D. <wi...@wj...> - 2006-11-03 19:04:41
|
On Nov 3, 2006, at 10:56 AM, Larry McVoy wrote:
> On Fri, Nov 03, 2006 at 10:53:49AM -0800, Jeff Hobbs wrote:
>> Larry McVoy wrote:
>>> sorts of stuff. If someone can think of a verb that means "expr"
>>> that
>>> isn't "expr" but is better than "L" we'll stick it in.
>>
>> lexpr. And you pronouce it "leper". ;)
>
> Very funny tclguy.
>
> So this is an alias for L --poly { .... }, right? I.e., you want any
> assignments to just autocreate variables without whining, correct?
> And no type checking.
Right. Any variables from the surrounding scope are poly's,
anyway, and if you want type checking on variables created within
the block you can always declare them explicitly.
Will
------------------------------------------------------------------
will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills
|
|
From: <lm...@bi...> - 2006-11-03 19:06:18
|
> >So this is an alias for L --poly { .... }, right? I.e., you want any
> >assignments to just autocreate variables without whining, correct?
> >And no type checking.
>
> Right. Any variables from the surrounding scope are poly's,
> anyway, and if you want type checking on variables created within
> the block you can always declare them explicitly.
OK doke.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
|
|
From: Brian G. <bgr...@mo...> - 2006-11-03 19:01:07
|
Larry McVoy wrote: > > If someone can think of a verb that means "expr" that > isn't "expr" but is better than "L" we'll stick it in. > How about "el", short for Expression Language. -Brian |
|
From: <lm...@bi...> - 2006-11-03 19:03:10
|
On Fri, Nov 03, 2006 at 10:59:16AM -0800, Brian Griffin wrote: > Larry McVoy wrote: > > > >If someone can think of a verb that means "expr" that > >isn't "expr" but is better than "L" we'll stick it in. > > > > How about "el", short for Expression Language. I like "lexpr" better because unlike Jeff, I pronounce it "L expr" and means exactly what you think it means, an expr that takes L syntax. "el" is nice for shortness sake but it is going to make people hiccup when they see it. The only downside I see to "lexpr" is maybe people with think it means "list expr", but that seems unlikely, what would a list expr do? -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
|
From: Brian G. <bgr...@mo...> - 2006-11-03 19:08:03
|
Larry McVoy wrote: > On Fri, Nov 03, 2006 at 10:59:16AM -0800, Brian Griffin wrote: > >> Larry McVoy wrote: >> >>> If someone can think of a verb that means "expr" that >>> isn't "expr" but is better than "L" we'll stick it in. >>> >>> >> How about "el", short for Expression Language. >> > > I like "lexpr" better because unlike Jeff, I pronounce it "L expr" and > means exactly what you think it means, an expr that takes L syntax. > > "el" is nice for shortness sake but it is going to make people hiccup > when they see it. > Agreed, I just thought it was cute because it's pronounced the same as "L". > The only downside I see to "lexpr" is maybe people with think it means > "list expr", but that seems unlikely, what would a list expr do? > list expr: evaluates a list of expressions. -Brian |
|
From: <lm...@bi...> - 2006-11-03 19:10:39
|
> >The only downside I see to "lexpr" is maybe people with think it means
> >"list expr", but that seems unlikely, what would a list expr do?
>
> list expr: evaluates a list of expressions.
Right but the return value is what? The last one evaluated? And how
is that any different than a list of statements?
set foo [lexpr {
a = 1;
b = 2;
c = 3;
}]
vs
set list [list "set a 1" "set b 2" "set c 3"]
set foo [lexpr $list]
Sort of seems like the list expr semantics are the L expr semantics or
pretty close.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
|
|
From: <dg...@ni...> - 2006-11-03 21:57:34
|
Quoting Larry McVoy <lm...@bi...>:
> ...so you can do all the
>
> if [L {a + b > c << 2}] { ... }
>
> sorts of stuff. If someone can think of a verb that means "expr" that
> isn't "expr" but is better than "L" we'll stick it in.
Without endorsing the plan, the good names for such a thing are
"compute" or "=".
DGP
|
|
From: <lm...@bi...> - 2006-11-03 22:48:48
|
On Fri, Nov 03, 2006 at 04:57:06PM -0500, dg...@ni... wrote:
> Quoting Larry McVoy <lm...@bi...>:
> > ...so you can do all the
> >
> > if [L {a + b > c << 2}] { ... }
> >
> > sorts of stuff. If someone can think of a verb that means "expr" that
> > isn't "expr" but is better than "L" we'll stick it in.
>
> Without endorsing the plan, the good names for such a thing are
> "compute" or "=".
I'm not so sure. The L stuff can handle arbitrary stuff, assignments,
variable declarations (if you're into that sort of thing), function
definitions, etc. It just so happened that people expressed an interest
in getting at a C like syntax for math stuff so we made sure that worked.
So "compute" is closer than "=".
But that said, what was wrong with "lexpr"?
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
|
|
From: <dg...@ni...> - 2006-11-04 04:43:31
|
Quoting Larry McVoy <lm...@bi...>: > On Fri, Nov 03, 2006 at 04:57:06PM -0500, dg...@ni... wrote: > ...the good names for such a thing are "compute" or "=". > I'm not so sure. The L stuff can handle arbitrary stuff, ... ok, so to the extent I've missed the point, I've chosen too narrow of a name. > But that said, what was wrong with "lexpr"? These things come down to matters of taste, I suppose, but to my eye it looks like a cryptic unixism. DGP |
|
From: <lm...@bi...> - 2006-11-04 07:06:24
|
> > But that said, what was wrong with "lexpr"? > > These things come down to matters of taste, I suppose, > but to my eye it looks like a cryptic unixism. Hmm. Cryptic is bad. But "=" is less cryptic than "lexpr"? Not really seeing that line of reasoning but that's just me. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
|
From: Tim D. Jr. <ti...@bi...> - 2006-11-04 07:20:01
|
On Nov 3, 2006, at 11:06 PM, Larry McVoy wrote: >>> But that said, what was wrong with "lexpr"? >> >> These things come down to matters of taste, I suppose, >> but to my eye it looks like a cryptic unixism. > > Hmm. Cryptic is bad. But "=" is less cryptic than "lexpr"? > Not really seeing that line of reasoning but that's just me. Oooh look, a bikeshed! "lexpr" is easier to google than "=", for what it's worth. Cheers, Tim |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X