emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CC-mode highlight change between 24.5 and 25


From: Alan Mackenzie
Subject: Re: CC-mode highlight change between 24.5 and 25
Date: Sun, 4 Sep 2016 22:29:12 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Davis.

On Fri, Sep 02, 2016 at 11:39:54AM -0600, Davis Herring wrote:
> > I feared as much.  I've often wondered why the C++ language developers
> > have had such a low regard for unambiguous syntax, such as most other
> > (computer) languages have.  I've cursed them for it on more than one
> > occasion.

> Blame Ritchie (if we may speak ill of the dead), for similar vagueness 
> dates to C:

> /* Choose one: */
> /* typedef int foo; */
> /* void foo(int); */

> int arg;

> void f() {foo(arg);}

> Depending on which of the declarations you include, "foo(arg)" is a 
> declaration of a local variable "arg" or is a call to the function foo. 
> (Obviously the declarations would typically be hidden in a header.)

That's true, but it's vanishingly uncommon to declare a variable with
parentheses round it (unless there's good reason like in

    void (*foo) (void);

).

> Part of the reason for the introduction of uniform initialization in 
> C++11 is to avoid the most-vexing-parse (though it does nothing for the 
> above).

OK.

> > In other words, only semantics determine that the line 4 is a variable
> > declaration rather than a function declaration.  CC Mode doesn't do
> > semantics, except to a _very_ limited degree.  So we're reduced, yet
> > again, to difficult and unreliable heuristics.  Curse the C++ language
> > developers!

> At least here the heuristic of "out of a function, it's a function; 
> inside a function, it's a variable" works pretty well and both ways 
> (since most people avoid global variables with constructors).

Thanks!  That's what I've been coding up over the weekend.  It seems to
work reasonably well.

> Davis

> PS - If you like, I'll be sure to mention your curse in Issaquah 
> (https://isocpp.org/std/meetings-and-participation/upcoming-meetings). 
> (Just be sure to tell me on how many occasions you have cursed WG21; 
> curses queue like POSIX real-time signals.)

Maybe.  But what's done is done and is not going to get undone in future
C++ standards.  But if you could point out that (near) pure syntactic
tools like Emacs do exist, and that every ambiguity introduced into the
language causes massive amounts of work for the maintainers of those
tools (like me), that would be helpful.

For example, I don't get the impression that the C++ developers were
aware of the ambiguities caused by using "less than" an "greater than"
as template delimiters.  Unique operators, perhaps something like "[<"
and ">]" could have been chosen without detriment to the language.  "<"
and ">" have caused, probably, scores (if not hundreds) of hours of work
in CC Mode, and likely in other syntax dependent tools.

At the moment, we have rules like "semicolons and braces can not appear
within template delimiters".  PLEASE don't do anything to destroy the
utility of such rules in future C++ versions.  If something is currently
syntactically clear, PLEASE make sure it remains so.

> -- 
> This product is sold by volume, not by mass.  If it appears too dense or 
> too sparse, it is because mass-energy conversion has occurred during 
> shipping.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]