## Modern Language Features of Visual C++ 2005

From a language design perspective, this was interesting (emphasis mine):

Most noticeably for anyone reading code in the new syntax, the common double-underscore keywords prevalent in Managed Extensions for defining garbage-collected classes, properties, and so on, are a thing of the past. While a few of these keywords remain and a few more are being introduced, they are infrequently used and won't muddy up the readability of the code. These double-underscore keywords are being replaced with two new types of keywords: context-sensitive and spaced. Context-sensitive keywords are only keywords when used in certain contexts, and spaced keywords are only keywords when used in combination with other keywords. For example, the __property keyword from Managed Extensions is replaced with the property keyword. (Not only that, but the entire syntax for defining a property and its accessors has been dramatically refined, making the declaration look very similar to what you might write in C#. See Figure 1 for an example.) This doesn't prevent you from using "property" as the name of a variable in your code. A token parsed as "property" is only treated as a keyword when in the context of declaring a property on a type.

Curious if many other languages do that with keywords, and if it ends up being a cure worse than the disease...

## Comment viewing options

### Apple/gcc VMX "vector" context-sensitive keyword

When Apple added "Altivec" support to their version of gcc, it was done by making "vector" be a context-sensitive keyword -- a keyword only when it shows up in a declaration. See IBM dW article and page about VMX support for an overview and a few examples.

A cure worse than the disease? Let's just say that this didn't add much extra complexity, at least to the C++ parser.

### How would one add complexity to a C++ parser?

That's like trying to increase the national debt. :)

On second thought...

On second thought, this is likely another example of complexity begetting complexity. The syntax of C++, being quite fragile, makes it quite difficult to add orthogonal extensions without resorting to introducing new lexemes (in other words, keywords) and thereby breaking any program which uses said keyword as an identifier.

Personally, I think the use of double underscores for vendor extensions to C++ is a preferable solution. Identifiers starting with underscores are already reserved for the implementation, so correct code shouldn't be broken; plus it provides a visual clue that a non-standard extension is being employed. (And if a shop doesn't like the double underscore, then the preprocessor is trivially used to solve that problem).

For instance, Haskell import declarations use the keywords "qualified", "as", and "hiding", which are not in the list of reserved identifiers (look at "reservedid").

I don't know of any particular problem this causes for Haskell.

### sounds like macros in Scheme

which can have their own keywords. kinda context-sensitive...

;; completely useless non-sense just to prove a point...
(define (from ls)
(for-each (lambda ( x )
(display x)
(newline))
ls))

(define-syntax import
(syntax-rules (from)
((import foo)
(display (quote foo)))
((import (k1 ...) from foo)
(from (list (quote k1) ...)))))

;; and then...

(import (x y z beta zeta omega) from foo)
;; no surprises...


also, i know TCL is able to use identifiers with white-space in them...

### BASIC

Some old BASICs (I'm specifically thinking of those from Texas Instruments, but there may be others) had lots of noise words added, to make thing look more like English. Stuff like: draw sprite S at X,Y. I think those extra words were specific to each command and not general keywords.