Parentheses in function calls

Discussion in 'C Programming' started by Tony Clough, Aug 28, 2010.

  1. Tony Clough

    Tony Clough Guest

    One possible problem with C as compared to other languages like Perl or
    Shell is that function calls require parentheses which leads to cluttered
    code. (But there are some funny exceptions in the standard library
    though, eg return and size_of do not need parentheses)

    Why not allow Juxtaposition to denote a functioncall with parentheses
    only needed to override other laws of precedence? Seems to me it would be
    easy to implement this and it would lead to cleaner code.

    Yours Tony
     
    Tony Clough, Aug 28, 2010
    #1
    1. Advertising

  2. Tony Clough

    Seebs Guest

    On 2010-08-28, Tony Clough <> wrote:
    > One possible problem with C as compared to other languages like Perl or
    > Shell is that function calls require parentheses which leads to cluttered
    > code.


    It doesn't look "cluttered" to me. I actually sort of like it for the
    clarity.

    > (But there are some funny exceptions in the standard library
    > though, eg return and size_of do not need parentheses)


    That's because they are not functions.

    > Why not allow Juxtaposition to denote a functioncall with parentheses
    > only needed to override other laws of precedence? Seems to me it would be
    > easy to implement this and it would lead to cleaner code.


    1. It's not easy to implement.
    2. It creates nasty ambiguity problems in some cases.
    printf "hello %f", math_function 3.0, 4.0
    3. It does not necessarily lead to "cleaner" code. It leads to code that
    looks more like what you are used to seeing as good style if you're coming
    from Ruby or perl or something.

    On the whole, I have found that C's style works very well for what I want
    C to do, which is to be relatively unambigous even if it's a bit punctuated
    at times. I certainly don't always use ()s for method calls in Ruby, but
    I have had more bugs involving arguments going to the wrong method in Ruby
    over a couple of years of casual use than I have in twenty-some years of
    fairly active use of C.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Aug 28, 2010
    #2
    1. Advertising

  3. Tony Clough

    Felix Palmen Guest

    * Tony Clough <>:
    > One possible problem with C as compared to other languages like Perl or
    > Shell is that function calls require parentheses which leads to cluttered
    > code. (But there are some funny exceptions in the standard library
    > though, eg return and size_of do not need parentheses)


    Four theses:

    1. return is a statement
    2. size_of does not exist in C
    3. sizeof is an operator
    4. you don't think enough before posting

    --
    Felix Palmen (Zirias) + [PGP] Felix Palmen <>
    web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
    my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
    http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
     
    Felix Palmen, Aug 28, 2010
    #3
  4. On 8/28/2010 4:02 PM, Tony Clough wrote:
    > One possible problem with C as compared to other languages like Perl or
    > Shell is that function calls require parentheses which leads to cluttered
    > code. (But there are some funny exceptions in the standard library
    > though, eg return and size_of do not need parentheses)
    >
    > Why not allow Juxtaposition to denote a functioncall with parentheses
    > only needed to override other laws of precedence? Seems to me it would be
    > easy to implement this and it would lead to cleaner code.


    Funny. This is precisely one of the reasons I _don't_ like Perl as
    much as C. I'd much rather see the arguments of a function surrounded
    by parantheses than not.

    --
    Dan Giaimo
     
    Daniel Giaimo, Aug 28, 2010
    #4
  5. Tony Clough

    BartC Guest

    "Tony Clough" <> wrote in message
    news:i5bq1j$bpo$...
    > One possible problem with C as compared to other languages like Perl or
    > Shell is that function calls require parentheses which leads to cluttered
    > code. (But there are some funny exceptions in the standard library
    > though, eg return and size_of do not need parentheses)
    >
    > Why not allow Juxtaposition to denote a functioncall with parentheses
    > only needed to override other laws of precedence? Seems to me it would be
    > easy to implement this and it would lead to cleaner code.


    Functions do need brackets (ie. parentheses), otherwise there are all sorts
    of problems: try removing them from any C code and see what it looks like.

    It would be like removing square brackets from array indexing; possible, but
    weird.

    It might work with Perl because no-one cares what Perl looks like anyway.
    And Shell isn't a serious language.

    Anyway brackets are everywhere in C not just in function calls.

    --
    Bartc
     
    BartC, Aug 28, 2010
    #5
  6. Tony Clough

    Tony Clough Guest

    Seebs writes:
    > That's because they are not functions.


    OK, functions, built-ins, same thing.

    > 1. It's not easy to implement.


    I don't see what's difficult about it, just a small change in the parser.

    > 2. It creates nasty ambiguity problems in some cases.
    > printf "hello %f", math_function 3.0, 4.0


    Yes, as I said parentheses would still be needed to override default
    precedence/associativity.

    > 3. It does not necessarily lead to "cleaner" code. It leads to code
    > that looks more like what you are used to seeing as good style if you're
    > coming from Ruby or perl or something.


    Don't know about Ruby, but Perl manages just fine and it produces much
    nicer code to look at and read.

    Yours Tony
     
    Tony Clough, Aug 28, 2010
    #6
  7. Tony Clough

    Eric Sosman Guest

    On 8/28/2010 4:02 PM, Tony Clough wrote:
    > One possible problem with C as compared to other languages like Perl or
    > Shell is that function calls require parentheses which leads to cluttered
    > code. (But there are some funny exceptions in the standard library
    > though, eg return and size_of do not need parentheses)


    I'm sure someone will point out that neither sizeof nor
    return is a function.

    > Why not allow Juxtaposition to denote a functioncall with parentheses
    > only needed to override other laws of precedence? Seems to me it would be
    > easy to implement this and it would lead to cleaner code.


    distance = sqrt dx * dx + dy * dy;

    Discuss.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Aug 28, 2010
    #7
  8. Tony Clough

    Tony Clough Guest

    BartC writes:
    > Anyway brackets are everywhere in C not just in function calls.


    Your right, they could usefully be removed from if, while etc. as well.

    Yours Tony
     
    Tony Clough, Aug 28, 2010
    #8
  9. Tony Clough

    Tony Clough Guest

    Eric Sosman writes:
    > I'm sure someone will point out that neither sizeof nor
    > return is a function.


    Function, builtin, your splitting hares!

    >> Why not allow Juxtaposition to denote a functioncall with parentheses
    >> only needed to override other laws of precedence? Seems to me it would
    >> be easy to implement this and it would lead to cleaner code.

    >
    > distance = sqrt dx * dx + dy * dy;
    >
    > Discuss.


    My discussion is: you just need to establish precedence and associativity
    for calling a function just like all other operators.

    Yours Tony
     
    Tony Clough, Aug 28, 2010
    #9
  10. Tony Clough

    Seebs Guest

    On 2010-08-28, Tony Clough <> wrote:
    > Seebs writes:
    >> That's because they are not functions.


    > OK, functions, built-ins, same thing.


    No, no they are NOT.

    sizeof is an OPERATOR. Not a function. It doesn't require () for the same
    reason that + doesn't require().

    return isn't even an operator, it's a kind of statement.

    >> 1. It's not easy to implement.


    > I don't see what's difficult about it, just a small change in the parser.


    That you don't see what is difficult about it does not mean that it is
    easy, it just means that you don't know anything about the compiler.

    When you've done it without breaking any existing code, tell us how easy
    it was.

    >> 2. It creates nasty ambiguity problems in some cases.
    >> printf "hello %f", math_function 3.0, 4.0


    > Yes, as I said parentheses would still be needed to override default
    > precedence/associativity.


    And that would create an inconsistency of usage which is, in many cases,
    worse than the current situation.

    >> 3. It does not necessarily lead to "cleaner" code. It leads to code
    >> that looks more like what you are used to seeing as good style if you're
    >> coming from Ruby or perl or something.


    > Don't know about Ruby, but Perl manages just fine and it produces much
    > nicer code to look at and read.


    Uh.

    No, it really doesn't. Sorry, but I've been using perl for close to twenty
    years, and you would NEVER get me to say that it is "nice" to look at and
    read, let alone "nicer".

    What you have here is what we call "baby duck syndrome" -- you imprint on
    something and then it looks normal and good to you and other things look
    wrong. When I started using ruby, it looked weird to me because there were
    so few ()s and all the idioms were strange. Now I'm used to it and it
    doesn't look weird anymore.

    I still like C over Ruby and perl for clarity of syntax. I think Ruby wins
    for some applications because it allows me to omit a whole lot of syntax
    and write things more tersely, but it will always take more effort to
    parse complicated expressions than C will.

    C's design is to some extent historical -- it reflects what was reasonably
    cost-effective to do in a parser thirty years ago. However, it is a pretty
    solid design, it works, and there is no real reason to change this about it.
    There are good reasons for the way it is, and it seems to me that you would
    benefit a whole lot from learning more about the language before declaring
    how it should be changed.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Aug 28, 2010
    #10
  11. Tony Clough

    Seebs Guest

    On 2010-08-28, BartC <> wrote:
    > It might work with Perl because no-one cares what Perl looks like anyway.
    > And Shell isn't a serious language.


    I don't know about "Shell", but Unix shell programming is a pretty active
    field, simply because it's such a handy "guaranteed to be there" tool.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Aug 28, 2010
    #11
  12. Tony Clough

    Felix Palmen Guest

    * Tony Clough <>:
    > Eric Sosman writes:
    >> I'm sure someone will point out that neither sizeof nor
    >> return is a function.

    >
    > Function, builtin, your splitting hares!


    Damn idiot, get a clue or get lost.

    --
    Felix Palmen (Zirias) + [PGP] Felix Palmen <>
    web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
    my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
    http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
     
    Felix Palmen, Aug 28, 2010
    #12
  13. Tony Clough

    Seebs Guest

    On 2010-08-28, Tony Clough <> wrote:
    > Eric Sosman writes:
    >> I'm sure someone will point out that neither sizeof nor
    >> return is a function.


    > Function, builtin, your splitting hares!


    1. This "builtin" concept is not part of C.
    2. It's not splitting hairs, it's a significant detail.
    3. Splitting hares is something that Elmer Fudd never quite managed.
    4. You are awfully arrogant.
    5. You seem to start with the assumption that people who are experienced
    in a field will offer stupid irrelevancies, rather than that they know
    something you don't. This is a very stupid assumption.
    6. You seem to be bound and determined to declare your insights rather
    than listening to what other people have to say.
    7. You are currently about as ignorant of C as it's possible to be
    and still know what it is at all.
    8. You are actively refusing to consider or discuss what people say,
    responding instead with the assumption that they're idiots and you know
    more than they are.
    9. Your posts here are a waste of your time and ours. Ours because you're
    not contributing anything new, and don't know enough to even begin to frame
    something new. Yours because you won't learn anything with your current
    attitude.
    10. *plonk*

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Aug 28, 2010
    #13
  14. Tony Clough

    Ian Collins Guest

    On 08/29/10 08:56 AM, Tony Clough wrote:
    > Eric Sosman writes:
    >> I'm sure someone will point out that neither sizeof nor
    >> return is a function.

    >
    > Function, builtin, your splitting hares!
    >
    >>> Why not allow Juxtaposition to denote a functioncall with parentheses
    >>> only needed to override other laws of precedence? Seems to me it would
    >>> be easy to implement this and it would lead to cleaner code.

    >>
    >> distance = sqrt dx * dx + dy * dy;
    >>
    >> Discuss.

    >
    > My discussion is: you just need to establish precedence and associativity
    > for calling a function just like all other operators.


    In other words you have to work out what is being called. No wonder
    Perl is rebound as a write only language.

    --
    Ian Collins
     
    Ian Collins, Aug 28, 2010
    #14
  15. Tony Clough wrote:
    > Eric Sosman writes:
    >> I'm sure someone will point out that neither sizeof nor
    >> return is a function.

    >
    > Function, builtin, your splitting hares!
    >

    Really? Better report him to the animal cruelty people then.

    [Sighs lugubriously, shakes head, craws back into hole.]

    James
     
    James Lothian, Aug 28, 2010
    #15
  16. Tony Clough

    Guest

    Tony Clough <> wrote:
    >
    > One possible problem with C as compared to other languages like Perl or
    > Shell is that function calls require parentheses which leads to cluttered
    > code. (But there are some funny exceptions in the standard library
    > though, eg return and size_of do not need parentheses)


    That's because return and sizeof are not functions and are not part of
    the standard library. return is a statement (like if, for, and while);
    sizeof is an operator (like +, &, and <<).

    Perl's "string a bunch of words together with no punctuation and try to
    guess how it all actually gets interpreted" may be a bit less cluttered,
    but it's way more confusing.
    --
    Larry Jones

    I think your train of thought is a runaway. -- Calvin's Mom
     
    , Aug 28, 2010
    #16
  17. Tony Clough

    BartC Guest

    "Tony Clough" <> wrote in message
    news:i5bt22$gun$...
    > BartC writes:
    >> Anyway brackets are everywhere in C not just in function calls.

    >
    > Your right, they could usefully be removed from if, while etc. as well.


    I've done that with language design (but retained brackets for functions
    with one or more arguments). The result *is* cleaner (IMO). But I don't call
    the result "C".

    Any such change in C is simply not practical. But I'm sure you know this...


    --
    bartc
     
    BartC, Aug 28, 2010
    #17
  18. Tony Clough

    Geoff Guest

    On Sat, 28 Aug 2010 20:56:34 +0000 (UTC), Tony Clough <> wrote:

    >Function, builtin, your splitting hares!
    >


    Hairs.
     
    Geoff, Aug 28, 2010
    #18
  19. Tony Clough

    Felix Palmen Guest

    * Geoff <>:
    > On Sat, 28 Aug 2010 20:56:34 +0000 (UTC), Tony Clough <> wrote:
    >
    >>Function, builtin, your splitting hares!
    >>

    >
    > Hairs.


    Not to forget: you're.

    But then; why should english skills differ from any other language
    skills?

    Regards, Felix

    --
    Felix Palmen (Zirias) + [PGP] Felix Palmen <>
    web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
    my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
    http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
     
    Felix Palmen, Aug 28, 2010
    #19
  20. Tony Clough

    Seebs Guest

    On 2010-08-29, Richard Harter <> wrote:
    > Yes and no. Within the narrow confines of the terminology of the
    > C standard, sizeof and + are indeed operators, a separate
    > category from functions, and never the twain shall meet. From a
    > more general perspective operators are priveleged functions with
    > a specialized syntax.


    Hmm. While I grant that this is true, I'm not sure it's relevant --
    given that general terminology, C doesn't require ()s for all
    functions. :)

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Aug 29, 2010
    #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. Honne Gowda A
    Replies:
    2
    Views:
    885
    Karl Heinz Buchegger
    Oct 31, 2003
  2. andy6
    Replies:
    2
    Views:
    766
    andy6 via DotNetMonster.com
    Jun 9, 2006
  3. Kamilche
    Replies:
    11
    Views:
    1,728
    Nick Coghlan
    Jan 8, 2005
  4. Replies:
    2
    Views:
    938
    Bengt Richter
    Aug 1, 2005
  5. Bob
    Replies:
    5
    Views:
    264
Loading...

Share This Page