Menu
▾
▴
tcl-core
|
From: <lm...@bi...> - 2006-11-04 15:25:58
|
On Sat, Nov 04, 2006 at 07:03:09AM -0800, Will Duquette wrote: > > 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. Right, we're in violent agreement. And as Tim said, that's enough discussion, anyone who doesn't like it can alias it to whatever they like in their code. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
|
From: Tom K. <tom...@fr...> - 2006-11-13 17:44:03
|
Larry, So, is L used to dissolve a lump of sugar in my T? Tom K. > On Sat, Nov 04, 2006 at 07:03:09AM -0800, Will Duquette wrote: > >>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. > > > Right, we're in violent agreement. And as Tim said, that's enough > discussion, anyone who doesn't like it can alias it to whatever they > like in their code. |
|
From: <lm...@bi...> - 2006-11-06 03:03:40
|
On Sun, Nov 05, 2006 at 10:59:10PM +0000, 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.
For what it is worth, we have 8+ years of usage and we do horrible things
like
unless (f = fopen(file, "r")) {
error stuff here
}
and I can't remember an instance of someone getting it wrong because we
did an "==" instead of an "=" or the other way around.
I think this is a newbie error that simply doesn't happen with pros.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
|
|
From: Donal K. F. <don...@ma...> - 2006-11-06 10:52:03
|
Larry McVoy wrote: > For what it is worth, we have 8+ years of usage and we do horrible things > like [...] I used to do that sort of thing quite a lot, but nowadays I try to write code that never puts an assignment in an if/while if possible since that leads to much greater clarity during maintenance. Saving a source line isn't worth it; newlines are cheap. :-) (I have an exception where I'm writing a macro that builds different functionality that isn't in base C and which needs an assignment in a funny place to work correctly. But in that case I'll also write a comment at the definition that explains what dirty tricks I'm up to.) > I think this is a newbie error that simply doesn't happen with pros. It's rare, but only because many people have learned to be paranoid about it. Using ":=" instead (which has a pretty good pedigree as well) means that forgetfulness won't lead to strange bugs. Also, Tcl's not just used by pros. Let's be kind to newcomers to the big world of programming too. Noobs make some *horrible* blunders in "intro to C" classes, and they're quite common among Java programmers too (though they're usually caught by the tighter type system there). By contrast, languages that use the Algol-derived ":=" don't have this problem at all. Mixing the symbols up is a syntax error, and so gets caught by people early. Donal. |
|
From: Michael K. <mi...@mu...> - 2006-11-06 12:06:09
|
On Sun, 5 Nov 2006, Larry McVoy wrote: > and I can't remember an instance of someone getting it wrong because we > did an "==" instead of an "=" or the other way around. > > I think this is a newbie error that simply doesn't happen with pros. FWIW also, after more than 15 years I still typo = vs. == sometimes in my C code, but I'm in the habit of putting constants first so that at least those are caught with an error. I never confuse the two operators, my fingers just don't always type the right thing. Doesn't happen often, but still happens. For that reason I'm similarly a tiny bit put off by "ni" as the opposite of "in". No chance of confusing the two, but easier to typo than, for example, "nin" or "!in" or "!($value in $list)". But I guess "ni" to "in" is more like "ne" is to "eq". Pity "ne" isn't "neq". Good thing I'm not (to my knowledge) dyslexic. :) -- Michael Kirkham www.muonics.com |
|
From: Brian G. <bri...@ea...> - 2006-11-06 03:33:49
|
On Nov 5, 2006, at 7:03 PM, Larry McVoy wrote:
> On Sun, Nov 05, 2006 at 10:59:10PM +0000, 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.
>
> For what it is worth, we have 8+ years of usage and we do horrible
> things
> like
>
> unless (f = fopen(file, "r")) {
> error stuff here
> }
>
> and I can't remember an instance of someone getting it wrong
> because we
> did an "==" instead of an "=" or the other way around.
>
> I think this is a newbie error that simply doesn't happen with pros.
Never say never. It does happen with pros, just not so often.
Modern compilers warn if such assignments are not within parentheses
(i.e. unless ((f=fopen(file,"r))) {}). This is a reasonable check to
prevent pros from making mistakes as well as newbies.
I think an ounce of prevention is worth it here since finding this,
if it's a bug, is very difficult, even for a pro.
-Brian
|
|
From: <lm...@bi...> - 2006-11-06 04:00:24
|
> I think an ounce of prevention is worth it here since finding this, > if it's a bug, is very difficult, even for a pro. Really? So who amongst us willing to pony up with 10 real world examples where this was an issue? I'm not saying it isn't but we're a 95% pure C shop and we should be seeing this all the time but we don't. Are we that much better than average? -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
|
From: Will D. <wi...@wj...> - 2006-11-06 04:24:18
|
Larry, I can honestly say that in my 20 years as a C programmer I've been bitten by saying "=" where I meant "==" or "==" where I meant "=" at least a few times every year. I believe I always caught the error in unit testing...but it usually left me scratching my head for a few minutes, because the actual error was so hard to see. I'd certainly be willing to live with "=" in [expr]; but on the other hand, using ":=" for assignment in [expr] is cheap-enough insurance. I don't really care either way. Will On Nov 5, 2006, at 8:00 PM, Larry McVoy wrote: >> I think an ounce of prevention is worth it here since finding this, >> if it's a bug, is very difficult, even for a pro. > > Really? So who amongst us willing to pony up with 10 real world > examples > where this was an issue? > > I'm not saying it isn't but we're a 95% pure C shop and we should > be seeing > this all the time but we don't. Are we that much better than average? > -- > --- > Larry McVoy lm at bitmover.com http:// > www.bitkeeper.com > > ---------------------------------------------------------------------- > --- > 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: Brian G. <bri...@ea...> - 2006-11-06 05:04:59
|
On Nov 5, 2006, at 8:00 PM, Larry McVoy wrote: >> I think an ounce of prevention is worth it here since finding this, >> if it's a bug, is very difficult, even for a pro. > > Really? So who amongst us willing to pony up with 10 real world > examples > where this was an issue? > > I'm not saying it isn't but we're a 95% pure C shop and we should > be seeing > this all the time but we don't. Are we that much better than average? Do you compile your C code with -Wall? If you don't, why not? Do you have a requirement to remove all warnings before shipping? What do you do with x.c:4: warning: suggest parentheses around assignment used as truth value ??? If you want this kind of checking in Tcl, you have to make the assignment token significantly visually different. You complain all the time about making Tcl "better". Here is an area that every C programer will agree is a "mistake" in C, and you have a chance to avoid the same mistake, so why not take advantage of it? -Brian |
|
From: <dr...@hw...> - 2006-11-02 16:24:34
|
Brian Griffin <bgriffin=40model.com> wrote: >=20 > ABSTRACT=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This TIP proposes allowing unquoted words to be recognized as strings= =20 > in expressions (*expr*, *if*, *while*).=20 >=20 I would much prefer that unquoted words be recognized as variable names. The single most common mistake I make when programming in TCL is to omit the =24 before variable names in expr. -- D. Richard Hipp <drh=40hwaci.com> |
|
From: <lm...@bi...> - 2006-11-02 16:30:00
|
On Thu, Nov 02, 2006 at 04:24:21PM +0000, dr...@hw... wrote:
> Brian Griffin <bgr...@mo...> wrote:
> >
> > ABSTRACT
> > ==========
> >
> > This TIP proposes allowing unquoted words to be recognized as strings
> > in expressions (*expr*, *if*, *while*).
> >
>
> I would much prefer that unquoted words be recognized as variable
> names. The single most common mistake I make when programming
> in TCL is to omit the $ before variable names in expr.
I tend to agree. And while we're there, is there really any need to
preserve the fact that you can do
set {silly variable name!} "some string"
Wouldn't life be simpler if there was a
tcp configure c-variable-names true
?
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
|
|
From: Brian G. <bgr...@mo...> - 2006-11-02 17:37:36
|
Larry McVoy wrote:
> On Thu, Nov 02, 2006 at 04:24:21PM +0000, dr...@hw... wrote:
>
>> Brian Griffin <bgr...@mo...> wrote:
>>
>>> ABSTRACT
>>> ==========
>>>
>>> This TIP proposes allowing unquoted words to be recognized as strings
>>> in expressions (*expr*, *if*, *while*).
>>>
>>>
>> I would much prefer that unquoted words be recognized as variable
>> names. The single most common mistake I make when programming
>> in TCL is to omit the $ before variable names in expr.
>>
I would attribute this kind of mistake to "thinking in C" rather then a
short coming of Tcl. I also make the mistake of putting {} around if
conditions in C, but I'm not going to petition the C standards body to
accept {} in place of () because of my forgetfulness.
>
> I tend to agree. And while we're there, is there really any need to
> preserve the fact that you can do
>
> set {silly variable name!} "some string"
>
> Wouldn't life be simpler if there was a
>
> tcp configure c-variable-names true
>
No, it wouldn't! Again, Tcl is not C!
The point is that the current situation is inconsistent.
set foo ASTRING ;# legal syntax
set foo "ASTRING" ;# legal syntax
if {$foo eq "ASTRING"} ;# legal syntax
if {$foo eq ASTRING} ;# illegal syntax!
This is odd and goes against the EIAS basis of Tcl. Either accept
unquoted string in expressions or require quotes everywhere else in
Tcl. A third option is to divorce expr from "if", "while", and "for"
commands, replacing it with a more Tclish conditional expression evaluator.
-Brian
|
|
From: <lm...@bi...> - 2006-11-06 14:55:45
|
> >I'm not saying it isn't but we're a 95% pure C shop and we should
> >be seeing
> >this all the time but we don't. Are we that much better than average?
>
> Do you compile your C code with -Wall? If you don't, why not?
Yup.
> Do you have a requirement to remove all warnings before shipping?
Requirement? No. We just do it as a matter of course. And you can't
remove all warnings, we have one that is legit.
> What do you do with
>
> x.c:4: warning: suggest parentheses around assignment used as truth
> value
>
> ???
We disable that warning, it was too annoying.
For what it is worth, it is almost always something like
unless (f = fopen(file, mode)) {
err: if (f) fclose(f), f = 0;
if (mem) free(mem);
if (this) that();
return (-1);
}
unless (mem = malloc(whatever)) goto err;
You get the idea, all the exit handling in one spot.
I'm getting the distinct sense we review our code a lot more than average.
Rather than code not going out with compiler warnings, our code doesn't
go out unreviewed.
> If you want this kind of checking in Tcl, you have to make the
> assignment token significantly visually different. You complain all
> the time about making Tcl "better". Here is an area that every C
> programer will agree is a "mistake" in C, and you have a chance to
> avoid the same mistake, so why not take advantage of it?
I suppose. In general, I think this one is so far down the priority list
compared to other stuff that I'm surprised anyone cares enough to fuss
about it. Perhaps it's the bikeshed effect again.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
|
|
From: Brian G. <bgr...@mo...> - 2006-11-06 19:34:54
|
Larry McVoy wrote: > I suppose. In general, I think this one is so far down the priority list > compared to other stuff that I'm surprised anyone cares enough to fuss > about it. Perhaps it's the bikeshed effect again. > This is not a bikeshed effect. This is a case of "Watch the pennies and the dollars will take care of themselves." It's a little thing now that can prevent bigger problems in the future. It's something that, once established, is incredibly difficult to change. -Brian |
×
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