TIP 472: Add Support for 0d Radix Prefix to Integer Literals

Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2017 Conference, Houston/TX, US, Oct 16-20
Send your abstracts to tclconference@googlegroups.com
by Aug 21.
Author:         Venkat Iyer <venksi@gmail.com>
Author:         Brian Griffin <brian_griffin@mentor.com>
State:          Accepted
Type:           Project
Vote:           Done
Created:        25-May-2017
Tcl-Version:    8.7


This TIP proposes adding support for a 0d decimal radix prefix to complement the existing 0x hexidecimal, 0o octal and 0b binary radix prefixes.


Verilog (and other Hardware Description Languages) always (or at least since the 1995 LRM) had a way to specify a decimal number explicitly. Verilog uses 'd343534 to mean decimal, VHDL actually allows any radix from 2 to 16 using syntax, so you could explicitly force a decimal interpretation using 10#343534#.

Tcl now allows 0b for binary in expr and format, which is similar to 'b in Verilog. And of course the 0x prefix has always been around. Another use case would be to prevent false parsing of leading zeroes in clock formats as octal, without having to go through a scan.

But a more elegant reason is that it makes the radix definition consistent, so

  1. all valid input radixes have a consistent unambiguous input literal format, and

  2. the d in format %d finally finds its complement in scan.


Extend the TclParseNumber function to recognize the prefixes 0d and 0D as decimal integers. It will have the same semantics as 0x, but base 10 instead of base 16.

Also extend format command '#' flag to produce the appropriate "0d" for the "%#d" conversion.


It's an integer:

   % expr {0d12 + 0d15}
   % format "%#x" 0d1024
   % format "%#d" 128

Errors same as other radix prefixes:

   % expr { 0d317g }
   invalid bareword "0d317g"
   in expression " 0d317g ";
   should be "$0d317g" or "{0d317g}" or "0d317g(...)" or ...
   % expr { 0x1.53 }
   missing operator at _@_
   in expression " 0x1_@_.53 "
   % expr {0d7.23}
   missing operator at _@_
   in expression "0d7_@_.23"


Currently, literals beginning with 0d and parsed as a number will produce an error. Any code expecting such an error would fail to produce an error an thus have a change in behavior. I would expect this situation to be uncommon.


An implementation can be found the fossil on the "bsg-0d-radix-prefix" branch, including %#d conversion support.


This document has been placed in the public domain.