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

Groups > comp.lang.c > #136807

Re: An enhancement

Show all headers | View raw

David Kleinecke <dkleinecke@gmail.com> writes:

> On Monday, October 15, 2018 at 7:44:53 AM UTC-7, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>> > On 15/10/18 13:15, Bart wrote:
>> >> On 15/10/2018 12:03, David Brown wrote:
>> >>> On 15/10/18 12:39, already5chosen@yahoo.com wrote:
>> >> 
>> >>>> I am not an expert, but would think that majority of experts would
>> >>>> say that 'error' in your example is not lambda.
>> >>>>
>> >>>
>> >>> It /is/ a C++ lambda - there is no doubt about it.  You could, perhaps,
>> >>> argue that it is not a common use of lambdas, or that it is unusual for
>> >>> lambdas to be named in this way - you'd be wrong, I think, but it would
>> >>> at least make sense.
>> >> 
>> >> In that case let me be the first to ask: what's the difference between
>> >> such a thing, and a regular named function?
>> >> 
>> >> (I can see lambdas being used in this fashion (made-up syntax):
>> >> 
>> >>    fn = lambda{|x,y| x*x-y*y};
>> >> 
>> >>    print(fn(10,5));     # output 75
>> >> 
>> >> but the lambda itself is anonymous.)
>> >> 
>> >
>> > The lambda itself is indeed anonymous - but you can assign it to an
>> > identifier to give it a name.
>> 
>> Using the right terminology can help here.  A lambda expression is a
>> syntactic entity -- it exists only in the text of the program.  The
>> result of evaluating a lambda expression is what C++ calls a closure
>> object.  It is that object which is referred to by the name 'error' in
>> Ian's example.
>> 
>> When people talk of "a lambda" it is not usually clear whether they are
>> talking about a lambda expression or the "function object" that results
>> from its evaluation.  Often, though, it does not matter much.
>  
> I'm not sure anybody got my point.

I am not surprised.  The example you gave was either pointless or had
potentially undefined behaviour.  Here it is:

    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: { 
        .... }}

If all the ... code fragments end with "return <exp>;" it's all
well-defined but pointless -- just use goto.  If, as appears to be the
case, you expect a "do label;" statements to "come back" like a function
call, that lone return either gives undefined behaviour or you are
writing pre-ANSI C (C without "void").  But even in pre-ANSI C, it was
conventional to leave the int implied when a function did not return a
value.  The result was I did not know what you really intended.

> I'm not trying to
> provide C with any new features or capabilities. I'm
> trying to document conventional C code better.

Eh?  The conventional code that corresponds to this fragment is just
fine as it is:

    void foo (int x)
    {
        if (x < 0) {
            // trivial case
            ...
        }
        else if (x == 0) {
            // easy_case
            ...
        }
        else {
            // usual_case
            ...
        }
        return;
     }

> I though I gave the game away completely by pointing out
> that any conventional C program could be modified - using
> my enhancement into a succession of simpler statements 
> which never embed a complex statement in another statement.

This is a non-problem as far as I can see.  I find nesting to be a
natural code structuring concept.  I will skip the details of each
branch when reading the code (a "folding" editor will help) so I don't
need the code tree to be flattened.

And your example would have been more interesting if it illustrated how
to simplify some code that would otherwise have more nesting.  I suspect
it does not improve the readability.

> If I do that - and make the labels explanatory - I have
> what I consider good top-down documentation of the program
> structure. Often no additional comments are needed.

There has to be a better reason to alter a programming language than to
permit labels to act as quasi comments.

-- 
Ben.

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

Thread

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

csiph-web