Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c > #6028

Re: Addition of nocode keyword

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.std.c
Subject Re: Addition of nocode keyword
Date 2019-10-30 09:48 +0100
Organization A noiseless patient Spider
Message-ID <qpbiot$p7v$1@dont-email.me> (permalink)
References (4 earlier) <qp99eu$mr6$1@dont-email.me> <qpa70q$rmh$2@reader2.panix.com> <3e29c254-1116-45ad-a635-95de0ba736ad@googlegroups.com> <aa2ea471-2375-424b-af05-4554e3f37c1f@googlegroups.com> <qpaiee$7fr$1@dont-email.me>

Show all headers | View raw


On 30/10/2019 00:36, Rick C. Hodgin wrote:
> On 10/29/2019 5:47 PM, jameskuyper@alumni.caltech.edu wrote:
>> On Tuesday, October 29, 2019 at 4:31:52 PM UTC-4, Rick C. Hodgin wrote:
>>> On Tuesday, October 29, 2019 at 4:21:48 PM UTC-4, David Spencer wrote:
>> ...
>>>> It would not be compatible with
>>>>    int nocode = 0;
>>>>
>>>> which has been C since it was first conceived.
>>>
>>> New keywords have been added to C with each revision.
>>
>> Yes, and for quite some time now, the committee has been careful to
>> choose all new keywords from the name space reserved for
>> implementations, which therefore cannot cause problems for code that
>> strictly conformed to previous versions of the standard. I don't think
>> your suggestion has any significant chance of getting accepted into the
>> standard, but it would greatly increase that chance to use such a name,
>> such as _Nocode.
> 
> Never happen.  I think the use of features like that in a language,
> unless they are explicitly going out of their way to not be invasive
> in their name usage, are ridiculous.

The naming style _Nocode is picked /precisely/ not to be invasive - and
is thus an excellent choice.

Look at when C gained a boolean type.  They could not add a keyword
"bool" without conflict with a great deal of existing code.  So the name
of the type, and the new keyword, was _Bool.  But because people often
want a nicer name like "bool", they also made a <stdbool.h> file
consisting basically of :

	#define bool	_Bool
	#define true	1
	#define false	0

It gives you everything.  There is a keyword that does not conflict with
existing code, and people writing new code can easily use the nicer type
name "bool" after #include <stdbool.h>

If your proposal were accepted, the new keyword would be _Nocode.  And
there would be a new standard header, <stdnocode.h>, consisting of the
line :

	#define nocode _Nocode



> 
>     int8_t
>     int16_t
>     int32_t
>     int64_t
> 
> Why _t?

There are a number of reasons.  It makes it obvious to programmers and
readers that these are types, not variables.  It reduces the risk of
conflict with existing code.  It makes them stand out nicely.  They are
long enough that they won't be used for other things, short enough that
the are not onerous to type.  They follow the long tradition in C and
POSIX of using _t suffixes on types.

No choice would be considered "perfect" by everyone, but these names are
good enough for most people.

>  In CAlive I defined signed and unsigned:

Your language, your choice.

> 
>     s8, s16, s32, s64
>     u8, u16, u32, u64

There is such a thing as being /too/ short.  These don't carry the
information I would want in type names - and they risk conflict with
other uses.

> 
> And can you guess what these are?
> 
>     f32, f64, f80

Knowing the context, yes.  Without context, no, it would not be clear.
But "float32_t" and "float64_t" would be perfectly clear in all cases.
(Standard C does not have these types, but I think it should do.)

> 
>>> As with all new extensions, things in the past which use the
>>> new keywords / syntax will break.
>>
>> If you choose a reserved name as a keyword, all code which previously
>> used that keyword was already broken.
> 
> Exactly when was "auto" reserved by the C committee?  That C code
> I wrote that's been compiling all these years since the 1980s now
> breaks because they reserved the word auto in the 1990s?  2000s?
> 2010s?

"auto" has been around since the beginning of C (and perhaps from its
predecessors).  It has been pointless in code since at least C89/C90
(the first standardised C), but still exists for compatibility.  (C++
completely redefined its meaning with C++11.  I would like to see it
deprecated in C too, so that it can be re-used later.)

> 
> It doesn't matter.  I keep saying this, and it's hard for me to
> flatly and coldly turn my back on something or someone (it takes
> a real chain of events to make it happen), but I'm done with any
> attempt to improve C via the C Standard or such related.
> 

I am sure the C standards committee see this as a great loss.

Less sarcastically, the crux of your problem is cooperation.  C is a
language standardised by a committee.  Before changes are made, there
are discussions - opinions are swapped, ideas exchanged.  People
/listen/ far more than they talk, and they think about other people more
than themselves.  The standards committee make changes that they think
will be helpful for /others/ - they are not concerned about their own
coding.

You, on the other hand, are never willing to enter a proper discussion.
 You get an idea, and you fixate on it - convinced that it is something
miraculous and world-changing, and that you alone know the answer.  You
have no consideration for other people - you are concerned only with
your own coding.  You are unable to listen to other people's opinions,
thoughts or suggestions - you assume that anyone who does not agree with
you entirely is doing so through malice or, if you are feeling kind,
incompetence.

/That/ is why you cannot work with the C standards committee.

I hope - though it is highly unlikely - that you will read that and it
will give you the insight needed to change your attitude.  It is always
a good idea to try to work /with/ other people, rather than against
everyone.

> CAlive is my future.  End of story.
> 

Sadly for you, that may be the case.

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 05:26 -0700
  Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2019-10-25 15:53 +0200
    Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 07:26 -0700
      Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2020-08-04 11:00 +0200
  Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 11:04 -0700
  Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-25 23:42 +0100
    Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 22:20 -0400
      Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-26 22:52 +0100
        Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-26 23:27 +0100
        Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-26 17:19 -0700
  Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-25 22:10 -0300
    Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 19:02 -0700
      Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-28 23:45 -0400
        Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 08:15 -0400
          Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 08:42 -0400
          Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-29 22:37 -0400
            Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:10 -0700
    Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 18:45 +0200
  Re: Addition of nocode keyword Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2019-10-28 10:42 +0100
    Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-28 18:13 -0700
      Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 02:55 +0000
        Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 07:58 -0400
          Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 20:21 +0000
            Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 13:31 -0700
              Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-29 14:47 -0700
                Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 19:36 -0400
                Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-29 22:13 -0400
                Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:03 -0700
                Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 09:48 +0100
                Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:13 -0700
                Re: Addition of nocode keyword Keith Thompson <kst-u@mib.org> - 2019-10-30 08:40 -0700
                Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 09:44 -0700
                Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 18:30 +0100
                Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-30 08:12 -0700
                Re: Addition of nocode keyword Nick Bowler <nbowler@draconx.ca> - 2019-10-30 16:47 +0000
                Re: Addition of nocode keyword James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-30 13:30 -0400
                Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 18:37 +0100
                Re: Addition of nocode keyword Nick Bowler <nbowler@draconx.ca> - 2019-10-30 18:34 +0000
                Re: Addition of nocode keyword Keith Thompson <kst-u@mib.org> - 2019-10-31 10:14 -0700
                Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 21:29 -0400
                Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-31 08:37 -0700
                Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-31 09:38 -0700
                Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-31 19:50 +0100
                Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2020-08-04 11:18 +0200
                Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-11-01 07:20 -0700
              Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 23:46 +0000
                Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 21:41 -0400
              Re: Addition of nocode keyword guinness.tony@gmail.com - 2019-10-30 04:36 -0700
                Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-31 00:19 +0000
    Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-29 14:32 +0100
      Re: Addition of nocode keyword Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2019-10-29 17:41 +0100
        Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-29 23:24 +0100

csiph-web