Doc Comments /
Lex
Lexical
 | | Table of contents of this page | |
|
|
Messages
Minor typo:
Decimal Literal, U Suffix Type
0U .. 4_294_967_296U uint
4_294_967_296U .. 18_446_744_073_709_551_615UL ulong
Should presumably be
Decimal Literal, U Suffix Type
0U .. 4_294_967_295U uint
4_294_967_296U .. 18_446_744_073_709_551_615UL ulong
As a mathematician I would like:
If I had two changes I would make to the C programming language, it is
1. Put in an exponentiation operator, a^b or a**b, so that 2**3 is 8. For a numerics programmer this would be really useful. This is one way that Fortran really scores over C. I know that there is the pow function in C, but it always treats the power as a float or double, where if the power is an integer it should really work differently. Also the optimization should be able to do clever things with a^2 (i.e. write it as inline code a*a). Also, using "pow" is just plain ugly. I do appreciate that a^b and a**b already have meaning in C (the first is exclusive or, and the second is a*(*b)), but I think that this is sufficiently worthwhile for numerics programmers that you either find a whole new symbol, or depreciate the current use of ^ or ** (e.g. one could insist that the current a**b is always written a* *b - I mean when does a**b actually ever appear in real code?).
2. a%b has a very definite and unambiguous meaning when a is negative, and b is positive. The output should be non-negative. This is something Perl has done right.
Another math suggestion
I support the creation of a ** operator, as suggested in the comment above. I would also like to have the possibility of writing complex numbers as 1+2j as well as 1+2i. (While this may look like a silly requirement, 1i and 1j have different meanings in some fields, such as in electronics, where they indicate the time convention used.) I think these two suggestions would make math coding even more comfortable. Thx.
identifiers & "unialpha"
Why is D referencing "ISO/IEC 9899:1999 (E) Appendix D" for defining "universal alpha"? "ISO/IEC 9899:1999 (E) Appendix D" isn't listing "universal alpha".
Sample: \u00B7 (MIDDLE DOT, Other_Punctuation) isn't an "universal alpha" but allowed by Appendix D in identifiers.
"ISO/IEC 9899:1999 (E) Appendix D" itself is referencing "ISO/IEC TR 10176:1998" for the character data. I strongly suggest to
drop the redirection via "Appendix D" and use "ISO/IEC TR 10176 (current)" instead of the dated version "ISO/IEC TR 10176:1998". The 1998 version didn't yet include quite a chunk of CJK and Math characters that can be found in the current version.
(from NG:digitalmars.D/42263 by Thomas Kuehne)
Suggestion
I recommend that the D Programming Language Lex specification reserves (or weakly reserves) all two-to-six long lowercase a-to-z ASCII identifiers ( [a-z]{2,6} ) which have at least one [aeiouy] character, for future language expansion. Perhaps further relax the reserved identifiers by saying only English words are reserved. That should accommodate future language needs as the language grows. --Eljay
Links
|