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

Groups > comp.lang.c > #141995 > unrolled thread

[ On topic, amazingtly ]: labels and declarations

Back to article view | Back to comp.lang.c

Contents

  [ On topic, amazingtly ]: labels and declarations gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-17 14:45 +0000
    Re: [ On topic, amazingtly ]: labels and declarations nobody@example.org (Scott) - 2019-03-17 17:25 +0000
      Re: [ On topic, amazingtly ]: labels and declarations fir is a sexy shemale <cdalten@gmail.com> - 2019-03-17 10:59 -0700
    Re: [ On topic, amazingtly ]: labels and declarations Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-03-17 14:16 -0400
      Re: [ On topic, amazingtly ]: labels and declarations Richard Damon <Richard@Damon-Family.org> - 2019-03-17 18:43 -0400
        Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-17 22:55 +0000
          Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 01:37 +0000
          Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-17 19:46 -0700
            Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-18 08:41 +0100
              Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 11:20 +0000
                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 04:39 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 12:08 +0000
                    Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 05:26 -0700
                      labels and declarations and debugger breakpoints "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 05:40 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 17:25 +0000
                        Re: [ On topic, amazingtly ]: labels and declarations gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-18 19:11 +0000
                          Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-19 01:36 +0000
                        Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 12:31 -0700
                          Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 19:57 +0000
                            Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 13:09 -0700
                              Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 21:09 +0000
                                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 16:03 -0700
                                  Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 23:49 +0000
                                    Re: [ On topic, amazingtly ]: labels and declarations fir is a sexy shemale <cdalten@gmail.com> - 2019-03-18 16:53 -0700
                                    Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 18:03 -0700
                Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-18 13:16 +0100
                  Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 12:30 +0000
                    Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-18 13:41 +0100
                      Re: [ On topic, amazingtly ]: labels and declarations fir <profesor.fir@gmail.com> - 2019-03-18 06:54 -0700
                        Re: [ On topic, amazingtly ]: labels and declarations fir <profesor.fir@gmail.com> - 2019-03-18 07:05 -0700
                          Re: [ On topic, amazingtly ]: labels and declarations fir <profesor.fir@gmail.com> - 2019-03-18 09:07 -0700
              Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-18 06:46 -0700
                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 07:25 -0700
          Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-21 17:48 +0100
            Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-21 10:04 -0700
              Re: [ On topic, amazingtly ]: labels and declarations fir is a sexy shemale <cdalten@gmail.com> - 2019-03-21 10:34 -0700
              Re: [ On topic, amazingtly ]: labels and declarations Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-21 20:19 +0000
                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-21 14:29 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations Chad <cdalten@gmail.com> - 2019-03-22 10:15 -0700
                    Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-22 13:58 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations Chad <cdalten@gmail.com> - 2019-03-22 15:10 -0700
                        Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-22 15:31 -0700
                Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-22 09:22 +0100
                  Re: [ On topic, amazingtly ]: labels and declarations Chad <cdalten@gmail.com> - 2019-03-22 09:28 -0700
              Re: [ On topic, amazingtly ]: labels and declarations Manfred <invalid@add.invalid> - 2019-03-22 18:15 +0100
                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-22 10:51 -0700
                Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-22 11:31 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-23 17:43 +0100
                    Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-23 13:36 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations Richard Damon <Richard@Damon-Family.org> - 2019-03-23 17:37 -0400
                        Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-25 09:18 -0700
                Re: [ On topic, amazingtly ]: labels and declarations James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-22 12:59 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-22 14:03 -0700
                    Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-23 12:44 +0100
                      Re: [ On topic, amazingtly ]: labels and declarations Robert Wessel <robertwessel2@yahoo.com> - 2019-03-24 10:10 -0500
                  Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-23 17:48 +0100
                    Re: [ On topic, amazingtly ]: labels and declarations James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 11:32 -0700
            Re: [ On topic, amazingtly ]: labels and declarations Robert Wessel <robertwessel2@yahoo.com> - 2019-03-21 22:22 -0500
              Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-22 17:45 +0100
                Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-22 11:13 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-23 18:20 +0100
                    Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-23 11:57 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 10:58 -0700
                        Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-25 13:17 -0700
        Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-17 16:16 -0700
          Re: [ On topic, amazingtly ]: labels and declarations Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-03-17 19:29 -0400
            Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-17 16:49 -0700
              Re: [ On topic, amazingtly ]: labels and declarations Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-03-17 19:51 -0400
              Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-17 17:41 -0700
                Re: [ On topic, amazingtly ]: labels and declarations Richard Damon <Richard@Damon-Family.org> - 2019-03-17 22:53 -0400
                  Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-17 21:08 -0700
                    Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-17 21:40 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-18 05:03 +0000
                        Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 02:30 -0700
                        Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-18 06:32 -0700
                          Re: [ On topic, amazingtly ]: labels and declarations gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-18 16:06 +0000
                  Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-17 22:19 -0700
          Re: [ On topic, amazingtly ]: labels and declarations Richard Damon <Richard@Damon-Family.org> - 2019-03-17 20:07 -0400
    Re: [ On topic, amazingtly ]: labels and declarations luser droog <luser.droog@gmail.com> - 2019-03-17 12:37 -0700
    Re: [ On topic, amazingtly ]: labels and declarations "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-18 11:00 +0800
      Re: [ On topic, amazingtly ]: labels and declarations "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-18 22:43 +0800
        Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 08:00 -0700
          Re: [ On topic, amazingtly ]: labels and declarations "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 13:11 +0800
            Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-19 05:27 +0000
              Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 14:40 +0800
              Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-19 04:39 -0700
                Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 19:44 +0800
                  Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:11 -0700
                    Re: Use of goto in high-level C programming "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 20:13 +0800
                      Re: Use of goto in high-level C programming fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:42 -0700
                        Re: Use of goto in high-level C programming "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 20:44 +0800
                      Re: Use of goto in high-level C programming Wouter Verhelst <w@uter.be> - 2019-03-20 08:16 +0200
                        Re: Use of goto in high-level C programming "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-20 19:16 +0800
                Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:13 -0700
                  Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-19 05:56 -0700
                    Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 06:30 -0700
                      Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-19 06:54 -0700
                        Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 07:12 -0700
                          Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-19 12:03 -0700
                            Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 13:33 -0700
    Re: [ On topic, amazingtly ]: labels and declarations fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:17 -0700
      Re: from programming to religion and then.... sex? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 20:23 +0800
        Re: from programming to religion and then.... sex? fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:40 -0700
          Re: from programming to religion and then.... sex? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 20:46 +0800
            Re: from programming to religion and then.... sex? fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 06:30 -0700
              Re: from programming to religion and then.... sex? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 21:36 +0800
                Re: from programming to religion and then.... sex? fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 07:08 -0700
                  Re: from programming to religion and then.... sex? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-20 19:16 +0800
    Re: [ On topic, amazingtly ]: labels and declarations John Bode <jfbode1029@gmail.com> - 2019-03-19 14:58 -0700

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#142046

On 18/03/2019 20:09, Rick C. Hodgin wrote:
> On Monday, March 18, 2019 at 3:58:12 PM UTC-4, Bart wrote:

>> I think that would make things too complex. Either L1 is a statement by
>> itself or it isn't. It shouldn't only be independent in some cases and
>> not in others. The rule should be unequivocal.
> 
> It would be unequivocal, but it would be two different operations.
> (1) stand-alone label
> (2) label that's the entry point of a flow control block

Which of the following labels will be stand-alone:

    {L1: L2: L3: L4: S1;}

What about now:

    {L1: L2: L3: L4:}


> In the case of (2) it simply identifies the serves as a placeholder
> which points to the next statement within.
> 
>> So L1:S1, which is anyway going to be extremely rare, needs to be
>> written as {L1: S1;}.
> 
> I agree that it is rare.  I don't think it exists in most code, but
> it could exist.  And I don't agree with the solution of forcing
> developers to create { this; solution; }.  I would rather not break
> existing code, so by creating the (1) and (2) breakout above, no
> existing code would break (at least none that I can think of right
> now).

It could break new code. Someone could write, in a new program:

   if (C) L1: S1;

expecting S1 to be unconditional, then be puzzled why it's tied to 
condition C.

(Nobody would deliberately write this, but with the use of macros in C 
you never know how it's going to end up.)

[toc] | [prev] | [next] | [standalone]

#142047

On Monday, March 18, 2019 at 5:10:12 PM UTC-4, Bart wrote:
> On 18/03/2019 20:09, Rick C. Hodgin wrote:
> > On Monday, March 18, 2019 at 3:58:12 PM UTC-4, Bart wrote:
> 
> >> I think that would make things too complex. Either L1 is a statement by
> >> itself or it isn't. It shouldn't only be independent in some cases and
> >> not in others. The rule should be unequivocal.
> > 
> > It would be unequivocal, but it would be two different operations.
> > (1) stand-alone label
> > (2) label that's the entry point of a flow control block
> 
> Which of the following labels will be stand-alone:
> 
>     {L1: L2: L3: L4: S1;}

Under the new proposal, with the (2) rule above, all of the ones
which exist before the first real statement S1.

> What about now:
> 
>     {L1: L2: L3: L4:}

There's an implied empty statement after L4, and it would be the
first statement.

> > In the case of (2) it simply identifies the serves as a placeholder
> > which points to the next statement within.
> > 
> >> So L1:S1, which is anyway going to be extremely rare, needs to be
> >> written as {L1: S1;}.
> > 
> > I agree that it is rare.  I don't think it exists in most code, but
> > it could exist.  And I don't agree with the solution of forcing
> > developers to create { this; solution; }.  I would rather not break
> > existing code, so by creating the (1) and (2) breakout above, no
> > existing code would break (at least none that I can think of right
> > now).
> 
> It could break new code. Someone could write, in a new program:
> 
>    if (C) L1: S1;
> 
> expecting S1 to be unconditional, then be puzzled why it's tied to 
> condition C.

They'd have to know the rules to use the new features.

> (Nobody would deliberately write this, but with the use of macros in C 
> you never know how it's going to end up.)

They would need to re-write it to be:

    if (C) L1:; S1;

Of course, anyone who wrote code like that is just asking for
trouble anyway.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142048

On 18/03/2019 23:03, Rick C. Hodgin wrote:
> On Monday, March 18, 2019 at 5:10:12 PM UTC-4, Bart wrote:
>> On 18/03/2019 20:09, Rick C. Hodgin wrote:
>>> On Monday, March 18, 2019 at 3:58:12 PM UTC-4, Bart wrote:
>>
>>>> I think that would make things too complex. Either L1 is a statement by
>>>> itself or it isn't. It shouldn't only be independent in some cases and
>>>> not in others. The rule should be unequivocal.
>>>
>>> It would be unequivocal, but it would be two different operations.
>>> (1) stand-alone label
>>> (2) label that's the entry point of a flow control block
>>
>> Which of the following labels will be stand-alone:
>>
>>      {L1: L2: L3: L4: S1;}
> 
> Under the new proposal, with the (2) rule above, all of the ones
> which exist before the first real statement S1.
> 
>> What about now:
>>
>>      {L1: L2: L3: L4:}
> 
> There's an implied empty statement after L4, and it would be the
> first statement.

Here's that last example expressed as an AST using my compiler in 
conforming mode (in that mode, a ";" needs to be inserted after L4:):

|---1 block:
|---|---1 labelstmt: L1
|---|---|---1 labelstmt: L2
|---|---|---|---1 labelstmt: L3
|---|---|---|---|---1 labelstmt: L4

Here's the AST when labels are independent statements:

|---1 block:
|---|---1 labelstmt: L1
|---|---1 labelstmt: L2
|---|---1 labelstmt: L3
|---|---1 labelstmt: L4

Note how much more sensible this form is, and therefore how nonsensical 
the other must be. If there were 20 such labels, they would disappear 
off the right edge of the screen, rather than be a simple linear list. 
There is no reason a series of labels needs to form a hierarchy like that.

[toc] | [prev] | [next] | [standalone]

#142049

We can just make this entire debate moot by switching over to Common Lisp.

[toc] | [prev] | [next] | [standalone]

#142050

On Monday, March 18, 2019 at 7:50:09 PM UTC-4, Bart wrote:
> On 18/03/2019 23:03, Rick C. Hodgin wrote:
> > On Monday, March 18, 2019 at 5:10:12 PM UTC-4, Bart wrote:
> >> What about now:
> >>
> >>      {L1: L2: L3: L4:}
> > 
> > There's an implied empty statement after L4, and it would be the
> > first statement.
> 
> Here's that last example expressed as an AST using my compiler in 
> conforming mode (in that mode, a ";" needs to be inserted after L4:):
> 
> |---1 block:
> |---|---1 labelstmt: L1
> |---|---|---1 labelstmt: L2
> |---|---|---|---1 labelstmt: L3
> |---|---|---|---|---1 labelstmt: L4
> 
> Here's the AST when labels are independent statements:
> 
> |---1 block:
> |---|---1 labelstmt: L1
> |---|---1 labelstmt: L2
> |---|---1 labelstmt: L3
> |---|---1 labelstmt: L4
> 
> Note how much more sensible this form is, and therefore how nonsensical 
> the other must be. If there were 20 such labels, they would disappear 
> off the right edge of the screen, rather than be a simple linear list. 
> There is no reason a series of labels needs to form a hierarchy like that.

You could revise your methodology so you can attack the goal from
one or two directions.  (1) Goes through traditional AST,  (2) is
another form that uses a separate layer providing additional in-
jection abilities at reference points.  In this case, it would
make some assumptions on block starts / stops, for example, and
would look like this:

    |---1 block:
    |---|---1 entry point
    |---|
    |---|--- ... whatever normal logic goes here
    |---|
    |---|---N exit point

Your 1 entry point reference would exist as a fixed target, and
you can reference whatever you need from that point.

In CAlive, I use this with a particular node direction indicating
things which are attached to a location, but are not part of the
normal AST.

CAlive uses this primarily for its use of casks (which allow for
arbitrary injection of code or logic in the middle of otherwise
syntactically correct statements or expressions), and for the way
it handles fif () { .. } statements (full ifs, which examine all
of the expressions within and does not include an early-out on
logic failure, but rather stores the result of each conditional
making those results available for examination and post-processing
traditionally the logic and flow control navigation).

The cask concept required me to design this way of handling logic.
It's not something I referenced in research, but developed it on
my own.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142022

On 18/03/2019 12:20, Bart wrote:
> On 18/03/2019 07:41, David Brown wrote:
>> On 18/03/2019 03:46, Tim Rentsch wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> [..allowing labels on declarations..]
>>>>
>>>> How about just allowing a label to be statement by itself?
>>>
>>> Not workable for C because it breaks existing code.
>>>
>>
>> Would it break much?  It would break this:
>>
>>     if (x) L1: foo();
>>
>> Do you think there is much existing code that would go wrong if labels
>> were made statements?  Apart from case labels (obviously), labels and
>> gotos are mostly used to break out of nested loops or handle error
>> conditions, and these should be fine.
>>
>> (Of course, the fact that this change could break any existing code at
>> all is enough to give strong resistance to it - I am not suggesting that
>> it's okay as long as it doesn't break much!)
> 
> Such examples (conditional blocks consisting of one label statement) are
> easily detected, and can be fixed, eg. by writing:
> 
>     if (x) {L1: foo();}

True - but no one wants to make changes to the source code here.  The
whole point of backwards compatibility - which is C's strongest
advantage, and also the biggest millstone round its neck - is that you
don't make changes to the language definition which could require
changes to existing source code.  It doesn't matter how easy it would be
to make the changes or to detect where they are needed.

[toc] | [prev] | [next] | [standalone]

#142024

On 18/03/2019 12:16, David Brown wrote:
> On 18/03/2019 12:20, Bart wrote:

>> Such examples (conditional blocks consisting of one label statement) are
>> easily detected, and can be fixed, eg. by writing:
>>
>>      if (x) {L1: foo();}
> 
> True - but no one wants to make changes to the source code here.  The
> whole point of backwards compatibility - which is C's strongest
> advantage, and also the biggest millstone round its neck - is that you
> don't make changes to the language definition which could require
> changes to existing source code.  It doesn't matter how easy it would be
> to make the changes or to detect where they are needed.
> 

My compiler has an -old option, normally disabled. If modifying existing 
source to fix things like:

    int fn() {...}

is too onerous, or not practical (eg. not my code to modify), then using 
-old will turn a blind eye to those, and enable the compiler to get past 
such obstacles.

But where it is practical, then those changes will be made.

This is the opposite attitude to just pandering to all such bad design 
decisions and encouraging people to (1) do nothing about existing code; 
(2) continue coding using the same bad habits and thus perpetuating the 
body of bad or dated code.

It doesn't need a change to the definition either; allowing labels as 
statements rather than prefixes to statements, can be an extension.

[toc] | [prev] | [next] | [standalone]

#142026

On 18/03/2019 13:30, Bart wrote:
> On 18/03/2019 12:16, David Brown wrote:
>> On 18/03/2019 12:20, Bart wrote:
> 
>>> Such examples (conditional blocks consisting of one label statement) are
>>> easily detected, and can be fixed, eg. by writing:
>>>
>>>      if (x) {L1: foo();}
>>
>> True - but no one wants to make changes to the source code here.  The
>> whole point of backwards compatibility - which is C's strongest
>> advantage, and also the biggest millstone round its neck - is that you
>> don't make changes to the language definition which could require
>> changes to existing source code.  It doesn't matter how easy it would be
>> to make the changes or to detect where they are needed.
>>
> 
> My compiler has an -old option, normally disabled. If modifying existing
> source to fix things like:
> 
>    int fn() {...}
> 
> is too onerous, or not practical (eg. not my code to modify), then using
> -old will turn a blind eye to those, and enable the compiler to get past
> such obstacles.
> 
> But where it is practical, then those changes will be made.
> 
> This is the opposite attitude to just pandering to all such bad design
> decisions and encouraging people to (1) do nothing about existing code;
> (2) continue coding using the same bad habits and thus perpetuating the
> body of bad or dated code.
> 

Yes, but your compiler is not intended to be a standard C compiler or a
replacement for normal C compilers.  It is designed to handle the C
/you/ write in the way that suits /you/ best, and maybe work with third
party C code that you have found useful and have tested.  That is fair
enough, of course, because it is exactly what you need and want to
create.  But other C compilers can't play by those rules.

Other C compilers can, of course, have extensions, or flags that affect
behaviour.  But something that could affect the behaviour of existing
code is going to have a flag to provide the new behaviour, not a flag to
enable the old behaviour.  And the change will only be made if it is
particularly useful - this one is not.

(There is also no reason I can think of to suppose code affected by such
changes would be "old" code.  I think it is more likely to be an issue
with generated C code, rather than hand-written code of any type.)


> It doesn't need a change to the definition either; allowing labels as
> statements rather than prefixes to statements, can be an extension.

[toc] | [prev] | [next] | [standalone]

#142030

W dniu poniedziałek, 18 marca 2019 13:41:18 UTC+1 użytkownik David Brown napisał:
> On 18/03/2019 13:30, Bart wrote:
> > On 18/03/2019 12:16, David Brown wrote:
> >> On 18/03/2019 12:20, Bart wrote:
> > 
> >>> Such examples (conditional blocks consisting of one label statement) are
> >>> easily detected, and can be fixed, eg. by writing:
> >>>
> >>>      if (x) {L1: foo();}
> >>
> >> True - but no one wants to make changes to the source code here.  The
> >> whole point of backwards compatibility - which is C's strongest
> >> advantage, and also the biggest millstone round its neck - is that you
> >> don't make changes to the language definition which could require
> >> changes to existing source code.  It doesn't matter how easy it would be
> >> to make the changes or to detect where they are needed.
> >>
> > 
> > My compiler has an -old option, normally disabled. If modifying existing
> > source to fix things like:
> > 
> >    int fn() {...}
> > 
> > is too onerous, or not practical (eg. not my code to modify), then using
> > -old will turn a blind eye to those, and enable the compiler to get past
> > such obstacles.
> > 
> > But where it is practical, then those changes will be made.
> > 
> > This is the opposite attitude to just pandering to all such bad design
> > decisions and encouraging people to (1) do nothing about existing code;
> > (2) continue coding using the same bad habits and thus perpetuating the
> > body of bad or dated code.
> > 
> 
> Yes, but your compiler is not intended to be a standard C compiler or a
> replacement for normal C compilers.  It is designed to handle the C
> /you/ write in the way that suits /you/ best, and maybe work with third
> party C code that you have found useful and have tested.  That is fair
> enough, of course, because it is exactly what you need and want to
> create.  But other C compilers can't play by those rules.
> 
> Other C compilers can, of course, have extensions, or flags that affect
> behaviour.  But something that could affect the behaviour of existing
> code is going to have a flag to provide the new behaviour, not a flag to
> enable the old behaviour.  And the change will only be made if it is
> particularly useful - this one is not.
> 
> (There is also no reason I can think of to suppose code affected by such
> changes would be "old" code.  I think it is more likely to be an issue
> with generated C code, rather than hand-written code of any type.)
> 
> 
> > It doesn't need a change to the definition either; allowing labels as
> > statements rather than prefixes to statements, can be an extension.

yhe problem with this thread as with 90% of threads here on clc is that it is (to use some phrase i somewhere heard) 
"ONE BIG DISTRACTION"

(i mean it moves focus ou of important things, [imo] and important things being 
creative things... i mean things aimed on creating some content by the usage of c language not by language itself (which is dull, mostly 'empty' unproductive activity)

(there are some exceptions to this what i say, becouse when discussing something which is important and has some value may be somtimes worth it - but this is only SOMETIMES, generally its in 99% one big distraction

this group needs to be turned into discussing on content making (whatever interesting that would be)

[toc] | [prev] | [next] | [standalone]

#142031

W dniu poniedziałek, 18 marca 2019 14:54:22 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 18 marca 2019 13:41:18 UTC+1 użytkownik David Brown napisał:
> > On 18/03/2019 13:30, Bart wrote:
> > > On 18/03/2019 12:16, David Brown wrote:
> > >> On 18/03/2019 12:20, Bart wrote:
> > > 
> > >>> Such examples (conditional blocks consisting of one label statement) are
> > >>> easily detected, and can be fixed, eg. by writing:
> > >>>
> > >>>      if (x) {L1: foo();}
> > >>
> > >> True - but no one wants to make changes to the source code here.  The
> > >> whole point of backwards compatibility - which is C's strongest
> > >> advantage, and also the biggest millstone round its neck - is that you
> > >> don't make changes to the language definition which could require
> > >> changes to existing source code.  It doesn't matter how easy it would be
> > >> to make the changes or to detect where they are needed.
> > >>
> > > 
> > > My compiler has an -old option, normally disabled. If modifying existing
> > > source to fix things like:
> > > 
> > >    int fn() {...}
> > > 
> > > is too onerous, or not practical (eg. not my code to modify), then using
> > > -old will turn a blind eye to those, and enable the compiler to get past
> > > such obstacles.
> > > 
> > > But where it is practical, then those changes will be made.
> > > 
> > > This is the opposite attitude to just pandering to all such bad design
> > > decisions and encouraging people to (1) do nothing about existing code;
> > > (2) continue coding using the same bad habits and thus perpetuating the
> > > body of bad or dated code.
> > > 
> > 
> > Yes, but your compiler is not intended to be a standard C compiler or a
> > replacement for normal C compilers.  It is designed to handle the C
> > /you/ write in the way that suits /you/ best, and maybe work with third
> > party C code that you have found useful and have tested.  That is fair
> > enough, of course, because it is exactly what you need and want to
> > create.  But other C compilers can't play by those rules.
> > 
> > Other C compilers can, of course, have extensions, or flags that affect
> > behaviour.  But something that could affect the behaviour of existing
> > code is going to have a flag to provide the new behaviour, not a flag to
> > enable the old behaviour.  And the change will only be made if it is
> > particularly useful - this one is not.
> > 
> > (There is also no reason I can think of to suppose code affected by such
> > changes would be "old" code.  I think it is more likely to be an issue
> > with generated C code, rather than hand-written code of any type.)
> > 
> > 
> > > It doesn't need a change to the definition either; allowing labels as
> > > statements rather than prefixes to statements, can be an extension.
> 
> yhe problem with this thread as with 90% of threads here on clc is that it is (to use some phrase i somewhere heard) 
> "ONE BIG DISTRACTION"
> 
> (i mean it moves focus ou of important things, [imo] and important things being 
> creative things... i mean things aimed on creating some content by the usage of c language not by language itself (which is dull, mostly 'empty' unproductive activity)
> 
> (there are some exceptions to this what i say, becouse when discussing something which is important and has some value may be somtimes worth it - but this is only SOMETIMES, generally its in 99% one big distraction
> 
> this group needs to be turned into discussing on content making (whatever interesting that would be)

i may add, in old 'golden era of programming' or 'golden era of computers',i belive people was able of
discussing content (this what i call as programming content, program content)
and i think thek knewed that this is itself much fun in programming - creation, content making

now in much more 'dog' times they like
totally turned into discussing language,
or sharing some discusiion on common errors, or a bit of ideology or news sometimes etc - but they totally forgot about discusing content 

(and i personally as i said really dont like it... the huestion is if only this group or some another is able to turn into more vivid content discussion or if
it is lost for good.... (i dont know, i personally think there are some chanses though slight)

[toc] | [prev] | [next] | [standalone]

#142039

W dniu poniedziałek, 18 marca 2019 15:05:28 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 18 marca 2019 14:54:22 UTC+1 użytkownik fir napisał:
> > W dniu poniedziałek, 18 marca 2019 13:41:18 UTC+1 użytkownik David Brown napisał:
> > > On 18/03/2019 13:30, Bart wrote:
> > > > On 18/03/2019 12:16, David Brown wrote:
> > > >> On 18/03/2019 12:20, Bart wrote:
> > > > 
> > > >>> Such examples (conditional blocks consisting of one label statement) are
> > > >>> easily detected, and can be fixed, eg. by writing:
> > > >>>
> > > >>>      if (x) {L1: foo();}
> > > >>
> > > >> True - but no one wants to make changes to the source code here.  The
> > > >> whole point of backwards compatibility - which is C's strongest
> > > >> advantage, and also the biggest millstone round its neck - is that you
> > > >> don't make changes to the language definition which could require
> > > >> changes to existing source code.  It doesn't matter how easy it would be
> > > >> to make the changes or to detect where they are needed.
> > > >>
> > > > 
> > > > My compiler has an -old option, normally disabled. If modifying existing
> > > > source to fix things like:
> > > > 
> > > >    int fn() {...}
> > > > 
> > > > is too onerous, or not practical (eg. not my code to modify), then using
> > > > -old will turn a blind eye to those, and enable the compiler to get past
> > > > such obstacles.
> > > > 
> > > > But where it is practical, then those changes will be made.
> > > > 
> > > > This is the opposite attitude to just pandering to all such bad design
> > > > decisions and encouraging people to (1) do nothing about existing code;
> > > > (2) continue coding using the same bad habits and thus perpetuating the
> > > > body of bad or dated code.
> > > > 
> > > 
> > > Yes, but your compiler is not intended to be a standard C compiler or a
> > > replacement for normal C compilers.  It is designed to handle the C
> > > /you/ write in the way that suits /you/ best, and maybe work with third
> > > party C code that you have found useful and have tested.  That is fair
> > > enough, of course, because it is exactly what you need and want to
> > > create.  But other C compilers can't play by those rules.
> > > 
> > > Other C compilers can, of course, have extensions, or flags that affect
> > > behaviour.  But something that could affect the behaviour of existing
> > > code is going to have a flag to provide the new behaviour, not a flag to
> > > enable the old behaviour.  And the change will only be made if it is
> > > particularly useful - this one is not.
> > > 
> > > (There is also no reason I can think of to suppose code affected by such
> > > changes would be "old" code.  I think it is more likely to be an issue
> > > with generated C code, rather than hand-written code of any type.)
> > > 
> > > 
> > > > It doesn't need a change to the definition either; allowing labels as
> > > > statements rather than prefixes to statements, can be an extension.
> > 
> > yhe problem with this thread as with 90% of threads here on clc is that it is (to use some phrase i somewhere heard) 
> > "ONE BIG DISTRACTION"
> > 
> > (i mean it moves focus ou of important things, [imo] and important things being 
> > creative things... i mean things aimed on creating some content by the usage of c language not by language itself (which is dull, mostly 'empty' unproductive activity)
> > 
> > (there are some exceptions to this what i say, becouse when discussing something which is important and has some value may be somtimes worth it - but this is only SOMETIMES, generally its in 99% one big distraction
> > 
> > this group needs to be turned into discussing on content making (whatever interesting that would be)
> 
> i may add, in old 'golden era of programming' or 'golden era of computers',i belive people was able of
> discussing content (this what i call as programming content, program content)
> and i think thek knewed that this is itself much fun in programming - creation, content making
> 
> now in much more 'dog' times they like
> totally turned into discussing language,
> or sharing some discusiion on common errors, or a bit of ideology or news sometimes etc - but they totally forgot about discusing content 
> 
> (and i personally as i said really dont like it... the huestion is if only this group or some another is able to turn into more vivid content discussion or if
> it is lost for good.... (i dont know, i personally think there are some chanses though slight)

i also may add 

((i talk on this as i realy
would like this group be more usable (for 
everybody) improving creativity of all 
sides/users not simply dwelling always and all the time in that big distraction mentioned ))

that i know that talking on "program content" is by nature harder as when doscissing some c language topic all users who knows c just know this topic 
so there is wide group of users involved
-- when instead of talking on that or that specific content of specific program
mosy users are just not in that topic
(they never coded that, dont want to code it at all etc) so that topics are likely 
to be ignored.. its normal

hovever i want to say if there is some opportunity of focusing some users on one
program content topic, the opportunity could be taken (as it may be somewhat 'profitable', (create bigger fun and knowledge) that kind of fun is just worth it.. its the stuff that real coders 
or hackers should look like

this may sound like a theory but this is some thing i think i realize... its realy 
good to understood those things "big distraction" and "program content"

(harder to make people understood it, and make them realy focusing on some content and go right creative way (instead of
dwelling into big distraction for decades ;c)

[toc] | [prev] | [next] | [standalone]

#142029

David Brown <david.brown@hesbynett.no> writes:

> On 18/03/2019 03:46, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>>> [..allowing labels on declarations..]
>>>
>>> How about just allowing a label to be statement by itself?
>>
>> Not workable for C because it breaks existing code.
>
> Would it break much?  [...]

I don't know how much code would be broken, except that I'm sure
the amount is greater than zero.  That gives the proposition as
a whole a negative ROI, which is more than enough to summarily
dismiss it.

[toc] | [prev] | [next] | [standalone]

#142033

On Monday, March 18, 2019 at 9:46:13 AM UTC-4, Tim Rentsch wrote:
> > On 18/03/2019 03:46, Tim Rentsch wrote:
> >> Not workable for C because it breaks existing code.
> 
> I don't know how much code would be broken, except that I'm sure
> the amount is greater than zero.  That gives the proposition as
> a whole a negative ROI, which is more than enough to summarily
> dismiss it.

Compiler authors could enable a diagnostic to signify when this
particular feature alters normal code flow.  It would be easy to
run a compilation pass and capture the places where it breaks
existing code and then manually fix it up.  A utility could even
be written which brings up all cases where it would be an issue,
allowing some pre-canned fixes.

It might be interesting for Kenny to write a quick parser to scan
through major C/C++ source code bases and identify any cases which
would break where this would be employed.  I'd wager he wouldn't
find any.

I don't see the purpose of this addition, but it is wholly workable
if people wanted to add it to the language.  It's a feature that
could exist and I see no reason not to add it.

I personally have added "nocode;" as a statement to CAlive, which
serves as a placeholder to indicate there is intended to be no code
in that location, and that it wasn't forgotten by accident.  It
would come in handy in places where a destination target is at the
end of block, for example:

        if (x)
        {
            if (y)
                goto end_of_block;

            // Other code:

    end_of_block:
        }

In CAlive, you could use:

        if (x)
        {
            if (y)
                goto end_of_block;

            // Other code:

    end_of_block:
            nocode;
        }

It would serve as a visible cue that the target was correct, and
that there is no code after that label that was expected.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142184

On 3/17/2019 11:55 PM, Bart wrote:
> On 17/03/2019 22:43, Richard Damon wrote:
>> On 3/17/19 2:16 PM, Lew Pitcher wrote:
>>> According to the standard, yes. My personal opinion is that, since C99,
>>> declarations have become statement-like (in that they now specify "an 
>>> action
>>> to be performed"; the (possibly conditional and code-path dependant)
>>> declaration of an object or objects[3]), and thus /should/ be 
>>> permitted to
>>> carry a label.
>>
>> I looked at the grammer, and realized that the simplest way to do this:
>>
>> * Change the production declaration to the now be named
>> declaration-statement (and moving all the pieces of declaration)
>>
>> * Adding the new declaration-statement to be one of the options for a
>> statement
>>
>> * Changing the definition of block-list to be:
>> statement
>> block-item-list statement
>>
>> (i.e. using statement instead of block-item which is a decclaration or a
>> statement since that is now just a statement).
>>
>>
>> This unfortunately leads to the following being grammatically correct:
> ....
>> The issue is that currently, the way a statement isn't a declaration,
>> means that declarations can't be used directly in control/conditional
>> statements, but only via a compound-statement, which introduces a scope,
>> so the declarations can't 'leak out'.
> 
> 
> How about just allowing a label to be statement by itself? You should be 
> able to do:
> 
>    {s1; goto L1; s2; s3; L1:}
> 
> without requiring L1 to be followed by a dummy statement.
> 

As Tim Rentsch pointed out, this is not backwards compatible, so too 
much impractical for a language like C, especially considering that the 
alternative of adding an extra ';' is not too difficult (once you know it).
Otherwise, I think this would have been a smart solution. Probably 
better than making declarations into statements, which would require 
much more work on the general scoping rules.

This problem apparently follows from labels being neither statements nor 
declarations, but instead entities of their own slapped into the 
language to pair their ASM counterparts.
Today one may say they were not thought well enough in the beginning, 
but considering the status of CS in the '70s it would have been probably 
hard to foresee this kind of implications at the time, and hey, they 
served the purpose so far.

[toc] | [prev] | [next] | [standalone]

#142187

On Thursday, March 21, 2019 at 12:48:54 PM UTC-4, Manfred wrote:
> On 3/17/2019 11:55 PM, Bart wrote:
> > On 17/03/2019 22:43, Richard Damon wrote:
> >> On 3/17/19 2:16 PM, Lew Pitcher wrote:
> >>> According to the standard, yes. My personal opinion is that, since C99,
> >>> declarations have become statement-like (in that they now specify "an 
> >>> action
> >>> to be performed"; the (possibly conditional and code-path dependant)
> >>> declaration of an object or objects[3]), and thus /should/ be 
> >>> permitted to
> >>> carry a label.
> >>
> >> I looked at the grammer, and realized that the simplest way to do this:
> >>
> >> * Change the production declaration to the now be named
> >> declaration-statement (and moving all the pieces of declaration)
> >>
> >> * Adding the new declaration-statement to be one of the options for a
> >> statement
> >>
> >> * Changing the definition of block-list to be:
> >> statement
> >> block-item-list statement
> >>
> >> (i.e. using statement instead of block-item which is a decclaration or a
> >> statement since that is now just a statement).
> >>
> >>
> >> This unfortunately leads to the following being grammatically correct:
> > ....
> >> The issue is that currently, the way a statement isn't a declaration,
> >> means that declarations can't be used directly in control/conditional
> >> statements, but only via a compound-statement, which introduces a scope,
> >> so the declarations can't 'leak out'.
> > 
> > 
> > How about just allowing a label to be statement by itself? You should be 
> > able to do:
> > 
> >    {s1; goto L1; s2; s3; L1:}
> > 
> > without requiring L1 to be followed by a dummy statement.
> 
> As Tim Rentsch pointed out, this is not backwards compatible, so too 
> much impractical for a language like C, especially considering that the 
> alternative of adding an extra ';' is not too difficult (once you know it).

I do not understand this limitation people impose upon C.

There is no problem maintaining backward compatibility when adding
new features ... if those features are not enabled by default, but
are enabled via some switch.

You can add new features to a language which must be enabled to be
used.  Once enabled, only then it would break backward compatibility.

But to not add any new features (and not particularly this one, but
more of an "in general" concept) because they may break backward
compatibility ... I think that's a wrong philosophy, a wrong way of
thinking, and a wrong decision.

New features SHOULD be added.  And if there's legitimate concern
about it breaking non-trivial amounts of code, then it should be
added as a feature which must be enabled.  But, new features should
be made available to developers in a language over time.

> Otherwise, I think this would have been a smart solution. Probably 
> better than making declarations into statements, which would require 
> much more work on the general scoping rules.
> 
> This problem apparently follows from labels being neither statements nor 
> declarations, but instead entities of their own slapped into the 
> language to pair their ASM counterparts.
> Today one may say they were not thought well enough in the beginning, 
> but considering the status of CS in the '70s it would have been probably 
> hard to foresee this kind of implications at the time, and hey, they 
> served the purpose so far.

I've observed an entire philosophy in many people of the C language
that seems to be 100% backward from the way things should be.  I
don't know what the cause of that is, and I don't remember seeing
it any place else except in some aspects of UNIX/Linux's design.

It's like this whole backward ecosystem rose out of K&R and Stallman
and other early adopters which pushed to make it all public, and it's
persisted that way from their initial seeds.

The idea of creating a language which operates on minimums ... it
does make sense in the 70s, 80s, and probably even 90s, but not in
the 00s, and certainly not in the 10s or 20s.

Those seeds need to be supplanted with new long-term seeds which do
make real sense.

The existing C compilers and code which exist can continue to be
compiled, and new features can be added, and changes can be made,
without breaking anything historically.

The biggest ones I'd like to see is the removal of the requirement
of having forward declarations.  Our computers today are fast enough
we do not need that extra workload for the developer any longer.

Another one for C would be the introduction of the basic class.  It
is a beautiful way to write code, though it could use some changes
in syntax to make it more beautiful (especially for accessor methods).

Such simple augments to save man-weeks of work per developer per
year if properly employed with inheritance and the like.

If only...

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142191

On Thursday, March 21, 2019 at 10:04:40 AM UTC-7, Rick C. Hodgin wrote:
> On Thursday, March 21, 2019 at 12:48:54 PM UTC-4, Manfred wrote:
> > On 3/17/2019 11:55 PM, Bart wrote:
> > > On 17/03/2019 22:43, Richard Damon wrote:
> > >> On 3/17/19 2:16 PM, Lew Pitcher wrote:
> > >>> According to the standard, yes. My personal opinion is that, since C99,
> > >>> declarations have become statement-like (in that they now specify "an 
> > >>> action
> > >>> to be performed"; the (possibly conditional and code-path dependant)
> > >>> declaration of an object or objects[3]), and thus /should/ be 
> > >>> permitted to
> > >>> carry a label.
> > >>
> > >> I looked at the grammer, and realized that the simplest way to do this:
> > >>
> > >> * Change the production declaration to the now be named
> > >> declaration-statement (and moving all the pieces of declaration)
> > >>
> > >> * Adding the new declaration-statement to be one of the options for a
> > >> statement
> > >>
> > >> * Changing the definition of block-list to be:
> > >> statement
> > >> block-item-list statement
> > >>
> > >> (i.e. using statement instead of block-item which is a decclaration or a
> > >> statement since that is now just a statement).
> > >>
> > >>
> > >> This unfortunately leads to the following being grammatically correct:
> > > ....
> > >> The issue is that currently, the way a statement isn't a declaration,
> > >> means that declarations can't be used directly in control/conditional
> > >> statements, but only via a compound-statement, which introduces a scope,
> > >> so the declarations can't 'leak out'.
> > > 
> > > 
> > > How about just allowing a label to be statement by itself? You should be 
> > > able to do:
> > > 
> > >    {s1; goto L1; s2; s3; L1:}
> > > 
> > > without requiring L1 to be followed by a dummy statement.
> > 
> > As Tim Rentsch pointed out, this is not backwards compatible, so too 
> > much impractical for a language like C, especially considering that the 
> > alternative of adding an extra ';' is not too difficult (once you know it).
> 
> I do not understand this limitation people impose upon C.
> 
> There is no problem maintaining backward compatibility when adding
> new features ... if those features are not enabled by default, but
> are enabled via some switch.
> 
> You can add new features to a language which must be enabled to be
> used.  Once enabled, only then it would break backward compatibility.
> 
> But to not add any new features (and not particularly this one, but
> more of an "in general" concept) because they may break backward
> compatibility ... I think that's a wrong philosophy, a wrong way of
> thinking, and a wrong decision.
> 
> New features SHOULD be added.  And if there's legitimate concern
> about it breaking non-trivial amounts of code, then it should be
> added as a feature which must be enabled.  But, new features should
> be made available to developers in a language over time.
> 
> > Otherwise, I think this would have been a smart solution. Probably 
> > better than making declarations into statements, which would require 
> > much more work on the general scoping rules.
> > 
> > This problem apparently follows from labels being neither statements nor 
> > declarations, but instead entities of their own slapped into the 
> > language to pair their ASM counterparts.
> > Today one may say they were not thought well enough in the beginning, 
> > but considering the status of CS in the '70s it would have been probably 
> > hard to foresee this kind of implications at the time, and hey, they 
> > served the purpose so far.
> 
> I've observed an entire philosophy in many people of the C language
> that seems to be 100% backward from the way things should be.  I
> don't know what the cause of that is, and I don't remember seeing
> it any place else except in some aspects of UNIX/Linux's design.
> 
> It's like this whole backward ecosystem rose out of K&R and Stallman
> and other early adopters which pushed to make it all public, and it's
> persisted that way from their initial seeds.
> 
> The idea of creating a language which operates on minimums ... it
> does make sense in the 70s, 80s, and probably even 90s, but not in
> the 00s, and certainly not in the 10s or 20s.
> 
> Those seeds need to be supplanted with new long-term seeds which do
> make real sense.
> 
> The existing C compilers and code which exist can continue to be
> compiled, and new features can be added, and changes can be made,
> without breaking anything historically.
> 
> The biggest ones I'd like to see is the removal of the requirement
> of having forward declarations.  Our computers today are fast enough
> we do not need that extra workload for the developer any longer.
> 
> Another one for C would be the introduction of the basic class.  It
> is a beautiful way to write code, though it could use some changes
> in syntax to make it more beautiful (especially for accessor methods).
> 
> Such simple augments to save man-weeks of work per developer per
> year if properly employed with inheritance and the like.
> 


I *think* Stallman was influenced by the belief of the MIT Computer Science that things like C were half assed buggy implementation of Lisp. I *think* because I vaguely remember a guy that I used to party with mentioning this the day after the police had detained us for doing stupid things in public at 3am.

[toc] | [prev] | [next] | [standalone]

#142203

On Thu, 2019-03-21, Rick C. Hodgin wrote:
...
> I've observed an entire philosophy in many people of the C language
> that seems to be 100% backward from the way things should be.  I
> don't know what the cause of that is, and I don't remember seeing
> it any place else except in some aspects of UNIX/Linux's design.

From my point of view it's you (and Bart, and a handful of other
posters) who have it backwards.  Being (it seems to me) more
interested in new language features than in writing useful programs
using the existing features.

If it's any comfort, there seem to be other communities where things
are how you think they should be: fast-moving languages like Python3,
Groovy and ... probably many others; I don't keep track.

(Last thing I heard, PHP had been reworked, and is now considered cool
again.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#142205

On Thursday, March 21, 2019 at 4:19:09 PM UTC-4, Jorgen Grahn wrote:
> On Thu, 2019-03-21, Rick C. Hodgin wrote:
> ...
> > I've observed an entire philosophy in many people of the C language
> > that seems to be 100% backward from the way things should be.  I
> > don't know what the cause of that is, and I don't remember seeing
> > it any place else except in some aspects of UNIX/Linux's design.
> 
> From my point of view it's you (and Bart, and a handful of other
> posters) who have it backwards.  Being (it seems to me) more
> interested in new language features than in writing useful programs
> using the existing features.

Speaking for myself, I like to do both, though I do use a C++ compiler
for my C-like code because I prefer some of it's constraints and relax-
ations on C syntax.

> If it's any comfort, there seem to be other communities where things
> are how you think they should be: fast-moving languages like Python3,
> Groovy and ... probably many others; I don't keep track.
> 
> (Last thing I heard, PHP had been reworked, and is now considered cool
> again.)

CAlive is so named to give C new life (among other things).

If I ever complete it, everyone will have this option.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142247

On Thursday, March 21, 2019 at 2:30:17 PM UTC-7, Rick C. Hodgin wrote:
> On Thursday, March 21, 2019 at 4:19:09 PM UTC-4, Jorgen Grahn wrote:
> > On Thu, 2019-03-21, Rick C. Hodgin wrote:
> > ...
> > > I've observed an entire philosophy in many people of the C language
> > > that seems to be 100% backward from the way things should be.  I
> > > don't know what the cause of that is, and I don't remember seeing
> > > it any place else except in some aspects of UNIX/Linux's design.
> > 
> > From my point of view it's you (and Bart, and a handful of other
> > posters) who have it backwards.  Being (it seems to me) more
> > interested in new language features than in writing useful programs
> > using the existing features.
> 
> Speaking for myself, I like to do both, though I do use a C++ compiler
> for my C-like code because I prefer some of it's constraints and relax-
> ations on C syntax.
> 
> > If it's any comfort, there seem to be other communities where things
> > are how you think they should be: fast-moving languages like Python3,
> > Groovy and ... probably many others; I don't keep track.
> > 
> > (Last thing I heard, PHP had been reworked, and is now considered cool
> > again.)
> 
> CAlive is so named to give C new life (among other things).
> 
> If I ever complete it, everyone will have this option.

Do you have the tokenizer completed? If so, do you have the production rules for the language grammar written down? Because if you can't do that, well CAlive is going to be like Fir attempting to become a programmer for a living. Ie, it will never happen.

[toc] | [prev] | [next] | [standalone]

#142266

On Friday, March 22, 2019 at 1:16:08 PM UTC-4, Chad wrote:
> On Thursday, March 21, 2019 at 2:30:17 PM UTC-7, Rick C. Hodgin wrote:
> > CAlive is so named to give C new life (among other things).
> > If I ever complete it, everyone will have this option.
> 
> Do you have the tokenizer completed?

I don't do drugs.  I'm strait-lace, sir.

> If so, do you have the production rules for the language
> grammar written down?

I hated grammar in school.  My worst subject.  I did like the
predicate nominative though.  A stand out there in a sea of
otherwise doldrum.  Conjunctions weren't bad either, but mostly
because I liked the song.  "Con-junc-tion junc-tion.  What's
your function?  Pickin' up nouns and phrases and clauses."  Oh
some happy boyhood memories.

> Because if you can't do that, well CAlive .. it will never happen.

You mean ... wait ... I have to know grammar to complete CAlive?
Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaargh!
Noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!
Khaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaan!

-----
Chad,

It's a Christian project.  I assume your constant inquiries are
the result of some deep-seated desires to come on board and help
complete this noble project?

You're welcome to come on board and help out.  Do you have a
statement of faith on record that Jesus Christ is your Lord and
Savior, and that you seek to write software to bring honor and
glory to Him, and to serve mankind in that way?  Or ... is your
comparing me to fir the antithetical non-statement of faith?

I await your reply with both bated breath and baited breath (as
I've recently eaten a Tuna sandwich on flatbread from my local
Subway -- yum yum).

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web