Path: utzoo!attcan!uunet!clyde.concordia.ca!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!mcnc!rti!xyzzy!bigbird.rtp.dg.com!langley
From: langley@bigbird.rtp.dg.com (Mark L Langley)
Newsgroups: comp.lang.c++
Subject: Syntax considered harmful
Message-ID: <826@xyzzy.UUCP>
Date: 5 Mar 90 15:39:04 GMT
Sender: usenet@xyzzy.UUCP
Reply-To: langley@bigbird.rtp.dg.com (Mark L Langley)
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 57


I'm afraid I must volley back a friendly disagreement with Bjarne 
Stroustup, language designer, C++ patriarch, and all in all a good 
guy to drink a beer with. 

His example,

  struct T { int i, j; };

  f()
  {
	T (*p)[7];      // declaration or expression?
	    		// declaration!

	T (*p)[7]->m = 7;       // declaration or expression?
	    			// expression!  
				// ** No, syntax error under 2.0 **

  }
  "bs.c", line 8: error: syntax error
  1 error

For the record, does not in fact compile under cfront 2.0. 

The problem, it seems to me, is not a distinction between syntax and 
semantics, its a question of what something should actually mean, and how 
do you know!  Second to that is finding some technology that can reliably
determine it mechanically.  Unfortunately, a rule like "if its a declaration,
fine, otherwise its a statement" doesn't suggest a good technology.

C++ is laced with a number of problems like this whereby a statement
is ambiguous.  The most famous is the function like cast.

	main() { int(x); }

This, too, is a syntax error under cfront 2.0, though documented
in the manual as an ANSI style declaration with a parenthesized
declarator.  This problem can be beaten by the judicious use of
YACC in a sorta-LR grammar.  (Jim Roskind and I have produced
similar results -- his are available from the net.)

Problems like this arise because C++, as a language of engineering
compromise between C, ANSI C, and C-With-Classes need *very similar*
syntax to mean different things.

While designing programming languages is hard, modifying programming
languages (with a blender) is agongizingly hard, because you have to
decide which interpretation to ignore.  In programming languages with
less ancestry, the question a BNF can answer is what is legal (plus or 
minus type-checking, and undeclared identifiers).  With C++, in addition 
to the function-like cast there are a number of other minor koans whose 
meaning is opaque, but legality unquestioned.

The big issue in C++ is not whether something is legal, but what it
means, and how can you tell.  I wonder if attributed grammars would
help, though I doubt it...  Any technology suggestions, netland?

Mark