RFC: represent all litterals as string

[timotheecour]

literals-as-strings

this was discussed in forum recently (EDIT: not sure how to find it D20200425T182934; EDIT: https://irclogs.nim-lang.org/02-04-2020.html#12:45:32); the idea is to make the parser emit litterals (eg 123, 123'u8, 23.4, -34 etc) as strings instead of doing the parsing there; and the parsing would be deferred to semcheck phase

benefits

• BigInt support (eg https://irclogs.nim-lang.org/02-04-2020.html#12:37:04)
• remove edge case where T.low can't be used as a litteral for signed types T, eg -128'i8, see -128'i8 gives: Error: number out of range: '128'i8' #125
• repr (and runnableExamples rendering etc) would preserve original source code formatting (refs runnableExamples should preserve source code doc comments, strings, and (maybe) formatting nim-lang/Nim#8871); it'd also make it easier for nimpretty and nim doc

alternatives considered

• tkBigNum proposed here https://irclogs.nim-lang.org/02-04-2020.html#12:45:32 is less useful, doesn't help with other things, eg keeping source code representation, or floating point litterals

links

D20200425T180920

info

• https://irclogs.nim-lang.org/02-04-2020.html#12:39:02 fwiw nkIntLit is used in the compiler 131 times, it's quite a change

more discussion

(around https://irclogs.nim-lang.org/02-04-2020.html#12:31:25)

• strings really seem like the most sane option here.
• nimpretty, arbitrarily big custom int literals, fixing the -128 issue
• in the macro system we already have an 'intVal' accessor, we can do the parsing in there
• as 1000 loses information over 1_000'i32
• parsing them in the lexer is a hack really, nimpretty needs to extract the numbers back from the original source code

open questions

• how to deal with backward compatibility
• how to deal with existing macros

EDIT

migrated to nim-lang/compilerdev#7