CoCoA » CoCoALib

One possibility would be to require that an integer literal start with a decimal digit: e.g. there is no problem in decimal or octal, but in hexadecimal one would write 0abc instead of abc. If the number in hex already starts with 1-9 then it is not necessary to prepend a zero (but it is also harmless to do so).

I'm far from convinced that it is a good idea to use the istream (and ostream) base indicators; it is hard to imagine when it could be useful.
CoCoA could offer functions octal and hex (or hexadecimal) which convert an integer (and maybe a rational) into a string.... maybe?

Note that in C++ octal literals start with 0 and then have further octal digits; hex literals start with 0x and then have further hex digits.
So my suggestion above to start a hex literal with just 0 could be confusing to those who know C++... :-(

There is an output option in C++ showbase which forces output of the appropriate C++ standard prefix; not sure what it does for input (seemingly nothing).

Regarding point (1)... what should input of a BigRat do with the following input streams?

• 1/2 -->JAA: ok
• -1/2 -->JAA: ok
• 1/-2 -->JAA: err
• -1/-2 -->JAA: err
• - 1/2 -->JAA: ???
• 1 /2 -->JAA: ???
• 1/ 2 -->JAA: ???
• 1 / 2 -->JAA: ???
• 1/0 -->JAA: div-by-zero

If spaces are not allowed then - 1/2 will give error after the minus sign (and ready to read space-1-slash-2); 1 /2 will successfully read BigRat(1) and be ready to read /2;
1/ 2 will give error after the slash, and be ready to read 2 (space two); 1 / 2 is much like 1 /2.

Opinions?

Ooops! I have had a look a what happens when a BigInt is read... and I found a bug :-(

For BigInt no space is allowed between a minus sign and the first digit.

Currently reading a BigInt not in decimal will produce a wrong result: the string of digits is correctly read, but BigIntFromString assumes that the base is 10.

One mild concern is that the reading fns in C++ try to accept the maximum length initial string which gives "valid" input.
When reading a rational we could encounter an input stream containing 1/z. The max length initial string giving a valid rational is 1, but we can know this only after having read the slash and then seeing that the next char is not a valid digit; it is possible to "put back" the slash which has been read (and thereby mimic the behaviour of the input operators for built-in types).

However, we surely cannot mimic the behaviour of the input operators for built-in types when reading a symbol (see issue ???) because we might then need to put back an arbitrarily large number of characters (which is not portable).

Since we cannot do it for symbols, I am inclined to say that we should also not do it for rationals.