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

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

An enhancement

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

Contents

  An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-08 15:44 -0700
    Re: An enhancement Ian Collins <ian-news@hotmail.com> - 2018-10-09 11:48 +1300
      Re: An enhancement Spiros Bousbouras <spibou@gmail.com> - 2018-10-08 23:16 +0000
    Re: An enhancement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 00:30 +0100
      Re: An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-08 17:24 -0700
        Re: An enhancement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 02:12 +0100
          Re: An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-08 22:42 -0700
            Re: An enhancement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 14:41 +0100
          Re: An enhancement David Brown <david.brown@hesbynett.no> - 2018-10-09 11:15 +0200
            Re: An enhancement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 16:09 +0100
              GCC nested functions: deprecated? (Was: An enhancement) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 15:36 +0000
              Re: An enhancement David Brown <david.brown@hesbynett.no> - 2018-10-09 21:01 +0200
          Re: An enhancement Bart <bc@freeuk.com> - 2018-10-09 11:43 +0100
            Re: An enhancement already5chosen@yahoo.com - 2018-10-09 04:08 -0700
              Re: An enhancement Bart <bc@freeuk.com> - 2018-10-09 12:29 +0100
    Re: An enhancement Spiros Bousbouras <spibou@gmail.com> - 2018-10-08 23:37 +0000
      Re: An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-08 17:22 -0700
        Re: An enhancement Ian Collins <ian-news@hotmail.com> - 2018-10-09 13:30 +1300
        Re: An enhancement Spiros Bousbouras <spibou@gmail.com> - 2018-10-09 05:23 +0000
          Re: An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-08 22:50 -0700
          Re: An enhancement Richard Damon <Richard@Damon-Family.org> - 2018-10-09 08:28 -0400
        Re: An enhancement Wouter Verhelst <w@uter.be> - 2018-10-09 14:05 +0200
          C is often used as an "implementation language" for other languages.  (Was: An enhancement) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 13:13 +0000
            Re: C is often used as an "implementation language" for other languages.  (Was: An enhancement) David Brown <david.brown@hesbynett.no> - 2018-10-09 16:51 +0200
          Re: An enhancement Bart <bc@freeuk.com> - 2018-10-09 14:17 +0100
        Re: An enhancement Thiago Adams <thiago.adams@gmail.com> - 2018-10-09 05:20 -0700
          Re: An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-09 11:33 -0700
            Re: An enhancement Thiago Adams <thiago.adams@gmail.com> - 2018-10-09 13:41 -0700
      Re: An enhancement Bart <bc@freeuk.com> - 2018-10-09 12:35 +0100
    Re: An enhancement Wouter Verhelst <w@uter.be> - 2018-10-09 14:04 +0200
      Re: An enhancement Spiros Bousbouras <spibou@gmail.com> - 2018-10-09 12:29 +0000
        Re: An enhancement Wouter Verhelst <w@uter.be> - 2018-10-09 19:50 +0200
        Re: An enhancement queequeg@trust.no1 (Queequeg) - 2018-10-15 09:19 +0000
          Re: An enhancement already5chosen@yahoo.com - 2018-10-15 03:07 -0700
            Re: An enhancement Ian Collins <ian-news@hotmail.com> - 2018-10-15 23:18 +1300
              Re: An enhancement already5chosen@yahoo.com - 2018-10-15 03:39 -0700
                Re: An enhancement David Brown <david.brown@hesbynett.no> - 2018-10-15 13:03 +0200
                  Re: An enhancement Bart <bc@freeuk.com> - 2018-10-15 12:15 +0100
                    Re: An enhancement Thiago Adams <thiago.adams@gmail.com> - 2018-10-15 05:20 -0700
                      Re: An enhancement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-15 15:39 +0100
                    Re: An enhancement David Brown <david.brown@hesbynett.no> - 2018-10-15 14:36 +0200
                      Re: An enhancement Thiago Adams <thiago.adams@gmail.com> - 2018-10-15 05:59 -0700
                        Re: An enhancement David Brown <david.brown@hesbynett.no> - 2018-10-15 15:08 +0200
                          Re: An enhancement Thiago Adams <thiago.adams@gmail.com> - 2018-10-15 07:25 -0700
                      Re: An enhancement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-15 15:44 +0100
                        Re: An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-15 19:02 -0700
                          Re: An enhancement Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-16 05:55 +0000
                          Re: An enhancement jameskuyper@alumni.caltech.edu - 2018-10-16 05:37 -0700
                            Re: An enhancement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-16 15:11 +0100
                              Re: An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-16 13:33 -0700
                                Re: An enhancement David Kleinecke <dkleinecke@gmail.com> - 2018-10-16 21:27 -0700
                          Re: An enhancement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-16 14:57 +0100
                            Re: An enhancement scott@slp53.sl.home (Scott Lurndal) - 2018-10-16 14:24 +0000
                              Re: An enhancement mark.bluemel@gmail.com - 2018-10-16 07:28 -0700
                            Re: An enhancement Bart <bc@freeuk.com> - 2018-10-16 15:25 +0100
              Re: An enhancement Bart <bc@freeuk.com> - 2018-10-15 11:44 +0100
                Re: An enhancement David Brown <david.brown@hesbynett.no> - 2018-10-15 13:08 +0200
            Re: An enhancement Bart <bc@freeuk.com> - 2018-10-15 11:22 +0100
              Re: An enhancement David Brown <david.brown@hesbynett.no> - 2018-10-15 13:01 +0200
                Re: An enhancement Nick Bowler <nbowler@draconx.ca> - 2018-10-15 14:43 +0000

Page 1 of 3  [1] 2 3  Next page →

#136445 — An enhancement

I want to propose an enhancement:

Add to C the statement type
    DO identifier SEMICOLON
where the identifier is a label. The meaning is that
the statement just identified is replaced by the
statement following the label.

This enhancement is potentially ambiguous in
    DO identifier SEMICOLON WHILE ... SEMICOLON
and this situation has come up in another thread
and triggered my post here. In order to preserve
conforming it is necessary that the ambiguity be
resolved as a DO-WHILE leaving 
    identifier SEMICOLON 
as the repeated code. But the whole reduces to
    WHILE .... SEMICOLON

The purpose of this enhancement is to enable
top-down coding in the sense Knuth wanted with
his literate programming. You can write code
like:
    int foo (int x) {
        if (x < 0) do trivial_case;
        else if (x == 0) do easy_case;
        else do usual_case;
        return;
     trivial_case: { 
        .... }
     easy_case: { 
        .... }
     usual_case: { 
        .... }}
which is generally easier to understand if you have
given as labels good descriptive phrases.

[toc] | [next] | [standalone]

#136446

On 09/10/18 11:44, David Kleinecke wrote:
> I want to propose an enhancement:
> 
> Add to C the statement type
>      DO identifier SEMICOLON
> where the identifier is a label. The meaning is that
> the statement just identified is replaced by the
> statement following the label.
> 
> This enhancement is potentially ambiguous in
>      DO identifier SEMICOLON WHILE ... SEMICOLON
> and this situation has come up in another thread
> and triggered my post here. In order to preserve
> conforming it is necessary that the ambiguity be
> resolved as a DO-WHILE leaving
>      identifier SEMICOLON
> as the repeated code. But the whole reduces to
>      WHILE .... SEMICOLON
> 
> The purpose of this enhancement is to enable
> top-down coding in the sense Knuth wanted with
> his literate programming. You can write code
> like:
>      int foo (int x) {
>          if (x < 0) do trivial_case;
>          else if (x == 0) do easy_case;
>          else do usual_case;
>          return;
>       trivial_case: {
>          .... }
>       easy_case: {
>          .... }
>       usual_case: {
>          .... }}
> which is generally easier to understand if you have
> given as labels good descriptive phrases.

What's wrong with calling functions with good descriptive names?

-- 
Ian.

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

#136447

On Tue, 9 Oct 2018 11:48:34 +1300
Ian Collins <ian-news@hotmail.com> wrote:
> On 09/10/18 11:44, David Kleinecke wrote:
> > I want to propose an enhancement:
> > 
> > Add to C the statement type
> >      DO identifier SEMICOLON
> > where the identifier is a label. The meaning is that
> > the statement just identified is replaced by the
> > statement following the label.
> > 
> > This enhancement is potentially ambiguous in
> >      DO identifier SEMICOLON WHILE ... SEMICOLON
> > and this situation has come up in another thread
> > and triggered my post here. In order to preserve
> > conforming it is necessary that the ambiguity be
> > resolved as a DO-WHILE leaving
> >      identifier SEMICOLON
> > as the repeated code. But the whole reduces to
> >      WHILE .... SEMICOLON
> > 
> > The purpose of this enhancement is to enable
> > top-down coding in the sense Knuth wanted with
> > his literate programming. You can write code
> > like:
> >      int foo (int x) {
> >          if (x < 0) do trivial_case;
> >          else if (x == 0) do easy_case;
> >          else do usual_case;
> >          return;
> >       trivial_case: {
> >          .... }
> >       easy_case: {
> >          .... }
> >       usual_case: {
> >          .... }}
> > which is generally easier to understand if you have
> > given as labels good descriptive phrases.
> 
> What's wrong with calling functions with good descriptive names?

That was my thought too. Local functions which inherit the variables
of the parent function seem to me more useful.

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

#136448

David Kleinecke <dkleinecke@gmail.com> writes:

> I want to propose an enhancement:
>
> Add to C the statement type
>     DO identifier SEMICOLON
> where the identifier is a label. The meaning is that
> the statement just identified is replaced by the
> statement following the label.
>
> This enhancement is potentially ambiguous in
>     DO identifier SEMICOLON WHILE ... SEMICOLON
> and this situation has come up in another thread
> and triggered my post here. In order to preserve
> conforming it is necessary that the ambiguity be
> resolved as a DO-WHILE leaving 
>     identifier SEMICOLON 
> as the repeated code. But the whole reduces to
>     WHILE .... SEMICOLON

Rather then use an ambiguous syntax, why not write it as

  label();

The you could even add arguments and parameters and, hey presto, you get
what Knuth (and others) would have wanted from the get-go.

<snip>
-- 
Ben.

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

#136453

On Monday, October 8, 2018 at 4:30:40 PM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
> > I want to propose an enhancement:
> >
> > Add to C the statement type
> >     DO identifier SEMICOLON
> > where the identifier is a label. The meaning is that
> > the statement just identified is replaced by the
> > statement following the label.
> >
> > This enhancement is potentially ambiguous in
> >     DO identifier SEMICOLON WHILE ... SEMICOLON
> > and this situation has come up in another thread
> > and triggered my post here. In order to preserve
> > conforming it is necessary that the ambiguity be
> > resolved as a DO-WHILE leaving 
> >     identifier SEMICOLON 
> > as the repeated code. But the whole reduces to
> >     WHILE .... SEMICOLON
> 
> Rather then use an ambiguous syntax, why not write it as
> 
>   label();
> 
> The you could even add arguments and parameters and, hey presto, you get
> what Knuth (and others) would have wanted from the get-go.
 
I don't follow - a label without following colon is not in
the spirit of C. What do you mean?

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

#136455

David Kleinecke <dkleinecke@gmail.com> writes:

> On Monday, October 8, 2018 at 4:30:40 PM UTC-7, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> 
>> > I want to propose an enhancement:
>> >
>> > Add to C the statement type
>> >     DO identifier SEMICOLON
>> > where the identifier is a label. The meaning is that
>> > the statement just identified is replaced by the
>> > statement following the label.
>> >
>> > This enhancement is potentially ambiguous in
>> >     DO identifier SEMICOLON WHILE ... SEMICOLON
>> > and this situation has come up in another thread
>> > and triggered my post here. In order to preserve
>> > conforming it is necessary that the ambiguity be
>> > resolved as a DO-WHILE leaving 
>> >     identifier SEMICOLON 
>> > as the repeated code. But the whole reduces to
>> >     WHILE .... SEMICOLON
>> 
>> Rather then use an ambiguous syntax, why not write it as
>> 
>>   label();
>> 
>> The you could even add arguments and parameters and, hey presto, you get
>> what Knuth (a-invend others) would have wanted from the get-go.
>  
> I don't follow - a label without following colon is not in
> the spirit of C. What do you mean?

I mean don't write

  do something;

but write

  something();

since it is, in effect, a function call.  Then go all the way and rather
than writing

  something:
       /* code for 'something' ... */

write

  void something()
  {
       /* code for 'something' ... */
  }
  
You are re-inventing local functions.  Just go the whole hog and allow
local functions, because the function abstraction is familiar and yet
more flexible.


-- 
Ben.

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

#136458

On Monday, October 8, 2018 at 6:12:20 PM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
> > On Monday, October 8, 2018 at 4:30:40 PM UTC-7, Ben Bacarisse wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> 
> >> > I want to propose an enhancement:
> >> >
> >> > Add to C the statement type
> >> >     DO identifier SEMICOLON
> >> > where the identifier is a label. The meaning is that
> >> > the statement just identified is replaced by the
> >> > statement following the label.
> >> >
> >> > This enhancement is potentially ambiguous in
> >> >     DO identifier SEMICOLON WHILE ... SEMICOLON
> >> > and this situation has come up in another thread
> >> > and triggered my post here. In order to preserve
> >> > conforming it is necessary that the ambiguity be
> >> > resolved as a DO-WHILE leaving 
> >> >     identifier SEMICOLON 
> >> > as the repeated code. But the whole reduces to
> >> >     WHILE .... SEMICOLON
> >> 
> >> Rather then use an ambiguous syntax, why not write it as
> >> 
> >>   label();
> >> 
> >> The you could even add arguments and parameters and, hey presto, you get
> >> what Knuth (a-invend others) would have wanted from the get-go.
> >  
> > I don't follow - a label without following colon is not in
> > the spirit of C. What do you mean?
> 
> I mean don't write
> 
>   do something;
> 
> but write
> 
>   something();
> 
> since it is, in effect, a function call.  Then go all the way and rather
> than writing
> 
>   something:
>        /* code for 'something' ... */
> 
> write
> 
>   void something()
>   {
>        /* code for 'something' ... */
>   }
>   
> You are re-inventing local functions.  Just go the whole hog and allow
> local functions, because the function abstraction is familiar and yet
> more flexible.

Essentially you are correct and that is a solution I was
trying to avoid. I think local functions are probably too
powerful. I see bugs when I look at the possibility of
parameters and returns not features. 

And of course I do not want to have to declare these 
sub-functions before I use them. By reducing them to
the equivalent of void-void functions I can avoid
early declaration. 

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

#136481

David Kleinecke <dkleinecke@gmail.com> writes:

> On Monday, October 8, 2018 at 6:12:20 PM UTC-7, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> 
>> > On Monday, October 8, 2018 at 4:30:40 PM UTC-7, Ben Bacarisse wrote:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> >> 
>> >> > I want to propose an enhancement:
>> >> >
>> >> > Add to C the statement type
>> >> >     DO identifier SEMICOLON
>> >> > where the identifier is a label. The meaning is that
>> >> > the statement just identified is replaced by the
>> >> > statement following the label.
>> >> >
>> >> > This enhancement is potentially ambiguous in
>> >> >     DO identifier SEMICOLON WHILE ... SEMICOLON
>> >> > and this situation has come up in another thread
>> >> > and triggered my post here. In order to preserve
>> >> > conforming it is necessary that the ambiguity be
>> >> > resolved as a DO-WHILE leaving 
>> >> >     identifier SEMICOLON 
>> >> > as the repeated code. But the whole reduces to
>> >> >     WHILE .... SEMICOLON
>> >> 
>> >> Rather then use an ambiguous syntax, why not write it as
>> >> 
>> >>   label();
>> >> 
>> >> The you could even add arguments and parameters and, hey presto, you get
>> >> what Knuth (a-invend others) would have wanted from the get-go.
>> >  
>> > I don't follow - a label without following colon is not in
>> > the spirit of C. What do you mean?
>> 
>> I mean don't write
>> 
>>   do something;
>> 
>> but write
>> 
>>   something();
>> 
>> since it is, in effect, a function call.  Then go all the way and rather
>> than writing
>> 
>>   something:
>>        /* code for 'something' ... */
>> 
>> write
>> 
>>   void something()
>>   {
>>        /* code for 'something' ... */
>>   }
>>   
>> You are re-inventing local functions.  Just go the whole hog and allow
>> local functions, because the function abstraction is familiar and yet
>> more flexible.
>
> Essentially you are correct and that is a solution I was
> trying to avoid. I think local functions are probably too
> powerful. I see bugs when I look at the possibility of
> parameters and returns not features.

They have issues for sure, but then so does any such proposal.  If you
want to limit them so that parameters and return value are banner, you
can do that.  You will still benefit from the fact that you are not
introducing a whole new structure with an ambiguous syntax.

-- 
Ben.

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

#136462

On 09/10/18 03:12, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
<snip>
> You are re-inventing local functions.  Just go the whole hog and allow
> local functions, because the function abstraction is familiar and yet
> more flexible.
> 

They also have the advantage of existing already - as a gcc extension
for C, and as lambdas in C++.

The only thing missing here is the "use before declaration" issue.

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

#136485

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

> On 09/10/18 03:12, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> 
> <snip>
>> You are re-inventing local functions.  Just go the whole hog and allow
>> local functions, because the function abstraction is familiar and yet
>> more flexible.
>
> They also have the advantage of existing already - as a gcc extension
> for C, and as lambdas in C++.

For some reason I had the idea in the back of my mind that gcc had either
removed this extension or was planning to discontinue support or some
such.  It's likely I'm making that up...

-- 
Ben.

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

#136487 — GCC nested functions: deprecated? (Was: An enhancement)

In article <87d0sjupfh.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
...
>For some reason I had the idea in the back of my mind that gcc had either
>removed this extension or was planning to discontinue support or some
>such.  It's likely I'm making that up...

I don't think you are.  I have vague memories of reading the same thing,
but I couldn't find anything on it ATM.

I think it is not supported on all platforms, so, in the spirit of the
dogma of this particular newsgroup, I think there is a move afoot to
disable it on all platforms.  A theme frequently seen on this NG, where
everybody must suffer because of the limitations of the DS9000.

Also, it is believed by some that it is a "security" risk.

And, finally, it is believed by some that it is "not necessary" and that
you can use "statement expressions" to do  whatever it is that you wanted
to do with nested functions.

If they do deprecate and/or (eventually) remove it, I wonder how they will
support languages like Ada and Pascal...

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Security

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

#136499

On 09/10/18 17:09, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 09/10/18 03:12, Ben Bacarisse wrote:
>>> David Kleinecke <dkleinecke@gmail.com> writes:
>>>
>> <snip>
>>> You are re-inventing local functions.  Just go the whole hog and allow
>>> local functions, because the function abstraction is familiar and yet
>>> more flexible.
>>
>> They also have the advantage of existing already - as a gcc extension
>> for C, and as lambdas in C++.
> 
> For some reason I had the idea in the back of my mind that gcc had either
> removed this extension or was planning to discontinue support or some
> such.  It's likely I'm making that up...
> 


Nested functions themselves are not a problem.  The trouble comes when 
you take their address and pass that out.  To make that work, gcc uses 
trampolines (on most platforms, anyway) - small code sections generated 
at run-time on the stack.  Clearly this is not going to work with 
non-executable stacks, and is going to give security-paranoid people 
nightmares.

And while nested functions are not deprecated AFAIK (and no mention is 
given in the gcc manual), it is probably better to use C++ and lambdas 
than gcc C with nested functions.

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

#136466

On 09/10/2018 02:12, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
>> On Monday, October 8, 2018 at 4:30:40 PM UTC-7, Ben Bacarisse wrote:
>>> David Kleinecke <dkleinecke@gmail.com> writes:
>>>
>>>> I want to propose an enhancement:
>>>>
>>>> Add to C the statement type
>>>>      DO identifier SEMICOLON
>>>> where the identifier is a label. The meaning is that
>>>> the statement just identified is replaced by the
>>>> statement following the label.
>>>>
>>>> This enhancement is potentially ambiguous in
>>>>      DO identifier SEMICOLON WHILE ... SEMICOLON
>>>> and this situation has come up in another thread
>>>> and triggered my post here. In order to preserve
>>>> conforming it is necessary that the ambiguity be
>>>> resolved as a DO-WHILE leaving
>>>>      identifier SEMICOLON
>>>> as the repeated code. But the whole reduces to
>>>>      WHILE .... SEMICOLON
>>>
>>> Rather then use an ambiguous syntax, why not write it as
>>>
>>>    label();
>>>
>>> The you could even add arguments and parameters and, hey presto, you get
>>> what Knuth (a-invend others) would have wanted from the get-go.
>>   
>> I don't follow - a label without following colon is not in
>> the spirit of C. What do you mean?
> 
> I mean don't write
> 
>    do something;
> 
> but write
> 
>    something();
> 
> since it is, in effect, a function call.  Then go all the way and rather
> than writing
> 
>    something:
>         /* code for 'something' ... */
> 
> write
> 
>    void something()
>    {
>         /* code for 'something' ... */
>    }
>    
> You are re-inventing local functions.  Just go the whole hog and allow
> local functions, because the function abstraction is familiar and yet
> more flexible.

The OP is proposing a lightweight, easier-to-implement feature compared 
to local functions.

Local functions are a can of worms (mainly to do with accessing the 
local variables of the enclosing functions).

(This proposal has similarities to a feature of Rick's from a few years 
ago, a form of which I'd implemented for a while. But then got rid of 
it, because (1) it looked a bit naff (I used '@' rather than 'do'); (2) 
I hardly ever used it; (3) it was difficult to express for a C target.

This assumes you can write 'do something' from more than one place, and 
that each named block will never be reentrant.)

-- 
bart

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

#136467

On Tuesday, October 9, 2018 at 1:43:31 PM UTC+3, Bart wrote:
> On 09/10/2018 02:12, Ben Bacarisse wrote:
> > David Kleinecke <dkleinecke@gmail.com> writes:
> > 
> >> On Monday, October 8, 2018 at 4:30:40 PM UTC-7, Ben Bacarisse wrote:
> >>> David Kleinecke <dkleinecke@gmail.com> writes:
> >>>
> >>>> I want to propose an enhancement:
> >>>>
> >>>> Add to C the statement type
> >>>>      DO identifier SEMICOLON
> >>>> where the identifier is a label. The meaning is that
> >>>> the statement just identified is replaced by the
> >>>> statement following the label.
> >>>>
> >>>> This enhancement is potentially ambiguous in
> >>>>      DO identifier SEMICOLON WHILE ... SEMICOLON
> >>>> and this situation has come up in another thread
> >>>> and triggered my post here. In order to preserve
> >>>> conforming it is necessary that the ambiguity be
> >>>> resolved as a DO-WHILE leaving
> >>>>      identifier SEMICOLON
> >>>> as the repeated code. But the whole reduces to
> >>>>      WHILE .... SEMICOLON
> >>>
> >>> Rather then use an ambiguous syntax, why not write it as
> >>>
> >>>    label();
> >>>
> >>> The you could even add arguments and parameters and, hey presto, you get
> >>> what Knuth (a-invend others) would have wanted from the get-go.
> >>   
> >> I don't follow - a label without following colon is not in
> >> the spirit of C. What do you mean?
> > 
> > I mean don't write
> > 
> >    do something;
> > 
> > but write
> > 
> >    something();
> > 
> > since it is, in effect, a function call.  Then go all the way and rather
> > than writing
> > 
> >    something:
> >         /* code for 'something' ... */
> > 
> > write
> > 
> >    void something()
> >    {
> >         /* code for 'something' ... */
> >    }
> >    
> > You are re-inventing local functions.  Just go the whole hog and allow
> > local functions, because the function abstraction is familiar and yet
> > more flexible.
> 
> The OP is proposing a lightweight, easier-to-implement feature compared 
> to local functions.
> 
> Local functions are a can of worms (mainly to do with accessing the 
> local variables of the enclosing functions).


I don't see how what David proposes is not *exactly* the same can of worms.

I once was forced to read and understand largish code base (in Ada) written with a lot of local functions where programmers didn't think twice before accessing/modifying variables from the outer scope. It was painful. Since then I very much appreciate an absence of local functions in C.

> 
> (This proposal has similarities to a feature of Rick's from a few years 
> ago, a form of which I'd implemented for a while. But then got rid of 
> it, because (1) it looked a bit naff (I used '@' rather than 'do'); (2) 
> I hardly ever used it; (3) it was difficult to express for a C target.
> 
> This assumes you can write 'do something' from more than one place, and 
> that each named block will never be reentrant.)
> 
> -- 
> bart

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

#136468

On 09/10/2018 12:08, already5chosen@yahoo.com wrote:
> On Tuesday, October 9, 2018 at 1:43:31 PM UTC+3, Bart wrote:
>> On 09/10/2018 02:12, Ben Bacarisse wrote:
>>> David Kleinecke <dkleinecke@gmail.com> writes:
>>>
>>>> On Monday, October 8, 2018 at 4:30:40 PM UTC-7, Ben Bacarisse wrote:
>>>>> David Kleinecke <dkleinecke@gmail.com> writes:
>>>>>
>>>>>> I want to propose an enhancement:
>>>>>>
>>>>>> Add to C the statement type
>>>>>>       DO identifier SEMICOLON
>>>>>> where the identifier is a label. The meaning is that
>>>>>> the statement just identified is replaced by the
>>>>>> statement following the label.
>>>>>>
>>>>>> This enhancement is potentially ambiguous in
>>>>>>       DO identifier SEMICOLON WHILE ... SEMICOLON
>>>>>> and this situation has come up in another thread
>>>>>> and triggered my post here. In order to preserve
>>>>>> conforming it is necessary that the ambiguity be
>>>>>> resolved as a DO-WHILE leaving
>>>>>>       identifier SEMICOLON
>>>>>> as the repeated code. But the whole reduces to
>>>>>>       WHILE .... SEMICOLON
>>>>>
>>>>> Rather then use an ambiguous syntax, why not write it as
>>>>>
>>>>>     label();
>>>>>
>>>>> The you could even add arguments and parameters and, hey presto, you get
>>>>> what Knuth (a-invend others) would have wanted from the get-go.
>>>>    
>>>> I don't follow - a label without following colon is not in
>>>> the spirit of C. What do you mean?
>>>
>>> I mean don't write
>>>
>>>     do something;
>>>
>>> but write
>>>
>>>     something();
>>>
>>> since it is, in effect, a function call.  Then go all the way and rather
>>> than writing
>>>
>>>     something:
>>>          /* code for 'something' ... */
>>>
>>> write
>>>
>>>     void something()
>>>     {
>>>          /* code for 'something' ... */
>>>     }
>>>     
>>> You are re-inventing local functions.  Just go the whole hog and allow
>>> local functions, because the function abstraction is familiar and yet
>>> more flexible.
>>
>> The OP is proposing a lightweight, easier-to-implement feature compared
>> to local functions.
>>
>> Local functions are a can of worms (mainly to do with accessing the
>> local variables of the enclosing functions).
> 
> 
> I don't see how what David proposes is not *exactly* the same can of worms.
> 
> I once was forced to read and understand largish code base (in Ada) written with a lot of local functions where programmers didn't think twice before accessing/modifying variables from the outer scope. It was painful. Since then I very much appreciate an absence of local functions in C.

If there is an outer function A(), containing inner function B(), which 
contains inner function C(), then the can of worms refers to C() being 
able to a access local variables in A() and B(), given that A, B and C 
could have been called recursively multiple times so that each has a 
number of active stack frames, of which the most recent of are at 
non-contiguous locations.

This won't happen with the proposal, where there is only the one stack 
frame of the one function.

There might still be problems caused by C's block scopes, but only 
things like this:

     float a, b;
     { int a, b;
       do something;
     }
     {
       something: a+=b;
     }

where the block at 'something' won't see the same a,b names visible at 
the 'caller'. But this is the problem as this:

     float a, b;
     { int a, b;
       goto something;
       L1:
     }
     {
       something: a+=b;
       goto L1;
     }

which is not something that is perceived as a problem; just bad code.

-- 
bart

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

#136449

On Mon, 8 Oct 2018 15:44:14 -0700 (PDT)
David Kleinecke <dkleinecke@gmail.com> wrote:
> I want to propose an enhancement:
> 
> Add to C the statement type
>     DO identifier SEMICOLON
> where the identifier is a label. The meaning is that
> the statement just identified is replaced by the
> statement following the label.

[...]

> The purpose of this enhancement is to enable
> top-down coding in the sense Knuth wanted with
> his literate programming. You can write code
> like:
>     int foo (int x) {
>         if (x < 0) do trivial_case;
>         else if (x == 0) do easy_case;
>         else do usual_case;
>         return;
>      trivial_case: { 
>         .... }
>      easy_case: { 
>         .... }
>      usual_case: { 
>         .... }}
> which is generally easier to understand if you have
> given as labels good descriptive phrases.

You could achieve the same with macros :

int foo (int x) {
#define  trivial_case {  \
    ....                 \
}
#define  easy_case {     \
    ....                 \
}
#define  usual_case {    \
    ....                 \
}
    if (x < 0) trivial_case
    else if (x == 0) easy_case
    else usual_case
    return 13 ;
}

Your code looks cleaner but I'm not sure the difference is worth adding
the new syntax.

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

#136452

On Monday, October 8, 2018 at 4:38:02 PM UTC-7, Spiros Bousbouras wrote:
> On Mon, 8 Oct 2018 15:44:14 -0700 (PDT)
> David Kleinecke <dkleinecke@gmail.com> wrote:
> > I want to propose an enhancement:
> > 
> > Add to C the statement type
> >     DO identifier SEMICOLON
> > where the identifier is a label. The meaning is that
> > the statement just identified is replaced by the
> > statement following the label.
> 
> [...]
> 
> > The purpose of this enhancement is to enable
> > top-down coding in the sense Knuth wanted with
> > his literate programming. You can write code
> > like:
> >     int foo (int x) {
> >         if (x < 0) do trivial_case;
> >         else if (x == 0) do easy_case;
> >         else do usual_case;
> >         return;
> >      trivial_case: { 
> >         .... }
> >      easy_case: { 
> >         .... }
> >      usual_case: { 
> >         .... }}
> > which is generally easier to understand if you have
> > given as labels good descriptive phrases.
> 
> You could achieve the same with macros :
> 
> int foo (int x) {
> #define  trivial_case {  \
>     ....                 \
> }
> #define  easy_case {     \
>     ....                 \
> }
> #define  usual_case {    \
>     ....                 \
> }
>     if (x < 0) trivial_case
>     else if (x == 0) easy_case
>     else usual_case
>     return 13 ;
> }
> 
> Your code looks cleaner but I'm not sure the difference is worth adding
> the new syntax.

Since I am writing a compiler an enhancement is easy. 

The problem with macros is that they must be defined before
they are used. That also applies to functions. IMO top-down
more less dictates that the top level be presented to the
reader first. 

Many other ideas are possible but I want to make as few
changes as possible to C (which I still think of as C90).
Enhancements have always been envisioned. 

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

#136454

On 09/10/18 13:22, David Kleinecke wrote:
> On Monday, October 8, 2018 at 4:38:02 PM UTC-7, Spiros Bousbouras wrote:
>> On Mon, 8 Oct 2018 15:44:14 -0700 (PDT)
>> David Kleinecke <dkleinecke@gmail.com> wrote:
>>> I want to propose an enhancement:
>>>
>>> Add to C the statement type
>>>      DO identifier SEMICOLON
>>> where the identifier is a label. The meaning is that
>>> the statement just identified is replaced by the
>>> statement following the label.
>>
>> [...]
>>
>>> The purpose of this enhancement is to enable
>>> top-down coding in the sense Knuth wanted with
>>> his literate programming. You can write code
>>> like:
>>>      int foo (int x) {
>>>          if (x < 0) do trivial_case;
>>>          else if (x == 0) do easy_case;
>>>          else do usual_case;
>>>          return;
>>>       trivial_case: {
>>>          .... }
>>>       easy_case: {
>>>          .... }
>>>       usual_case: {
>>>          .... }}
>>> which is generally easier to understand if you have
>>> given as labels good descriptive phrases.
>>
>> You could achieve the same with macros :
>>
>> int foo (int x) {
>> #define  trivial_case {  \
>>      ....                 \
>> }
>> #define  easy_case {     \
>>      ....                 \
>> }
>> #define  usual_case {    \
>>      ....                 \
>> }
>>      if (x < 0) trivial_case
>>      else if (x == 0) easy_case
>>      else usual_case
>>      return 13 ;
>> }
>>
>> Your code looks cleaner but I'm not sure the difference is worth adding
>> the new syntax.
> 
> Since I am writing a compiler an enhancement is easy.
> 
> The problem with macros is that they must be defined before
> they are used. That also applies to functions. IMO top-down
> more less dictates that the top level be presented to the
> reader first.

So you declare the functions in a header.

Your suggestion would make functions longer, which is usually a bad 
idea.  If you have a discrete task, put it in a function.

> Many other ideas are possible but I want to make as few
> changes as possible to C (which I still think of as C90).
> Enhancements have always been envisioned.

You don't need to make any if you stick with good modularisation.

-- 
Ian

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

#136457

On Mon, 8 Oct 2018 17:22:51 -0700 (PDT)
David Kleinecke <dkleinecke@gmail.com> wrote:
> On Monday, October 8, 2018 at 4:38:02 PM UTC-7, Spiros Bousbouras wrote:
> > On Mon, 8 Oct 2018 15:44:14 -0700 (PDT)
> > David Kleinecke <dkleinecke@gmail.com> wrote:
> > > I want to propose an enhancement:
> > > 
> > > Add to C the statement type
> > >     DO identifier SEMICOLON
> > > where the identifier is a label. The meaning is that
> > > the statement just identified is replaced by the
> > > statement following the label.
> > 
> > [...]
> > 
> > > The purpose of this enhancement is to enable
> > > top-down coding in the sense Knuth wanted with
> > > his literate programming. You can write code
> > > like:
> > >     int foo (int x) {
> > >         if (x < 0) do trivial_case;
> > >         else if (x == 0) do easy_case;
> > >         else do usual_case;
> > >         return;
> > >      trivial_case: { 
> > >         .... }
> > >      easy_case: { 
> > >         .... }
> > >      usual_case: { 
> > >         .... }}
> > > which is generally easier to understand if you have
> > > given as labels good descriptive phrases.
> > 
> > You could achieve the same with macros :
> > 
> > int foo (int x) {
> > #define  trivial_case {  \
> >     ....                 \
> > }
> > #define  easy_case {     \
> >     ....                 \
> > }
> > #define  usual_case {    \
> >     ....                 \
> > }
> >     if (x < 0) trivial_case
> >     else if (x == 0) easy_case
> >     else usual_case
> >     return 13 ;
> > }
> > 
> > Your code looks cleaner but I'm not sure the difference is worth adding
> > the new syntax.
> 
> Since I am writing a compiler an enhancement is easy. 
> 
> The problem with macros is that they must be defined before
> they are used. That also applies to functions.

With local functions you could make the compiler so that it scans the whole
body of the top level function to see if it has local functions. Then , in a
2nd pass , when it encounters a function call with a name coinciding with one
of the local functions , it assumes this is what was intended otherwise it
treats it in the same way it would a global function. I'm guessing that even
with your enhancement it would need 2 passes.

> IMO top-down
> more less dictates that the top level be presented to the
> reader first. 

My impression is that the distinction top-down vs bottom-up is more related
to how one designs and writes the code. Regardless of how the code was
written , one can read it in any order one wishes. And there are tools which
analyse C code and give you the tree of function calls so one can get a sense
where each function lies in the hierarchy.

-- 
Good taste is the hobgoblin of little minds.

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

#136459

On Monday, October 8, 2018 at 10:23:59 PM UTC-7, Spiros Bousbouras wrote:
> On Mon, 8 Oct 2018 17:22:51 -0700 (PDT)
> David Kleinecke <dkleinecke@gmail.com> wrote:
> > On Monday, October 8, 2018 at 4:38:02 PM UTC-7, Spiros Bousbouras wrote:
> > > On Mon, 8 Oct 2018 15:44:14 -0700 (PDT)
> > > David Kleinecke <dkleinecke@gmail.com> wrote:
> > > > I want to propose an enhancement:
> > > > 
> > > > Add to C the statement type
> > > >     DO identifier SEMICOLON
> > > > where the identifier is a label. The meaning is that
> > > > the statement just identified is replaced by the
> > > > statement following the label.
> > > 
> > > [...]
> > > 
> > > > The purpose of this enhancement is to enable
> > > > top-down coding in the sense Knuth wanted with
> > > > his literate programming. You can write code
> > > > like:
> > > >     int foo (int x) {
> > > >         if (x < 0) do trivial_case;
> > > >         else if (x == 0) do easy_case;
> > > >         else do usual_case;
> > > >         return;
> > > >      trivial_case: { 
> > > >         .... }
> > > >      easy_case: { 
> > > >         .... }
> > > >      usual_case: { 
> > > >         .... }}
> > > > which is generally easier to understand if you have
> > > > given as labels good descriptive phrases.
> > > 
> > > You could achieve the same with macros :
> > > 
> > > int foo (int x) {
> > > #define  trivial_case {  \
> > >     ....                 \
> > > }
> > > #define  easy_case {     \
> > >     ....                 \
> > > }
> > > #define  usual_case {    \
> > >     ....                 \
> > > }
> > >     if (x < 0) trivial_case
> > >     else if (x == 0) easy_case
> > >     else usual_case
> > >     return 13 ;
> > > }
> > > 
> > > Your code looks cleaner but I'm not sure the difference is worth adding
> > > the new syntax.
> > 
> > Since I am writing a compiler an enhancement is easy. 
> > 
> > The problem with macros is that they must be defined before
> > they are used. That also applies to functions.
> 
> With local functions you could make the compiler so that it scans the whole
> body of the top level function to see if it has local functions. Then , in a
> 2nd pass , when it encounters a function call with a name coinciding with one
> of the local functions , it assumes this is what was intended otherwise it
> treats it in the same way it would a global function. I'm guessing that even
> with your enhancement it would need 2 passes.

I found it trivial to design my enhancement in a 1 pass
compiler. 

> > IMO top-down
> > more less dictates that the top level be presented to the
> > reader first. 
> 
> My impression is that the distinction top-down vs bottom-up is more related
> to how one designs and writes the code. Regardless of how the code was
> written , one can read it in any order one wishes. And there are tools which
> analyse C code and give you the tree of function calls so one can get a sense
> where each function lies in the hierarchy.
 
What I called top-down coding is designed to make the 
code easy and pleasant to understand. If you will you
can call it a documentation style.

It is a mechanical process to convert any C program 
into a form using my enhancement - the only work is
inventing perspicacious labels.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web