Lexical Structure

[Dan Bonachea]

Chapter 1: Lexical Structure: Are the PT() and RD() functions used later in the spec missing from this list? The examples seem to indicate these are in the global name space. Or is it actually upcxx::PT()? In general it's unclear whether or not identifiers introduced in later sections are in the upcxx:: namespace. Should either be more consistently explicit with including upcxx:: when formally defining the various identifiers in later chapters, or perhaps make a blanket statement that all other identifiers mentioned in the spec are universally in the upcxx namespace.

Ch1 "Keywords": We should probably stay away from the term "keyword" in the spec, since this is a library and these are technically macros (right?). Specifically, I'm assuming the user should be permitted to explicitly #undef them (for example when including blocks of C++ code that may have conflicting variable names).

[Yili Zheng]

I agree with Dan.

[Amir Kamil]

I suggest we add a sentence such as the following in this chapter, to avoid having to use the upcxx:: prefix everywhere:

Unless indicated otherwise, all functions and types introduced in this specification are defined in the upcxx namespace.

As for "keywords," I think the initial idea was to define a specification that could be implemented as either a library or a compiler, rather than restricting ourselves to the current implementation. (There are configuration options that are explicitly defined as macros later in the spec, but the names listed here are used to define statement- and expression- like constructs in UPC++.) But if others prefer to explicitly define these "keywords" as "macros," I'm OK with that.

[Dan Bonachea]

On the 5/6 telecon we made a few decisions relevant to the keyword issue that seemed to mostly have consensus. I've expanded on these somewhat here:

• The tokens defined in Ch1 (foreach, finish, teamsplit, memberof) will no longer be called "keywords" and instead be explicitly specified as macros that are defined by EVERY inclusion of <upcxx.h>.
• This means the user can avoid introducing these tokens into the namespace on a per-module basis by omitting the #include <upcxx.h>. This also implies other UPC++ features are unavailable, but that may be fine for compiling a vanilla C++ module (this is mostly a convenience feature so the UPC++ driver script can also correctly compile vanilla C++ modules).
• The user can also explicitly #undef these names after include, which may be desirable when #including a block of vanilla C++ code (for example a C++ library header that happens to use some conflicting variable names). In this situation the user may optionally #include <upcxx.h> a second time to restore the definitions. If we believe this is common we may even want a shorthand to undef the macros (eg #include <upccxx_undef_shortnames.h>), ie:

#include <upcxx.h>

// some UPC++ code using foreach, finish, etc

#include <upccxx_undef_shortnames.h>
#include <cxx_some_external_library.h>  // might use finish as  a variable name
#include <upcxx.h> // restore the definitions

// more UPC++ code

• This per-module control obviates the need for a --enable-short-names library configure option (which seems like the wrong place to control the namespace)
• None of this prevents a future UPC++ implementation from using compiler support to specially recognize and handle these (because the header file can just #define them to builtins)

[Amir Kamil]

I move that we close this issue, as it is not relevant to v1.0.