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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#136474

On 10/9/18 1:23 AM, Spiros Bousbouras wrote:
> 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.

Not unlike C++ classes, where member functions defined inline in a class
are allowed to refer to other members, even if defined later in the
class definition.

It does break the precedent that C is 'one-pass' language, where in
principle, a compiler is able to process a file making a single pass
through it, never having to back up more than to the beginning of the
current statement/declaration. (The final link step does require the
linker to be able to go back and 'fix up' previously generated code that
knew it was going to need to be fixed up.)

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

#136472

On 10/9/18 2:22 AM, David Kleinecke wrote:
> Since I am writing a compiler an enhancement is easy.

What is it with all the people who are "writing a compiler" in this group?

This is comp.lang.C, not comp.lang.my-fantasy-language-based-on-C

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

#136478 — C is often used as an "implementation language" for other languages. (Was: An enhancement)

In article <r5iu8f-0qq.ln1@gangtai.home.grep.be>,
Wouter Verhelst  <w@uter.be> wrote:
>On 10/9/18 2:22 AM, David Kleinecke wrote:
>> Since I am writing a compiler an enhancement is easy.
>
>What is it with all the people who are "writing a compiler" in this group?
>
>This is comp.lang.C, not comp.lang.my-fantasy-language-based-on-C

Keep in mind that the need to support other languages has driven a lot of
gcc's development.  I.e., extensions are added to gcc so that gcc can be
used to implement compilers for other languages.

Example: &label syntax in GCC-C makes implementing Fortran easier.

-- 
Elect a clown, expect a circus.

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

#136484 — Re: C is often used as an "implementation language" for other languages. (Was: An enhancement)

On 09/10/18 15:13, Kenny McCormack wrote:
> In article <r5iu8f-0qq.ln1@gangtai.home.grep.be>,
> Wouter Verhelst  <w@uter.be> wrote:
>> On 10/9/18 2:22 AM, David Kleinecke wrote:
>>> Since I am writing a compiler an enhancement is easy.
>>
>> What is it with all the people who are "writing a compiler" in this group?
>>
>> This is comp.lang.C, not comp.lang.my-fantasy-language-based-on-C
> 
> Keep in mind that the need to support other languages has driven a lot of
> gcc's development.  I.e., extensions are added to gcc so that gcc can be
> used to implement compilers for other languages.
> 
> Example: &label syntax in GCC-C makes implementing Fortran easier.
> 

And local functions were implemented for Ada (and perhaps Pascal and
Modula-2).  gcc itself supports several languages - the C part is just
one front-end out of a half-dozen mainline gcc languages.  Some of these
extra features - like local functions - have been implemented as
extensions in the C front end.

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

#136479

On 09/10/2018 13:05, Wouter Verhelst wrote:
> On 10/9/18 2:22 AM, David Kleinecke wrote:
>> Since I am writing a compiler an enhancement is easy.
> 
> What is it with all the people who are "writing a compiler" in this group?
> 
> This is comp.lang.C, not comp.lang.my-fantasy-language-based-on-C

 From my recollection, there are jacob navia, Rick, Malcolm, fir, Thiago 
and the OP, other than myself, who have talked about writing compilers 
or related projects in this group.

(Maybe others have worked on compilers, but if they have, they haven't 
mentioned it. Although this is more about those who appear to be working 
on them single-handedly.)

Jacob navia's C compilers are for standard C with some extensions, and 
have been around for many years.

The OP's project appears to be based around C90.

My C compiler (there are a couple more) is also for an easy-to-implement 
subset of C90/99/11. There are no extensions, but it is sometimes used 
as a test-bed for new ideas. That product already exists.

So they cannot really be called fantasy languages, as they are solidly 
based on C. If there are extensions, they are real.

But sometimes new language features are discussed also.

(In my case, while such features may still be 'fantasy' as far as C is 
concerned, often they will actual features I've implemented elsewhere. 
Which means they can be viable.

The one in this thread is a case in point.)

-- 
bart

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

#136473

On Monday, October 8, 2018 at 9:23:06 PM UTC-3, David Kleinecke wrote:
[...]
> Since I am writing a compiler an enhancement is easy. 

Is it open source?

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

#136496

On Tuesday, October 9, 2018 at 5:21:09 AM UTC-7, Thiago Adams wrote:
> On Monday, October 8, 2018 at 9:23:06 PM UTC-3, David Kleinecke wrote:
> [...]
> > Since I am writing a compiler an enhancement is easy. 
> 
> Is it open source?

It would be were it complete enough to distribute. It is
not intended as a serious program but rather as a teaching
device. Currently I am stuck deep in the pre-processor.

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

#136507

On Tuesday, October 9, 2018 at 3:33:37 PM UTC-3, David Kleinecke wrote:
> On Tuesday, October 9, 2018 at 5:21:09 AM UTC-7, Thiago Adams wrote:
> > On Monday, October 8, 2018 at 9:23:06 PM UTC-3, David Kleinecke wrote:
> > [...]
> > > Since I am writing a compiler an enhancement is easy. 
> > 
> > Is it open source?
> 
> It would be were it complete enough to distribute. It is
> not intended as a serious program but rather as a teaching
> device. Currently I am stuck deep in the pre-processor.

I think C features are on topic for this group for several reasons.
Behind one feature there is some problem and maybe someone
know a good way to deal with it using the current C compiler.
Also a new feature could be added into C standard.

But I would be happy to participate in other group to talk 
in more detail about C compiler implementation like 
preprocessor.

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

#136469

On 09/10/2018 00:37, 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 ;
> }

Depending on the specs of the original proposal, this can behave 
differently.

For example in which variables are visible to the code in the macro.

And also, if it is intended to invoke each block more than once, it will 
cause the code to be repeated. This can cause problems with things like 
labels (with variable declarations, the whole thing can be wrapped in 
{...}).

-- 
bart

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

#136471

On 10/9/18 12:44 AM, 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: { 
>         .... }}

That is hardly different from:

if (x < 0) {
  // trivial case
  ....
} else if(x == 0) {
  // easy case
  ....
} else {
  // usual case
  ....
}
return;

Or you could, if you insist on having the logic separate from the if, do:

if(x < 0) goto trivial_case
else if (x == 0) goto easy_case
else goto usual_case;
trivial_case:
....
return;
easy_case:
....
return;
usual_case:
....
return;

Also note the lack of semicolons, otherwise the else is unexpected and
will cause things to fail ;)

(no, I don't recommend goto for this kind of thing, but it has the
advantage of already existing)

> which is generally easier to understand if you have
> given as labels good descriptive phrases.

Comments can also help with that.

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

#136475

On Tue, 9 Oct 2018 14:04:50 +0200
Wouter Verhelst <w@uter.be> wrote:
> On 10/9/18 12:44 AM, David Kleinecke wrote:
> > 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: { 
> >         .... }}
> 
> That is hardly different from:
> 
> if (x < 0) {
>   // trivial case
>   ....
> } else if(x == 0) {
>   // easy case
>   ....
> } else {
>   // usual case
>   ....
> }
> return;

I think what David really wants is local functions (i.e. functions within
functions) which do not accept any parameters , do not return a value and a
syntax which allows the compiler to recognise that it is a local function
call without having encountered first a declaration or definition for the
local function. The specific example he gave can be written using  goto's
but the more general case cannot (without very convoluted gymnastics).

> Or you could, if you insist on having the logic separate from the if, do:
> 
> if(x < 0) goto trivial_case
> else if (x == 0) goto easy_case
> else goto usual_case;
> trivial_case:
> ....
> return;
> easy_case:
> ....
> return;
> usual_case:
> ....
> return;
> 
> Also note the lack of semicolons, otherwise the else is unexpected and
> will cause things to fail ;)

Is this a joke I'm not getting ?

> (no, I don't recommend goto for this kind of thing, but it has the
> advantage of already existing)
> 
> > which is generally easier to understand if you have
> > given as labels good descriptive phrases.
> 
> Comments can also help with that.

-- 
But, it's a nice campus with some green spaces and you have the old, redbrick
buildings to make you feel like you're not a disappointment to your parents!
  https://www.studentcrowd.com/university-l1003801-s1008310-the_university_of_leeds-leeds

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

#136492

On 9/10/18 14:29, Spiros Bousbouras wrote:
> On Tue, 9 Oct 2018 14:04:50 +0200
> Wouter Verhelst <w@uter.be> wrote:
>> On 10/9/18 12:44 AM, David Kleinecke wrote:
>>> 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: { 
>>>         .... }}
>>
>> That is hardly different from:
>>
>> if (x < 0) {
>>   // trivial case
>>   ....
>> } else if(x == 0) {
>>   // easy case
>>   ....
>> } else {
>>   // usual case
>>   ....
>> }
>> return;
> 
> I think what David really wants is local functions (i.e. functions within
> functions) which do not accept any parameters , do not return a value and a
> syntax which allows the compiler to recognise that it is a local function
> call without having encountered first a declaration or definition for the
> local function.

Yeah, but I think it is a reasonably convoluted thing to want, and I
wanted to give examples about how something along those lines is already
possible with C today.

I can understand the desire for local functions, and share it somewhat.
But if you're going to create them, why settle for local functions that
don't take arguments and don't return values? That seems like a fairly
arbitrary restriction for no apparent value.

> The specific example he gave can be written using  goto's
> but the more general case cannot (without very convoluted gymnastics).

The goto's were just my second example, and I do agree that properly
returning from such a code block might be slightly more useful, but the
problem as stated doesn't do that.

[...]
> Is this a joke I'm not getting ?

No, it was me being confused about C syntax (I don't ever use if()
without a block following it, even if the block contains a single line,
so I forgot the rules for doing so). Sorry about that.

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

#136769

Spiros Bousbouras <spibou@gmail.com> wrote:

> I think what David really wants is local functions (i.e. functions within
> functions) which do not accept any parameters , do not return a value and a
> syntax which allows the compiler to recognise that it is a local function
> call without having encountered first a declaration or definition for the
> local function. The specific example he gave can be written using  goto's
> but the more general case cannot (without very convoluted gymnastics).

I guess he should learn about lambda functions in C++11.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

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

#136771

On Monday, October 15, 2018 at 12:19:44 PM UTC+3, Queequeg wrote:
> Spiros Bousbouras <spibou@gmail.com> wrote:
> 
> > I think what David really wants is local functions (i.e. functions within
> > functions) which do not accept any parameters , do not return a value and a
> > syntax which allows the compiler to recognise that it is a local function
> > call without having encountered first a declaration or definition for the
> > local function. The specific example he gave can be written using  goto's
> > but the more general case cannot (without very convoluted gymnastics).
> 
> I guess he should learn about lambda functions in C++11.
> 
> -- 
> https://www.youtube.com/watch?v=9lSzL1DqQn0


I don't think so.

1. Lambda functions are anonymous.
David wants *named* nested functions.
Being named is critically important, because [it seems to me that] important point of his proposal is an ability to call it from more than one location in the outer function.

2. Lambda functions are in-place
David wants his nested functions to be defined at the end of outer function because he feels that it would improve readability for top-down oriented readers. It seems likely that David himself is top-down character so he should know their needs better than decisively bottom-up people like myself.

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

#136772

On 15/10/18 23:07, already5chosen@yahoo.com wrote:
> On Monday, October 15, 2018 at 12:19:44 PM UTC+3, Queequeg wrote:
>> Spiros Bousbouras <spibou@gmail.com> wrote:
>> 
>>> I think what David really wants is local functions (i.e.
>>> functions within functions) which do not accept any parameters ,
>>> do not return a value and a syntax which allows the compiler to
>>> recognise that it is a local function call without having
>>> encountered first a declaration or definition for the local
>>> function. The specific example he gave can be written using
>>> goto's but the more general case cannot (without very convoluted
>>> gymnastics).
>> 
>> I guess he should learn about lambda functions in C++11.
>> 
>> -- https://www.youtube.com/watch?v=9lSzL1DqQn0
> 
> 
> I don't think so.
> 
> 1. Lambda functions are anonymous. David wants *named* nested
> functions. Being named is critically important, because [it seems to
> me that] important point of his proposal is an ability to call it
> from more than one location in the outer function.

You can name C++ lambdas.  From a bit of my own code:

   auto error = [this]( std::string function )
   {
     LOG_ERROR("Open: "+function+" failed %s", strerror(errno) );
     close(fd);
     fd = kInvalidFd;
     return false;
   };

   int Opt = 0;
   if (setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &Opt, sizeof(Opt)) != 0)
   {
     return error("setsockopt");
   }

   ... repeated in similar fashion for various socket operations ...

> 2. Lambda functions are in-place David wants his nested functions to
> be defined at the end of outer function because he feels that it
> would improve readability for top-down oriented readers. It seems
> likely that David himself is top-down character so he should know
> their needs better than decisively bottom-up people like myself.

Maybe, but I can't help feeling that's a bit like declaring a variable 
after it's used!

-- 
Ian.

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

#136774

On Monday, October 15, 2018 at 1:19:06 PM UTC+3, Ian Collins wrote:
> On 15/10/18 23:07, already5chosen@yahoo.com wrote:
> > On Monday, October 15, 2018 at 12:19:44 PM UTC+3, Queequeg wrote:
> >> Spiros Bousbouras <spibou@gmail.com> wrote:
> >> 
> >>> I think what David really wants is local functions (i.e.
> >>> functions within functions) which do not accept any parameters ,
> >>> do not return a value and a syntax which allows the compiler to
> >>> recognise that it is a local function call without having
> >>> encountered first a declaration or definition for the local
> >>> function. The specific example he gave can be written using
> >>> goto's but the more general case cannot (without very convoluted
> >>> gymnastics).
> >> 
> >> I guess he should learn about lambda functions in C++11.
> >> 
> >> -- https://www.youtube.com/watch?v=9lSzL1DqQn0
> > 
> > 
> > I don't think so.
> > 
> > 1. Lambda functions are anonymous. David wants *named* nested
> > functions. Being named is critically important, because [it seems to
> > me that] important point of his proposal is an ability to call it
> > from more than one location in the outer function.
> 
> You can name C++ lambdas.  From a bit of my own code:
> 
>    auto error = [this]( std::string function )
>    {
>      LOG_ERROR("Open: "+function+" failed %s", strerror(errno) );
>      close(fd);
>      fd = kInvalidFd;
>      return false;
>    };
> 
>    int Opt = 0;
>    if (setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &Opt, sizeof(Opt)) != 0)
>    {
>      return error("setsockopt");
>    }
> 
>    ... repeated in similar fashion for various socket operations ...
> 

I am not an expert, but would think that majority of experts would say that 'error' in your example is not lambda.

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

#136777

On 15/10/18 12:39, already5chosen@yahoo.com wrote:
> On Monday, October 15, 2018 at 1:19:06 PM UTC+3, Ian Collins wrote:
>> On 15/10/18 23:07, already5chosen@yahoo.com wrote:
>>> On Monday, October 15, 2018 at 12:19:44 PM UTC+3, Queequeg wrote:
>>>> Spiros Bousbouras <spibou@gmail.com> wrote:
>>>>
>>>>> I think what David really wants is local functions (i.e.
>>>>> functions within functions) which do not accept any parameters ,
>>>>> do not return a value and a syntax which allows the compiler to
>>>>> recognise that it is a local function call without having
>>>>> encountered first a declaration or definition for the local
>>>>> function. The specific example he gave can be written using
>>>>> goto's but the more general case cannot (without very convoluted
>>>>> gymnastics).
>>>>
>>>> I guess he should learn about lambda functions in C++11.
>>>>
>>>> -- https://www.youtube.com/watch?v=9lSzL1DqQn0
>>>
>>>
>>> I don't think so.
>>>
>>> 1. Lambda functions are anonymous. David wants *named* nested
>>> functions. Being named is critically important, because [it seems to
>>> me that] important point of his proposal is an ability to call it
>>> from more than one location in the outer function.
>>
>> You can name C++ lambdas.  From a bit of my own code:
>>
>>    auto error = [this]( std::string function )
>>    {
>>      LOG_ERROR("Open: "+function+" failed %s", strerror(errno) );
>>      close(fd);
>>      fd = kInvalidFd;
>>      return false;
>>    };
>>
>>    int Opt = 0;
>>    if (setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &Opt, sizeof(Opt)) != 0)
>>    {
>>      return error("setsockopt");
>>    }
>>
>>    ... repeated in similar fashion for various socket operations ...
>>
> 
> 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.

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

#136779

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.)

-- 
bart

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

#136780

On Monday, October 15, 2018 at 8:15:36 AM UTC-3, Bart wrote:
> On 15/10/2018 12:03, David Brown wrote:
> > On 15/10/18 12:39,  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 diference between C++ lambdas and a regular 
function is that C++ lambdas can capture variables.
When you have an empty capture [], them the C++ lambda
can be used as function pointer.

When the capture is not empty the C++ implementation
corresponds to an object with the operator () 
and cannot be used as function pointer. It is an anonymous
object.

The C language could have lambdas without capture and this
would be compatible with C++.

I have implemented this feature in my transpiler.

Go to 
http://thradams.com/web/cprime.html

and select the Lambdas sample.
(I don't allow lambdas with capture.)

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

#136785

Thiago Adams <thiago.adams@gmail.com> writes:
<snip>
> When you have an empty capture [], them the C++ lambda
> can be used as function pointer.
>
> When the capture is not empty the C++ implementation
> corresponds to an object with the operator () 
> and cannot be used as function pointer. It is an anonymous
> object.

Actually the result of a lambda expression is *always* a closure object
(of a unique, unnamed type), but when the capture is empty, the object
has an implicit conversion to a function pointer.

(The std::function class in <functional> allows you to unify the two
kinds of callable value so that algorithms don't need to know if they
are being given a function pointer or a function object.)

-- 
Ben.

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

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

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

csiph-web