[Cfp-interest 1406] thoughts on namespace, etc.

[Jim Thomas]

Some thoughts on namespace ...

CFP has tried to add full support for IEC 60559 by following existing C style and with minimum invention of language features. 

IEC 60559 calls for a huge number of interfaces ~= operations X types. C doesn’t have a mechanism for managing namespaces for external linkage.

Would have been a better topic 8 years ago.

Paper contains two kinds of proposals, with some overlap. Ones related to namespace and ones related to style. Some separation might be needed.

1. 
Most of your proposed changes are intended to reduce the likelihood of conflict. They don’t reduce the number of identifiers from the current user namespace. So argument from hypothetical probabilities seems questionable. Could data bases of user code be searched for instances of new identifiers?

HPUX had/has something like: entry points in libm had a normal primary name, _cospi, and a secondary name, cospi; math.h had #define cospi(x) _cospi(x), and the linker would use the secondary name only if a primary name were not found. User code produced primary names. Also, links sequenced standard libraries last in the search order, where possible. I believe all this managed to avoid most conflicts, though was not perfect. 

HP added five types (extended, quad, _Decimal32, _Decimal64, and _Decimal128) each with a full set of macros and suffixed functions, without namespace complaints from users that I recall.

1.1 
cr prefix misrepresented. See below.

1.1 
Why are reserved identifiers better than new types?

1.2 
Backing out or changing TS3 might be reasonable. TS3 goes beyond type extensions in order to support portable programming, by adding redundant types, could have double = _Float64 = _Float32x. 
Is adding math functions with fN and dN suffixes really going to coopt many user names? If name reservation is needed, why not just reserve names with these suffixes rather than new prefixes?

(1) basically adding macro operators
type could be controlled with casts, e.g., #define sqrtf(x) sqrt((float)x)
Implementations would have internal names for all the typed functions. Could typed math functions be treated as macro operators?
Hard to do without separating math library into pre and post C2X without breaking old code.

(2) How would this help with the external linkage issue?
Does CFP have any objection to putting decimal into <decmath.h>? It would mean a lot of redundant specification or a lot of references. Or could make 7.12 for <math.h> and <decmath.h>.

Q1 - open or agree - Namespace aside, TS3 is complicated and has no full implementations.
Q2 - question not clear - how does C allow user to control external linkage?
It’s the TS not its integration that determines compatibility - integration is an editorial function.
Q3 - what interfaces specifically are being referred to?
Is this be different from Q2.
Q4 - need more specifics. what would this mean for interchange and extended types?

2.
Having two different naming styles for similar functions, in the same header, e.g. for the old exp2 family and the new exp10 family, would be an ongoing inefficiency and annoyance for users, who would have to memorize or look up which functions use which style. 

A different scheme for these concerns could be something like a new <math_.h> header that provided all the suitable old and new math interfaces as they are now but with a reserved math_ prefix. Then <math.h> might continue as in C17. This would provide a simple consistent naming scheme for new code, and the general scheme would be extensible to other headers if needed.

3.1 
The proposal to use _t type names seems like a different issue. It offers nicer names but it increases rather than decreases the number of reserved names.  Might users have widely adopted names with _t for their own types?

What is the practical advantage of avoiding keywords? Implementation would have to have their own internal keyword-equivalents anyway.

fltN_eval_t would be more expressive than floatN_t, which might be too similar to fltN_t.

3.2 
_WIDTH is not a math.h feature, nor a floating point one per se.

Is there foreseeable further use of the _WiDTH suffix, not covered by the (U)?INT reservation?

3.4 - 3.7
Why prefixes over suffixes? Current C style generally uses suffixes. Why not reserve the current suffixes fN, dN, fNx, dNx?

Type prefixes instead of suffixes would mean names sort by type instead of function family. This would make using the index and other lists more difficult. This is part of the reason I find the lists in the proposal difficult to grok.

3.8 and 1.1
There is no reserved sqrt with a cr prefix. I don’t think there are any conflicts.

It’s important to reserve names for correctly rounded math functions, for use by early (including current) implementers.

CFP would support a proposal to change the cr prefix to cr_.

3.9 
Just looking at numbers, reserving prefixes or suffixes removes more names from user namespace. 
An attempt to use prefixes to create namespaces for argument types.

3.9.1
fe_ is used only for fe_dec_getround and fe_dec_setround, which correspond to fegetround and fesetround. This was a concession to easier reading, not intended to introduce a new prefix.

3.9.3,4
cmplx_flt_acospi vs cacospif
Is this a significant namespace issue, or mostly about style.


3.10
d64muld128, and the other functions that round to narrower type, follow the convention of prefix for result type and suffix for parameter type, which helps with parsing the name.
Question 13 is just about the prefix for the result type, right? toflt_addl vs faddl?

3.11.1
See 3.1 above.

What does “as if by typedef …” accomplish? If fltN_t is as if by typedef, then the corresponding complex types can’t be designated as fltN_t _Complex. Would need something like fltN_cmplx_t

_DecimalN has been in use for quite a while, doing back to the decimal TR. 

A style issue.

3.11.2
FENV_ is only used after #pragma STDC, so it’s not a namespace issue. Except for _Pragma?
Proposal would break consistency in pragma naming.

3.11.3
Introduces an inconsistency for a slight namespace benefit. Only fesetexcept, fetestexceptflag, fegetmode and fesetmode.

3.11.4
The names with “from" fits better with the scheme of return type prefixes and parameter type suffixes.

3.11.5 - 3.11.6
The proposed renaming to toint_logb and toint_quantexp doesn’t tell the return type. 

(logb better not viewed as a log followed by a conversion.)

So would have ilogb and toint_logb.

This scheme wouldn’t extend to existing functions lrint and llrint and lround and llround.

3.11.7
The type-suffix style naming for INFINITY and NAN, and carried on with SNAN, came from the use of that style for the similar math.h macro HUGE_VAL

We could put INFINITY, NAN, and SNAN with prefixes in float.h and obsolesce the suffixed ones in math.h.

3.11.8
Changing CR_DECIMAL_DIG to FP_DECIMAL_DIG loses the indication of correct rounding, which is key to the meaning.

CR_DECIMAL_DIG isn’t a significant namespace issue.


Some options regarding namespace:

0. reduce user namespace, following TS

1. reserve type-prefixes and rename, as Jens suggests

2. reserve a math prefix and rename, e.g., math_sinpi, perhaps in new header <math_.h>

3. add some form of namespaces, e.g., similar to C++’s

4. prefix new identifiers with two underscores, e.g., __sinpi

5. keep TS function names but reserve suffixes, maybe add “d” suffix for double

6. make math functions generic only (Jens idea)

7. remove Annex N from C2X and put it in a TS update

8. change Annex N to a proposal for adding IEC 60559 floating types only for added formats, hence e.g., no _Float32

9. back out decimal extensions, as Jens has suggested

What has been C’s position on adding namespaces? Could it be an optional feature, required for library extensions like ours?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20190918/e30ee607/attachment-0001.html