C closures & lexical scoping

Discussion in 'C Programming' started by Khookie, Dec 12, 2007.

  1. Khookie

    Khookie Guest

    Woah... is it just me or do C programmers don't bother talking about
    how cool C can be (compared to Lisp, Haskell, etc.) - functionally
    speaking?

    // Lexical scoping - via nested functions
    #include <stdio.h>

    int main() {
    int x = 10;

    // lexical scoping
    static void test() {
    x = 123;
    }
    test();

    printf("%d", x);
    return 0;
    }

    // Closures
    #include <stdio.h>

    int triple(int num) {
    return num * 3;
    }

    int square(int num) {
    return num * num;
    }

    int main() {
    int x = 10;

    int (*func)(int);

    func = square;
    printf("%d\n", func(5));

    func = triple;
    printf("%d\n", triple(5));

    return 0;
    }

    Chris
    Khookie, Dec 12, 2007
    #1
    1. Advertising

  2. In article <>,
    Khookie <> wrote:
    >Woah... is it just me or do C programmers don't bother talking about
    >how cool C can be (compared to Lisp, Haskell, etc.) - functionally
    >speaking?


    Well...

    >// Lexical scoping - via nested functions


    Oops, C doesn't have nested functions. Gcc has them as an extension.

    >// Closures
    >#include <stdio.h>
    >
    >int triple(int num) {
    > return num * 3;
    >}
    >
    >int square(int num) {
    > return num * num;
    >}
    >
    >int main() {
    > int x = 10;
    >
    > int (*func)(int);
    >
    > func = square;
    > printf("%d\n", func(5));
    >
    > func = triple;
    > printf("%d\n", triple(5));
    >
    > return 0;
    >}


    I don't see any closures there, just pointers to functions. Without
    nested functions, there's nothing interesting to close over.

    -- Richard
    --
    :wq
    Richard Tobin, Dec 12, 2007
    #2
    1. Advertising

  3. Khookie

    Chris Dollin Guest

    Khookie wrote:

    > Woah... is it just me or do C programmers don't bother talking about
    > how cool C can be (compared to Lisp, Haskell, etc.) - functionally
    > speaking?
    >
    > // Lexical scoping - via nested functions


    /Standard/ C doesn't have nested functions. (Even if it did, I expect it
    would have them BCPL-style -- no access to non-static outer locals.)

    Note also the significant restriction of these GCC-specific closures: you
    can't export them out of the defining function:

    If you try to call the nested function through its address after the
    containing function has exited, all hell will break loose.

    [The text is from
    http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Nested-Functions.html

    which was the first hit for the Google string "gcc nested functions".]

    A functional programmer will sneer at this feeble attempt at higher-order
    programming.

    --
    Chris "in fact, I just did" Dollin

    Hewlett-Packard Limited Cain Road, Bracknell, registered no:
    registered office: Berks RG12 1HN 690597 England
    Chris Dollin, Dec 12, 2007
    #3
  4. Khookie

    Mark Bluemel Guest

    Chris Dollin wrote:

    > A functional programmer will sneer at this feeble attempt at higher-order
    > programming.


    What about all us dysfunctional programmers?
    Mark Bluemel, Dec 12, 2007
    #4
  5. Khookie

    cr88192 Guest

    "Mark Bluemel" <> wrote in message
    news:fjojlp$qqk$...
    > Chris Dollin wrote:
    >
    >> A functional programmer will sneer at this feeble attempt at higher-order
    >> programming.

    >
    > What about all us dysfunctional programmers?


    sitting around scoffing at the idea of the compiler silently inserting
    runtime calls, and other things, whenever we use certain language
    features...
    cr88192, Dec 12, 2007
    #5
  6. Khookie

    Chris Dollin Guest

    Mark Bluemel wrote:

    > Chris Dollin wrote:
    >
    >> A functional programmer will sneer at this feeble attempt at higher-order
    >> programming.

    >
    > What about all us dysfunctional programmers?


    It's imperative that you assign pure-functional programmers to the
    right category, otherwise they won't be able to effect you.

    IO, IO, it's off to work we go ...

    --
    Chris "no, really, /e/ffect is exactly what I meant" Dollin

    Hewlett-Packard Limited registered office: Cain Road, Bracknell,
    registered no: 690597 England Berks RG12 1HN
    Chris Dollin, Dec 12, 2007
    #6
  7. Khookie

    Mark Bluemel Guest

    Chris Dollin wrote:
    > Mark Bluemel wrote:
    >
    >> Chris Dollin wrote:
    >>
    >>> A functional programmer will sneer at this feeble attempt at higher-order
    >>> programming.

    >> What about all us dysfunctional programmers?

    >
    > It's imperative that you assign pure-functional programmers to the
    > right category, otherwise they won't be able to effect you.
    >
    > IO, IO, it's off to work we go ...
    >

    I'm oriented to object to your suggestions...
    Mark Bluemel, Dec 12, 2007
    #7
  8. Khookie

    jacob navia Guest

    cr88192 wrote:
    > "Mark Bluemel" <> wrote in message
    > news:fjojlp$qqk$...
    >> Chris Dollin wrote:
    >>
    >>> A functional programmer will sneer at this feeble attempt at higher-order
    >>> programming.

    >> What about all us dysfunctional programmers?

    >
    > sitting around scoffing at the idea of the compiler silently inserting
    > runtime calls, and other things, whenever we use certain language
    > features...
    >
    >
    >


    Yeah, for instance
    long long a,b,c;
    ....

    c = a/b;

    This generates a function call in C due to operator overloading...
    Division is overloaded and works with long long types, but in a
    32 bit system that means a function call
    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Dec 12, 2007
    #8
  9. Khookie

    Richard Guest

    "cr88192" <> writes:

    > "Mark Bluemel" <> wrote in message
    > news:fjojlp$qqk$...
    >> Chris Dollin wrote:
    >>
    >>> A functional programmer will sneer at this feeble attempt at higher-order
    >>> programming.

    >>
    >> What about all us dysfunctional programmers?

    >
    > sitting around scoffing at the idea of the compiler silently inserting
    > runtime calls, and other things, whenever we use certain language
    > features...


    I don't understand. It can do just that.
    Richard, Dec 12, 2007
    #9
  10. jacob navia wrote:
    > cr88192 wrote:
    >> "Mark Bluemel" <> wrote in message
    >> news:fjojlp$qqk$...
    >>> Chris Dollin wrote:
    >>>
    >>>> A functional programmer will sneer at this feeble attempt at higher-order
    >>>> programming.
    >>> What about all us dysfunctional programmers?

    >> sitting around scoffing at the idea of the compiler silently inserting
    >> runtime calls, and other things, whenever we use certain language
    >> features...

    >
    > Yeah, for instance
    > long long a,b,c;
    > ...
    >
    > c = a/b;
    >
    > This generates a function call in C due to operator overloading...
    > Division is overloaded and works with long long types, but in a
    > 32 bit system that means a function call


    Not necessarily. It could easily mean an idiomatic sequence of machine
    instructions (similar in concept to a C macro) instead.
    Philip Potter, Dec 12, 2007
    #10
  11. Philip Potter said:

    > jacob navia wrote:

    <snip>
    >>
    >> Yeah, for instance
    >> long long a,b,c;
    >> ...
    >>
    >> c = a/b;
    >>
    >> This generates a function call in C due to operator overloading...
    >> Division is overloaded and works with long long types, but in a
    >> 32 bit system that means a function call

    >
    > Not necessarily. It could easily mean an idiomatic sequence of machine
    > instructions (similar in concept to a C macro) instead.


    Or it could simply be translated to a native division instruction, on
    machines that have such a thing. Nothing in the rules prevents this.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Dec 12, 2007
    #11
  12. >>>>> "K" == Khookie <> writes:

    K> Woah... is it just me or do C programmers don't bother talking
    K> about how cool C can be (compared to Lisp, Haskell, etc.) -
    K> functionally speaking?

    Because we've seen what happens in comp.lang.lisp, which is all about
    how cool Lisp is and how misunderstood Lisp programmers are, and how
    ANY DAY NOW the great unwashed masses are FINALLY going to realize
    just how cool Lisp is and abandon all other programming languages.

    Scarcely a parenthesis to be found.

    And we're spending so much time repeatedly explaining to Jacob Navia
    the concept of "topicality," and how he'd get better responses to his
    posts if he posted them where they were on topic, that we just can't
    muster the energy for any more foolish advocacy.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, Dec 12, 2007
    #12
  13. Richard Heathfield wrote:
    > Philip Potter said:
    >
    >> jacob navia wrote:

    > <snip>
    >>> Yeah, for instance
    >>> long long a,b,c;
    >>> ...
    >>>
    >>> c = a/b;
    >>>
    >>> This generates a function call in C due to operator overloading...
    >>> Division is overloaded and works with long long types, but in a
    >>> 32 bit system that means a function call

    >> Not necessarily. It could easily mean an idiomatic sequence of machine
    >> instructions (similar in concept to a C macro) instead.

    >
    > Or it could simply be translated to a native division instruction, on
    > machines that have such a thing. Nothing in the rules prevents this.


    The phrase "32 bit system" is a woolly one, but I took it to imply that
    the machine did not have a long long-sized division instruction.

    Phil
    Philip Potter, Dec 12, 2007
    #13
  14. Khookie

    jacob navia Guest

    Philip Potter wrote:
    > Richard Heathfield wrote:
    >> Philip Potter said:
    >>
    >>> jacob navia wrote:

    >> <snip>
    >>>> Yeah, for instance
    >>>> long long a,b,c;
    >>>> ...
    >>>>
    >>>> c = a/b;
    >>>>
    >>>> This generates a function call in C due to operator overloading...
    >>>> Division is overloaded and works with long long types, but in a
    >>>> 32 bit system that means a function call
    >>> Not necessarily. It could easily mean an idiomatic sequence of machine
    >>> instructions (similar in concept to a C macro) instead.

    >>
    >> Or it could simply be translated to a native division instruction, on
    >> machines that have such a thing. Nothing in the rules prevents this.

    >
    > The phrase "32 bit system" is a woolly one, but I took it to imply that
    > the machine did not have a long long-sized division instruction.
    >
    > Phil


    I just wanted to point out the basic unity between operators and
    functions. An operator can lead to a function call when an operation
    is absent in the real machine. In a 32 bit system precisely most of
    the time there is no 64 bit division. (Actually I have never seen a 32
    bit system with native 64 bit integer division...)

    Of course it can be inlined.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Dec 12, 2007
    #14
  15. Khookie

    jacob navia Guest

    Charlton Wilbur wrote:
    >>>>>> "K" == Khookie <> writes:

    >
    > K> Woah... is it just me or do C programmers don't bother talking
    > K> about how cool C can be (compared to Lisp, Haskell, etc.) -
    > K> functionally speaking?
    >
    > Because we've seen what happens in comp.lang.lisp, which is all about
    > how cool Lisp is and how misunderstood Lisp programmers are, and how
    > ANY DAY NOW the great unwashed masses are FINALLY going to realize
    > just how cool Lisp is and abandon all other programming languages.
    >
    > Scarcely a parenthesis to be found.
    >
    > And we're spending so much time repeatedly explaining to Jacob Navia
    > the concept of "topicality," and how he'd get better responses to his
    > posts if he posted them where they were on topic, that we just can't
    > muster the energy for any more foolish advocacy.
    >
    > Charlton
    >
    >


    Yes, you are spending way too much time bashing navia as it seems.

    You would better keep quiet then, and apply your own advice.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Dec 12, 2007
    #15
  16. Khookie

    Richard Guest

    Charlton Wilbur <> writes:

    >>>>>> "K" == Khookie <> writes:

    >
    > K> Woah... is it just me or do C programmers don't bother talking
    > K> about how cool C can be (compared to Lisp, Haskell, etc.) -
    > K> functionally speaking?
    >
    > Because we've seen what happens in comp.lang.lisp, which is all about
    > how cool Lisp is and how misunderstood Lisp programmers are, and how
    > ANY DAY NOW the great unwashed masses are FINALLY going to realize
    > just how cool Lisp is and abandon all other programming languages.
    >
    > Scarcely a parenthesis to be found.
    >
    > And we're spending so much time repeatedly explaining to Jacob Navia


    Who is "we"? The royal "we"?
    Richard, Dec 12, 2007
    #16
  17. jacob navia wrote:
    > Philip Potter wrote:
    >> Richard Heathfield wrote:
    >>> Philip Potter said:
    >>>> jacob navia wrote:
    >>>>> Yeah, for instance
    >>>>> long long a,b,c;
    >>>>> ...
    >>>>>
    >>>>> c = a/b;
    >>>>>
    >>>>> This generates a function call in C due to operator overloading...
    >>>>> Division is overloaded and works with long long types, but in a
    >>>>> 32 bit system that means a function call
    >>>> Not necessarily. It could easily mean an idiomatic sequence of machine
    >>>> instructions (similar in concept to a C macro) instead.
    >>> Or it could simply be translated to a native division instruction, on
    >>> machines that have such a thing. Nothing in the rules prevents this.

    >> The phrase "32 bit system" is a woolly one, but I took it to imply that
    >> the machine did not have a long long-sized division instruction.

    >
    > I just wanted to point out the basic unity between operators and
    > functions. An operator can lead to a function call when an operation
    > is absent in the real machine. In a 32 bit system precisely most of
    > the time there is no 64 bit division. (Actually I have never seen a 32
    > bit system with native 64 bit integer division...)
    >
    > Of course it can be inlined.


    In which case why make it a function call in the first place? The thread
    about the comparison between operators and function calls is over.
    Philip Potter, Dec 12, 2007
    #17
  18. Khookie

    Kaz Kylheku Guest

    On Dec 12, 2:28 am, Khookie <> wrote:
    > Woah... is it just me or do C programmers don't bother talking about
    > how cool C can be (compared to Lisp, Haskell, etc.) - functionally
    > speaking?


    The set of C programmers who

    - are interested in Lisp and Haskell, but
    - seriously misunderstand lexical closures, and who
    - don't know what is or isn't a GCC extension

    is probably vanishingly small.

    > // Lexical scoping - via nested functions
    > #include <stdio.h>
    >
    > int main() {
    > int x = 10;
    >
    > // lexical scoping
    > static void test() {
    > x = 123;
    > }


    Function nesting is a GCC extension, not standard C.

    More importantly, it doesn't implement first class lexical closures.
    It has ``downward funargs'' only, like Pascal.

    True lexical closures means being able to do something like this:

    static int (*test(void))(void)
    {
    int local = 42;
    int nested(void)
    {
    return local;
    }

    return &nested;
    }

    int main(void)
    {
    int (*func)(void) = test();
    printf("%d\n", func());
    return 0;
    }

    The output is 42, because in this imaginary C dialect, &nested creates
    a closure instead of just a regular function pointer. A closure is an
    object which contains not just the address of the function, but also
    the function's captured lexical environment in which the ``int local =
    42'' binding is in effect. That environment survives the termination
    of the test() call, which is why when we call func(), it returns the
    value 42.

    The above is not permitted by the GCC extension. The GCC manual says
    that ``all hell will break loose''.
    Kaz Kylheku, Dec 12, 2007
    #18
  19. Khookie

    CBFalconer Guest

    Khookie wrote:
    >
    > Woah... is it just me or do C programmers don't bother talking
    > about how cool C can be (compared to Lisp, Haskell, etc.) -
    > functionally speaking?
    >
    > // Lexical scoping - via nested functions
    > #include <stdio.h>
    >
    > int main() {
    > int x = 10;
    >
    > // lexical scoping
    > static void test() {
    > x = 123;
    > }
    > ...


    Illegal. C doesn't allow nested functions.

    --
    Merry Christmas, Happy Hanukah, Happy New Year
    Joyeux Noel, Bonne Annee.
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Dec 13, 2007
    #19
  20. Khookie

    cr88192 Guest

    "Richard" <> wrote in message
    news:p...
    > "cr88192" <> writes:
    >
    >> "Mark Bluemel" <> wrote in message
    >> news:fjojlp$qqk$...
    >>> Chris Dollin wrote:
    >>>
    >>>> A functional programmer will sneer at this feeble attempt at
    >>>> higher-order
    >>>> programming.
    >>>
    >>> What about all us dysfunctional programmers?

    >>
    >> sitting around scoffing at the idea of the compiler silently inserting
    >> runtime calls, and other things, whenever we use certain language
    >> features...

    >
    > I don't understand. It can do just that.


    often cases, yes.

    none the less, people tend to dislike this kind of thing in C land (even as
    such, it happens sometimes), albeit it is a very common occurance in most
    non-C languages (where there are hidden runtime calls pretty much
    everywhere...).

    now, adding lexical scoping, ... would require this.
    write a nested function, get a function pointer. oh no, a function call...
    cr88192, Dec 13, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jon Harrop

    First class lexical closures

    Jon Harrop, Oct 14, 2007, in forum: Python
    Replies:
    2
    Views:
    311
    Bruno Desthuilliers
    Oct 15, 2007
  2. Matt Barnicle
    Replies:
    10
    Views:
    626
    Bruno Desthuilliers
    Dec 2, 2007
  3. walterbyrd
    Replies:
    16
    Views:
    462
    Steven D'Aprano
    Dec 18, 2008
  4. Aronaxis, the Sourceror

    (?{..}) and lexical scoping issues.

    Aronaxis, the Sourceror, Jun 20, 2004, in forum: Perl Misc
    Replies:
    3
    Views:
    198
    Anno Siegel
    Jun 21, 2004
  5. Louis.

    Lexical scoping question.

    Louis., Feb 10, 2005, in forum: Perl Misc
    Replies:
    8
    Views:
    183
    Michael Powe
    Feb 11, 2005
Loading...

Share This Page