/ elang / kernel

Integer Literal Expression

Has the conventional meaning -- evaluates to the expressed integer. Just as E integers are unlimited in precision, so are E's literal integers. However, as in Java, in E you can only express non-negative integers literally. "-3" expands into "3 negate". This should make no difference to the E programmer in practice.

Lexical Regex:	decimal: [1-9][0-9]* octal: 0[0-7]* hex: 0[xX][0-9a-fA-F]* Note that "0.2" and "0e3" are Float64, so a bit of lookahead is required to tell that the initial "0" isn't an octal integer.
XML DTD:	<!ELEMENT Integer #PCDATA> Where the #PCDATA must conform to the above regex, and should be written as it appears in the source text.
Java:	If the integer fits into into a Java int (32 bit 2's complement), then it translates into BigInteger.valueOf(digits) else, if it fits into a Java long (64 bit 2's complement), then it translates into BigInteger.valueOf(digitsL) else, the leading "0x" or "0X" is removed and it translates to new BigInteger("digits", radix) where radix is 8, 10 or 16 according to the format of the integer. These translations preserves as much of the original reading as possible.
Example:	-3
in Kernel-E:	3 negate
in XML:	<callExpr> <Integer>3</Integer> <Verb>negate</Verb> </callExpr>
in Java	E.call(BigInteger.valueOf(3), "negate") or, with a plausible amount of type analysis BigInteger.valueOf(3).negate()

The E programmer can always use an IntegerRegion to declare that a variable may only hold a subrange of integers, or that a return value may only be in a subrange:

? pragma.syntax("0.8")

? var x :(2..4) := 3
# value: 3

? x := 5
# problem: 5 is not in the region 2..!5

? x
# value: 3

Currently, such variables are always more expensive than unconstrained variables. However, we hope to eventually have such declarations enable scalar storage & arithmetic with only overflow checking.