hcl icon indicating copy to clipboard operation
hcl copied to clipboard

Native Syntax: allow non-decimal integer literals

Open herrgahr opened this issue 9 months ago • 1 comments

Hello!

I'm considering HCL as a configuration language for an embedded software project. For this, it would be useful to have support for hexadecimal literals, maybe even binary and octal.

For simplicity reasons, I'm suggesting only a subset of Go's integer literals - some of the variations allowed there are not great for readability, especially octal literals like 07 or 0O7.

Since go-cty supports unsigned 64bit integers, it would make sense to limit the numeric range to that (uint64_t).

For existing HCL files, there should be no compatibility issues as far as I can tell. numeric literals as specified today will still parse unchanged, the only additions suggested are number literals of the form:

  • 0x12345678123ABCDE
  • 0b00001111000
  • 0o0666

Suggested Change in spec.md

NumericLit = BinaryLit | OctalLit | HexLit | DecimalLit;

BinaryLit = "0b" binary+;
binary = ('0' | '1');

OctalLit = "0o" octal+;
octal = '0' .. '7';

HexLit = "0x" hex+;
hex = (decimal | 'a' .. 'f' | 'A' .. 'F');

DecimalLit = decimal+ ("." decimal+)? (expmark decimal+)?;
decimal    = '0' .. '9';
expmark    = ('e' | 'E') ("+" | "-")?;

Notes Regarding Readability and (in-)Consistency in the Spec

For consistency reasons, one might be tempted to allow "0x" | "0X", "0b" | "0B" and "0o" | "0O", given that today's langauge spec allows for upper case E and lower case e in numbers (1.0e5 == 1.0E5). I am not suggesting this here. As mentioned above, the octal prefix "0O" is too easy to misinterpret IMHO.

herrgahr avatar Feb 05 '25 12:02 herrgahr