Parentheses in function calls

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

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

 

[Seebs]

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

 

[Felix Palmen]

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

 

[Daniel Giaimo]

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.

 

[BartC]

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.

 

[Tony Clough]

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

 

[Eric Sosman]

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.

 

[Tony Clough]

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]

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

Function, builtin, your splitting hares!

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

 

[Seebs]

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.

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.

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.

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

 

[Seebs]

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

 

[Felix Palmen]

Function, builtin, your splitting hares!

Damn idiot, get a clue or get lost.

 

[Seebs]

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

 

[Ian Collins]

Function, builtin, your splitting hares!


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.

 

[James Lothian]

Function, builtin, your splitting hares!

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

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

James

 

[lawrence.jones]

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.

 

[BartC]

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

 

[Geoff]

Function, builtin, your splitting hares!

Hairs.

 

[Felix Palmen]

Hairs.

Not to forget: you're.

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

Regards, Felix

 

[Seebs]

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