Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #12065 > unrolled thread
| Started by | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| First post | 2011-10-25 00:44 +0000 |
| Last post | 2011-11-04 14:51 -0700 |
| Articles | 20 on this page of 90 — 25 participants |
Back to article view | Back to comp.lang.c
John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-10-25 00:44 +0000
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-25 01:27 -0700
Re: John McCarthy died today. Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-10-25 09:27 +0000
Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-25 11:27 +0100
Re: John McCarthy died today. Ark <akhasin@macroexpressions.com> - 2011-10-29 13:33 -0400
Re: John McCarthy died today. Willem <willem@toad.stack.nl> - 2011-10-29 17:51 +0000
Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 21:28 +0300
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-10-29 11:57 -0700
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-30 08:20 -0700
Re: John McCarthy died today. Ark <akhasin@macroexpressions.com> - 2011-11-04 05:20 -0400
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 15:53 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-04 12:16 -0400
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 17:58 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-04 20:49 -0400
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-05 01:55 +0000
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-07 10:54 +0000
Re: John McCarthy died today. "Charles Richmond" <netnews@aquaporin4.com> - 2011-11-07 07:36 -0600
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-07 19:49 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-07 15:49 -0500
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-08 00:38 -0800
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 07:05 -0500
Re: John McCarthy died today. lawrence.jones@siemens.com - 2011-11-08 09:12 -0500
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 16:48 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 12:12 -0500
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:27 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 14:10 -0800
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 17:16 -0500
Re: John McCarthy died today. lawrence.jones@siemens.com - 2011-11-09 13:51 -0500
Re: Looping Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-09 19:21 -0700
Re: Looping Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 02:34 +0000
Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-08 17:49 -0500
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 16:35 -0800
Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-09 01:08 -0500
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 01:26 -0800
Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-09 08:18 -0500
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 05:32 -0800
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 01:24 -0800
Re: John McCarthy died today. Quentin Carbonneaux <qcarbonn@invalid.com> - 2011-11-09 11:59 +0000
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 05:34 -0800
Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-08 18:31 +0200
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 14:06 -0800
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-08 02:01 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 23:16 -0800
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 05:18 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 23:17 -0800
Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-08 01:46 -0800
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-08 13:02 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 14:19 -0800
Re: John McCarthy died today. Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-11-08 22:23 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 18:13 -0500
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:38 +0000
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:18 +0000
Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-10 12:40 +0200
Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 11:39 +0000
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-10 12:23 +0000
Re: John McCarthy died today. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-10 05:38 -0800
Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-10 17:29 +0200
Re: John McCarthy died today. David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 16:34 -0800
Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 01:37 -0800
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:25 -0800
Re: John McCarthy died today. Ian Collins <ian-news@hotmail.com> - 2011-11-10 10:36 +1300
Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 23:47 -0800
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-10 00:21 -0800
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-10 03:04 -0800
Re: John McCarthy died today. gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-10 15:20 +0000
Re: John McCarthy died today. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-12 23:22 +0000
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-13 01:44 +0000
Re: John McCarthy died today. "Charles Richmond" <netnews@aquaporin4.com> - 2011-11-13 04:18 -0600
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-13 16:57 +0000
Re: John McCarthy died today. Robert Wessel <robertwessel2@yahoo.com> - 2011-11-13 11:59 -0600
Re: John McCarthy died today. gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-13 18:54 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-13 14:47 -0800
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-14 03:43 +0000
Re: John McCarthy died today. Ike Naar <ike@sverige.freeshell.org> - 2011-11-14 09:00 +0000
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-14 18:30 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-14 14:44 -0500
Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-14 20:13 +0000
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-14 00:21 -0800
Re: John McCarthy died today. Lauri Alanko <la@iki.fi> - 2011-11-10 15:26 +0000
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 01:51 +0000
Re: John McCarthy died today. Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-11-09 17:15 +0000
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-09 18:04 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:31 -0800
Re: John McCarthy died today. Robert Wessel <robertwessel2@yahoo.com> - 2011-11-09 15:53 -0600
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-09 22:02 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 14:14 -0800
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:50 -0800
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 07:10 -0500
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-04 14:51 -0700
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-07 14:06 -0800 |
| Message-ID | <ln1utjegei.fsf@nuthaus.mib.org> |
| In reply to | #12839 |
"BartC" <bc@freeuk.com> writes:
[...]
> So things can be done about it, such as only allowing (a=b) to return a
> value when used on the rhs of another assignment. Or requiring an explicit
> operator to extract the value of (a=b). It would be a dramatic change to the
> language, but it will never be done because opponents will insist that
> anyone who gets = and == mixed up is just a lousy programmer and should be
> looking for a simpler occupation.
It will never be done because it would break existing code. It has
little or nothing to do with some imagined elitism.
Actually, I can think of a way to address the issue without breaking
existing code. (I don't think this would be adopted, and it probably
wouldn't be worth the added complexity.)
Define ":=" as an alias for "=", the simple assignment operator.
Keep "=" and "==" as they are. Provide an *optional* method
(perhaps a new #pragma) to turn on a warning for any use of "=".
Existing code would be unaffected. New code would be unaffected
if the author doesn't choose to use the new feature.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-11-08 02:01 +0000 |
| Message-ID | <j9a2it$kd1$1@dont-email.me> |
| In reply to | #12857 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:ln1utjegei.fsf@nuthaus.mib.org... > "BartC" <bc@freeuk.com> writes: > [...] >> So things can be done about it, such as only allowing (a=b) to return a >> value when used on the rhs of another assignment. Or requiring an >> explicit >> operator to extract the value of (a=b). > Actually, I can think of a way to address the issue without breaking > existing code. (I don't think this would be adopted, and it probably > wouldn't be worth the added complexity.) > > Define ":=" as an alias for "=", the simple assignment operator. > Keep "=" and "==" as they are. Provide an *optional* method > (perhaps a new #pragma) to turn on a warning for any use of "=". > > Existing code would be unaffected. New code would be unaffected > if the author doesn't choose to use the new feature. Looks good to me. But just surprised you are actually suggesting changing C's assignment operator to ":=", even if you're making it optional. The only problems I can see are the confusion when := and = are used in the same file (because someone using := will be maintaining or reading code that uses =, and vice versa). And where :=, = and == are allowed at the same time, people using := are possibly more likely to want to use = for equality. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-07 23:16 -0800 |
| Message-ID | <lnwrbbccej.fsf@nuthaus.mib.org> |
| In reply to | #12868 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:ln1utjegei.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>> [...]
>>> So things can be done about it, such as only allowing (a=b) to return a
>>> value when used on the rhs of another assignment. Or requiring an
>>> explicit
>>> operator to extract the value of (a=b).
>
>> Actually, I can think of a way to address the issue without breaking
>> existing code. (I don't think this would be adopted, and it probably
>> wouldn't be worth the added complexity.)
>>
>> Define ":=" as an alias for "=", the simple assignment operator.
>> Keep "=" and "==" as they are. Provide an *optional* method
>> (perhaps a new #pragma) to turn on a warning for any use of "=".
>>
>> Existing code would be unaffected. New code would be unaffected
>> if the author doesn't choose to use the new feature.
>
> Looks good to me. But just surprised you are actually suggesting changing
> C's assignment operator to ":=", even if you're making it optional.
Why is that surprising?
In any case, I'm not advocating it, merely suggesting that it's a
possibility. If we were designing C from scratch today, I'd advocate
using ":=" for assignment. But we're thoroughly stuck with "=" for
assignment. It's tempting to provide a mechanism to use ":=" as an
alternative, but the only thing more confusing than a language that uses
"=" for assignment (and permits it in expressions) is one that uses both
"=" and ":=".
> The only problems I can see are the confusion when := and = are used in the
> same file (because someone using := will be maintaining or reading code that
> uses =, and vice versa). And where :=, = and == are allowed at the same
> time, people using := are possibly more likely to want to use = for
> equality.
*If* we wanted to incrementally replace "=" by ":=" for assignment,
we could have a #pragma that causes ";=" to be recognized and "="
to be forbidden. But the more I think about it, the less I actually
like the idea.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-08 05:18 +0000 |
| Message-ID | <20111107211245.480@kylheku.com> |
| In reply to | #12857 |
On 2011-11-07, Keith Thompson <kst-u@mib.org> wrote:
> "BartC" <bc@freeuk.com> writes:
> [...]
>> So things can be done about it, such as only allowing (a=b) to return a
>> value when used on the rhs of another assignment. Or requiring an explicit
>> operator to extract the value of (a=b). It would be a dramatic change to the
>> language, but it will never be done because opponents will insist that
>> anyone who gets = and == mixed up is just a lousy programmer and should be
>> looking for a simpler occupation.
>
> It will never be done because it would break existing code. It has
> little or nothing to do with some imagined elitism.
Of course, there is always the preprocessor.
#define eq(x, y) ((x) == (y))
#define set(x, y) ((x) = (y))
while (!eq(set(ch, get(stream)), EOF)) {
/* ... */
}
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-07 23:17 -0800 |
| Message-ID | <lnsjlzccbk.fsf@nuthaus.mib.org> |
| In reply to | #12872 |
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2011-11-07, Keith Thompson <kst-u@mib.org> wrote:
>> "BartC" <bc@freeuk.com> writes:
>> [...]
>>> So things can be done about it, such as only allowing (a=b) to
>>> return a value when used on the rhs of another assignment. Or
>>> requiring an explicit operator to extract the value of (a=b). It
>>> would be a dramatic change to the language, but it will never
>>> be done because opponents will insist that anyone who gets =
>>> and == mixed up is just a lousy programmer and should be looking
>>> for a simpler occupation.
>>
>> It will never be done because it would break existing code. It has
>> little or nothing to do with some imagined elitism.
>
> Of course, there is always the preprocessor.
>
> #define eq(x, y) ((x) == (y))
> #define set(x, y) ((x) = (y))
>
> while (!eq(set(ch, get(stream)), EOF)) {
> /* ... */
> }
And of course:
#define BEGIN {
#define END }
#define IF if (
#define THEN } {
#define ELSE } else {
#define ENDIF }
and so on.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-11-08 01:46 -0800 |
| Message-ID | <8a3ee570-307b-46b4-8e39-996082e716fc@s5g2000vbe.googlegroups.com> |
| In reply to | #12857 |
On Nov 8, 12:06 am, Keith Thompson <ks...@mib.org> wrote: > > Define ":=" as an alias for "=", the simple assignment operator. > Keep "=" and "==" as they are. Provide an *optional* method > (perhaps a new #pragma) to turn on a warning for any use of "=". > Or you could make the warning non-optional. A utility to go through old C code changing every incidence of "=" to ":=" would be quite simple to write, and would ship with every new compiler. -- Basic Algorithms: a "how to" guide for practical programming. http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-11-08 13:02 +0000 |
| Message-ID | <j9b99e$qqi$1@dont-email.me> |
| In reply to | #12882 |
"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message news:8a3ee570-307b-46b4-8e39-996082e716fc@s5g2000vbe.googlegroups.com... > On Nov 8, 12:06 am, Keith Thompson <ks...@mib.org> wrote: >> >> Define ":=" as an alias for "=", the simple assignment operator. >> Keep "=" and "==" as they are. Provide an *optional* method >> (perhaps a new #pragma) to turn on a warning for any use of "=". >> > Or you could make the warning non-optional. > > A utility to go through old C code changing every incidence of "=" to > ":=" would be quite simple to write, and would ship with every new > compiler. Well, every "=" not preceded by "<", ">" and perhaps ":" (where a file has already been converted), and not followed by another "=". But what about "=" used to initialise data? Does that also change to ":="? For a static initialisation, it isn't really assignment. Or "=" occurring in comments and string literals; sometimes you want these to be left alone, but if it's commented-out code, or a string literal which happens to contain C source code, then they need to be changed! Unless it's C source code intended to produce old-style source... Or where a "=" occurs in a macro, in a way that would later be matched to another string to form "<=" or "==". See, these things are never that easy... And what about where someone has written a=b when they had actually meant a==b, but somehow the program works. Once converted to a:=b, it's then less likely that the error will be spotted later on. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-08 14:19 -0800 |
| Message-ID | <ln7h3acl4i.fsf@nuthaus.mib.org> |
| In reply to | #12882 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Nov 8, 12:06 am, Keith Thompson <ks...@mib.org> wrote:
>> Define ":=" as an alias for "=", the simple assignment operator.
>> Keep "=" and "==" as they are. Provide an *optional* method
>> (perhaps a new #pragma) to turn on a warning for any use of "=".
>>
> Or you could make the warning non-optional.
>
> A utility to go through old C code changing every incidence of "=" to
> ":=" would be quite simple to write, and would ship with every new
> compiler.
Are you serious?
Even if I thought it was a good idea, a language change that would
require modifying practically every C source file ever written
would never be accepted.
Modifying source files, even mechanically, is never a zero-cost
operation. Source control systems would show *huge* diffs between
successive versions of the same file. Suppose, for example,
that foo.c version 1 uses "=" for assignment, version 2 makes
some functional changes (10 lines changed), version 3 changes
all the "=" to ":=" (with no other changes), and version 4 makes
some more functional changes (7 lines changed). Imagine trying
to compare versions 1 and 4 to see what the actual changes were.
(No, we're not going to modify every diff tool in existence to
ignore "=" vs. ":=".) And that's assuming the "=" to ":=" change
isn't combined with other modifications.
And version 4 will not compile with earlier compilers. Now that I
think about it, that's a very strong argument against my original
idea.
Using "=" for assignment was not, in my opinion, a good idea. Any
attempt to change it now would be far worse.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> |
|---|---|
| Date | 2011-11-08 22:23 +0000 |
| Message-ID | <j9ca4i$gt7$1@speranza.aioe.org> |
| In reply to | #12919 |
Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On Nov 8, 12:06 am, Keith Thompson <ks...@mib.org> wrote: >>> Define ":=" as an alias for "=", the simple assignment operator. Keep >>> "=" and "==" as they are. Provide an *optional* method (perhaps a new >>> #pragma) to turn on a warning for any use of "=". >>> >> Or you could make the warning non-optional. >> >> A utility to go through old C code changing every incidence of "=" to >> ":=" would be quite simple to write, and would ship with every new >> compiler. > > Are you serious? > > Even if I thought it was a good idea, a language change that would > require modifying practically every C source file ever written would > never be accepted. > > Modifying source files, even mechanically, is never a zero-cost > operation. Source control systems would show *huge* diffs between > successive versions of the same file. Suppose, for example, that foo.c > version 1 uses "=" for assignment, version 2 makes some functional > changes (10 lines changed), version 3 changes all the "=" to ":=" (with > no other changes), and version 4 makes some more functional changes (7 > lines changed). Imagine trying to compare versions 1 and 4 to see what > the actual changes were. (No, we're not going to modify every diff tool > in existence to ignore "=" vs. ":=".) And that's assuming the "=" to > ":=" change isn't combined with other modifications. > > And version 4 will not compile with earlier compilers. Now that I think > about it, that's a very strong argument against my original idea. > > Using "=" for assignment was not, in my opinion, a good idea. Any > attempt to change it now would be far worse. With this attitude, the language will never improve!
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-11-08 18:13 -0500 |
| Message-ID | <4EB9B7A5.4020209@verizon.net> |
| In reply to | #12920 |
On 11/08/2011 05:23 PM, Edward Rutherford wrote: > Keith Thompson wrote: ... >> And version 4 will not compile with earlier compilers. Now that I think >> about it, that's a very strong argument against my original idea. >> >> Using "=" for assignment was not, in my opinion, a good idea. Any >> attempt to change it now would be far worse. > > With this attitude, the language will never improve! Whenever you propose a backwards-incompatible change to the language, the benefits of the change need to be balanced against the costs due tot he incompatibility. The change should not be done unless the benefits outweigh the costs by a substantial margin This constrains the possibilities for improvement, but it does not prevent improvement.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-08 23:38 +0000 |
| Message-ID | <20111108152946.677@kylheku.com> |
| In reply to | #12927 |
On 2011-11-08, James Kuyper <jameskuyper@verizon.net> wrote: > On 11/08/2011 05:23 PM, Edward Rutherford wrote: >> Keith Thompson wrote: > ... >>> And version 4 will not compile with earlier compilers. Now that I think >>> about it, that's a very strong argument against my original idea. >>> >>> Using "=" for assignment was not, in my opinion, a good idea. Any >>> attempt to change it now would be far worse. >> >> With this attitude, the language will never improve! > > Whenever you propose a backwards-incompatible change to the language, A backwards-incompatible change creates simply creates a new language or dialect. > the benefits of the change need to be balanced against the costs due tot > he incompatibility. More like, the benefits of the introduction of a language which is not significantly backward-compatible with anything need to be considered against the odds of the project failing to captivate anyone's interest, or garnering outright rejection, which are very likely outcomes no matter how good it is.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-08 23:18 +0000 |
| Message-ID | <20111108151313.538@kylheku.com> |
| In reply to | #12920 |
On 2011-11-08, Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> wrote: > Keith Thompson wrote: > >> Using "=" for assignment was not, in my opinion, a good idea. Any >> attempt to change it now would be far worse. > > With this attitude, the language will never improve! Inextensible languages like C do improve or at least evolve by creating spin-offs which are new languages. Some are backward-compatible (Objective C). Some have a lot of backward compatibility (C++). Others are incompatible (Java). Speaking of which, even though Java is not meant to be compatible with C, its assignment operator is = and comparison is ==. Oops!
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-11-10 12:40 +0200 |
| Message-ID | <87ty6cdzvu.fsf@bazspaz.fatphil.org> |
| In reply to | #12928 |
Kaz Kylheku <kaz@kylheku.com> writes: > On 2011-11-08, Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> wrote: > > Keith Thompson wrote: > > > >> Using "=" for assignment was not, in my opinion, a good idea. Any > >> attempt to change it now would be far worse. > > > > With this attitude, the language will never improve! > > Inextensible languages like C do improve or at least evolve by creating > spin-offs which are new languages. Some are backward-compatible (Objective C). > Some have a lot of backward compatibility (C++). Others are incompatible > (Java). > > Speaking of which, even though Java is not meant to be compatible with C, its > assignment operator is = and comparison is ==. > > Oops! As is JavaScript's, and perl's, and LUA's, and python's ... Was the decision really such a bad mistake if it's been willingly repeated so often? I'll pin my colours to the mast - I do not consider the choice of those tokens to be a mistake. Phil -- Unix is simple. It just takes a genius to understand its simplicity -- Dennis Ritchie (1941-2011), Unix Co-Creator
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-11-10 11:39 +0000 |
| Message-ID | <0.2d6e52c80a43ca6d5733.20111110113927GMT.87fwhw1a1c.fsf@bsb.me.uk> |
| In reply to | #13009 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes: <snip> > I'll pin my colours to the mast - I do not consider the choice of those > tokens to be a mistake. No, me neither, though I have a slight preference for an asymmetric symbol for assignment since the operation is asymmetric. More to the point, I don't recall any "hard" bug being caused by a =/== confusion. Sure, it happens, but the bug shows up immediately the code is tested. In contrast, A </<= error (which can be either a typo or a misunderstanding) can often be quite hard to track down. Does anyone recall a =/== bug that was anything but trivial? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-11-10 12:23 +0000 |
| Message-ID | <j9gfp0$uhj$1@dont-email.me> |
| In reply to | #13009 |
"Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message news:87ty6cdzvu.fsf@bazspaz.fatphil.org... > Kaz Kylheku <kaz@kylheku.com> writes: >> Speaking of which, even though Java is not meant to be compatible with C, >> its >> assignment operator is = and comparison is ==. >> >> Oops! > > As is JavaScript's, and perl's, and LUA's, and python's ... > > Was the decision really such a bad mistake if it's been willingly > repeated so often? Those languages were likely implemented in C. In which case, they would be quite receptive to the idea of using "=" and "==". And if they had considered using ":=" and "=" instead, they would quickly have found that mixing up ":="/"=" and "="/"==" (between writing the C code and testing fragments of the new language) caused too many problems! > I'll pin my colours to the mast - I do not consider the choice of those > tokens to be a mistake. In the original C, or the derived languages? Once the decision to use "=" for assignment in C was made, using "==" for equality was reasonable. Using .EQ. would be too naff, and using context was not possible as assignments also occur in expressions. (I think PL/I allowed "=" for both assignment/equality, maybe it did use context, but that was quite hairy to implement anyway.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-11-10 05:38 -0800 |
| Message-ID | <33286851.257.1320932318775.JavaMail.geo-discussion-forums@prmu13> |
| In reply to | #13016 |
I think in C the assignment = is OK. But if C is to be used to model HW circuits then the blocking and non-blocking assignment is different. There is ways around! For example, use an object way that the next property for HW objects to change values. C++ people usually don't like to talk about HW related properties such as pointers in C and pointer operations and stacks in compilers. Thus C is better to extend its usage in HW descriptions in the future. ANSI ASCII was an encode to express color letters in BBS in 199X. And that time those BBS programs are most written in C. Now html/xml/CSS take over the jobs!
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-11-10 17:29 +0200 |
| Message-ID | <87zkg4c7wq.fsf@bazspaz.fatphil.org> |
| In reply to | #13016 |
"BartC" <bc@freeuk.com> writes: > "Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message > news:87ty6cdzvu.fsf@bazspaz.fatphil.org... > > Kaz Kylheku <kaz@kylheku.com> writes: > > >> Speaking of which, even though Java is not meant to be compatible > >> with C, its > >> assignment operator is = and comparison is ==. > >> > >> Oops! > > > > As is JavaScript's, and perl's, and LUA's, and python's ... > > > > Was the decision really such a bad mistake if it's been willingly > > repeated so often? > > Those languages were likely implemented in C. In which case, they > would be quite receptive to the idea of using "=" and "==". Probably so. They didn't consider themselves hostages to some egregious 'mistake', that they had to escape from forthwith, that's for sure. It still makes them valid data points against the hypothesis that the choice was a mistake. > And if they had considered using ":=" and "=" instead, they would > quickly have found that mixing up ":="/"=" and "="/"==" (between > writing the C code and testing fragments of the new language) caused > too many problems! In some of those languages, the visual similarity is minuscule, so I don't think that would be an issue - their test inputs are simply not comparable to the language the compiler/interpreter's written in. > > I'll pin my colours to the mast - I do not consider the choice of those > > tokens to be a mistake. > > In the original C, or the derived languages? In C. And I support its borrowing in all languages that want to inherit some C-like syntax, as long as holistically it's coherent enough. > Once the decision to use > "=" for assignment in C was made, using "==" for equality was > reasonable. No more or less reasonable than something like =?, though. OK, the set of arbitrary and vaguely sensible things it could have been isn't huge, but it's certainly not a singleton. > Using .EQ. would be too naff, and using context was not > possible as assignments also occur in expressions. > > (I think PL/I allowed "=" for both assignment/equality, maybe it did > use context, but that was quite hairy to implement anyway.) Whilst I don't have a background in those languages, I do not feel that I am lacking in any way! (But I'm happy to have studied scheme, for example.) Phil -- Unix is simple. It just takes a genius to understand its simplicity -- Dennis Ritchie (1941-2011), Unix Co-Creator
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2011-11-21 02:39 -0500 |
| Message-ID | <tfjjc75t78gd94ju4ttskbfi1cffnh9ff6@4ax.com> |
| In reply to | #13016 |
On Thu, 10 Nov 2011 12:23:06 -0000, "BartC" <bc@freeuk.com> wrote: > "Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message > news:87ty6cdzvu.fsf@bazspaz.fatphil.org... > > Kaz Kylheku <kaz@kylheku.com> writes: > > >> Speaking of which, even though Java is not meant to be compatible with C, > >> its assignment operator is = and comparison is ==. > >> > >> Oops! > > > > As is JavaScript's, and perl's, and LUA's, and python's ... > > > > Was the decision really such a bad mistake if it's been willingly > > repeated so often? > > Those languages were likely implemented in C. In which case, they would be > quite receptive to the idea of using "=" and "==". > The implementation language as such doesn't matter; SQL and HTML, among many other things, are often implemented in C (or C++, which keeps all the same basic syntax) but look nothing alike. > And if they had considered using ":=" and "=" instead, they would quickly > have found that mixing up ":="/"=" and "="/"==" (between writing the C code > and testing fragments of the new language) caused too many problems! > That's a benefit, but I think a small one. More important, if the designers/ implementors have experience of using C (or C++) without trouble, and especially if they expect or find their users do so, then following the path already blazed makes life easier. > > > I'll pin my colours to the mast - I do not consider the choice of those > > tokens to be a mistake. > > In the original C, or the derived languages? Once the decision to use "=" > for assignment in C was made, using "==" for equality was reasonable. Using > .EQ. would be too naff, and using context was not possible as assignments > also occur in expressions. > > (I think PL/I allowed "=" for both assignment/equality, maybe it did use > context, but that was quite hairy to implement anyway.) PL/I does indeed, but it has assignment as a statement only at toplevel not a nestable expression. The harder problem in parsing PL/I, for both compiler and human, is unreserved keywords. COBOL similarly has no trouble distinguishing COMPUTE x = y . IF a = b THEN blah . and SQL SELECT x FROM t WHERE y = 3; UPDATE t SET x = 17;
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-08 16:34 -0800 |
| Message-ID | <lnr51ib0bn.fsf@nuthaus.mib.org> |
| In reply to | #12920 |
Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> Keith Thompson wrote:
[...]
>> Using "=" for assignment was not, in my opinion, a good idea. Any
>> attempt to change it now would be far worse.
>
> With this attitude, the language will never improve!
With any other attitude, the language will die.
If you think that changing the C language to use ":=" rather than
for assignment is a good idea, that's not an unreasonable opinion,
at least at first glance. Frankly, I *wish* I could agree. But if
you want to propose such a change and have it taken seriously,
you need to address the problems it could cause (as I did in my
previous message).
So tell us, how would you address the problem of existing code that
uses "=" for assignment, and of new code using ":=" for assignment
that would no longer compile with older compilers? Similarly,
how would you address the legions of C programmers who believe
(rightly or wrongly) that using "=" for assignment and "==" for
equality is ok, and doesn't need to be fixed?
Please be specific.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-11-09 01:37 -0800 |
| Message-ID | <b90b4feb-800f-41d4-936b-ee5836612d0d@e3g2000vbs.googlegroups.com> |
| In reply to | #12935 |
On Nov 9, 2:34 am, Keith Thompson <ks...@mib.org> wrote: > > So tell us, how would you address the problem of existing code that > uses "=" for assignment, and of new code using ":=" for assignment > that would no longer compile with older compilers? Similarly, > how would you address the legions of C programmers who believe > (rightly or wrongly) that using "=" for assignment and "==" for > equality is ok, and doesn't need to be fixed? > You need to make the change compulsory, so the Luddites will have to use old compilers. Otherwise you get a worse mess than the one you were trying to solve. The new compiler gives an error, "old style assignment operator: please run makenewstyle". So you type makenewstyle *.c, and within seconds, all your code compiles. There are some potential problems with diff and so on. If you've got a decent version control system then the new code is just flagged as a "new version", and it's no different to adding a comment, maybe a copyright notice to comply with new corporate policy. But there will be people for whom having two logically identical but textually different source files will be a nuisance. Then for a while there will be both old and new compilers in existence. You can't break old code without some problems. However old code with implict int will generate an unacceptable cascade of warnings on new compilers. implicit int has just about died out, together with old style function declarations. Changes are possible.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web