Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!husc6!cmcl2!yale!leichter
From: leichter@yale.UUCP (Jerry Leichter)
Newsgroups: comp.lang.c
Subject: Re: parens honored
Keywords: ANSI C standard
Message-ID: <21135@yale-celray.yale.UUCP>
Date: 8 Jan 88 17:27:20 GMT
References: <6829@brl-smoke.ARPA> <2845@zeus.TEK.COM> <6860@brl-smoke.ARPA> <12211@orchid.waterloo.edu> <6968@brl-smoke.ARPA> <1798@bsu-cs.UUCP> <6986@brl-smoke.ARPA>
Reply-To: leichter@yale-celray.UUCP (Jerry Leichter)
Organization: Yale University Computer Science Dept, New Haven CT
Lines: 37

With all the whining one way and the other about parens and order of
evaluation - and given all the changes to "K&R C", such as it was - why
not do things the clean way:  Round parens group but don't imply evaluation
order; "square parens" [] both group AND imply evaluation order.  This way
of doing things has a couple of advantages:

	- Complex mathematical formulas are often written with several
		different kinds of brackets; it makes them much easier
		to read.
	- When square brackets are used in formulas, they usually refer to
		larger, logically separate pieces, so it makes sense that
		they imply a stronger kind of grouping.
	- No existing code uses square brackets this way, so no existing
		code is affected at all.

Ah, you object, but square brackets are already used for arrays!  So what?
Parens are used for function calls as well as grouping; the syntaxes are
precisely analogous.

To make my proposal more complete:

	- Brackets and parens do NOT match each other - (a+b] is ill-formed.
	- Brackets can be used for grouping only in expressions; they cannot
		be used in other syntactic constructs that use parens (after
		for or if, or surrounding the typename in a cast or after
		sizeof, to give a couple of examples).  The one place this
		might be worth thinking more closely about is in grouping
		within typenames - [*int]() and such.  I doubt this is
		worth the extra ambiguity it adds to abstract declarators
		([] is analogous to ()).

If you really want, it's even possible to allow {} as another kind of
grouping operator in expressions, though (a) you'd have to make some fairly
arbitrary restrictions to eliminate ambiguities; (b) it would make error
recovery harder.  So I certainly wouldn't recommend it.

							-- Jerry