Sujet : Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?)
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 29. Mar 2025, 18:25:39
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vs9aek$1sesb$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 26.03.2025 23:15, Keith Thompson wrote:
[ dyadic and monadic minus operations, and minus sign at literals ]
I don't know of any language that uses "-" for both negation (prefix,
one operand) and subtraction (infix, two operands) and treats -5
as a single token rather than a unary minus operator applied to the
constant/literal "5".
I as well don't know. It may simplify things if the '-' is detached
from a numeric positive literal, especially for numeric expressions.
There's certainly cases where a signed numeric token is appropriate,
thinking (for example) about a CONST declaration in Pascal, like
CONST a = -5; here you don't have expressions, just the primitive
type literals.[*]
The point why I think that a signed literal as entity may be useful
is that it's a static (compile time) property; -5 is in that respect
different from -x, the negation operation. A negative constant does
not "cost" a run-time operation.
Given what we recently discussed about a division by a constant,
where compilers (may) handle expressions by pre-calculating the
reciprocal for run-time efficiency, it's not that clear to me that
it matters either way.
I suppose it's a question of whether it complicates syntax definition
or parsing.
Janis
[*] Note: Pascal, syntactically, also doesn't have signed constants,
the sign is in all those contexts an explicit token, not part of the
number token. This holds for both, a 'CONST' declaration and being
part of an INTEGER literal in an expression. The 'REAL' literals are
also handled that way, the overall sign is not part of the numeric
token, but the sign of its exponent *is* part of the 'REAL' token.