[Tcl-bugs] [ tcl-Bugs-866469 ] Integers aren't strings anymore

[SourceForge.net <no...@so...>]

Bugs item #866469, was opened at 2003-12-27 23:11
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=866469&group_id=10894

>Category: 46. Bytecode Compiler
Group: current: 8.4.5
Status: Open
Resolution: None
>Priority: 1
Submitted By: Lars Hellström (lars_h)
Assigned to: Donal K. Fellows (dkf)
Summary: Integers aren't strings anymore

Initial Comment:
Throughout most of Tcl8, there has been a bug (or 
malfeature of the tcl_precision variable) that two float 
values can have identical string representations but 
still behave differently when operated on. I hope that 
TIP 132 will soon correct this.

Although floats have been slightly magical, one has 
however always been able to rely on integers to not hide 
any information from the string representation. Sadly, 
that isn't true anymore. Behold:

% set l [expr 65536]
65536
% set w [expr {wide($l)}]
65536
% string equal $l $w
1
% expr {$l * 65536}
0
% expr {$w * 65536}
4294967296

In short, the bug is that [expr] lets its result depend 
on details of the internal representation that are not 
recorded in the string representation.


In a larger perspective, I think this is a symptom of a 
failure to clearly decide what an integer should be in 
Tcl, but sortinh that out requires a TIP. (IMHO the only 
approach that has a chance of being consistent is to 
allow arbitrarily long decimal strings as integers, as 
now use efficient internal representations for integers 
up to 32 or 64 bits, and rely on some callback similar 
to [unknown] for all operations on larger numbers.)


----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2004-01-01 16:54

Message:
Logged In: YES 
user_id=79902

Yuck.

The problem is balancing between the real need for 64-bit
values and the (unknown) quantity of code out there that
assumes that int values are 32-bits wide.  If it hadn't been
for that (and the speed implications on 32-bit platforms),
I'd have preferred to make all integers 64-bits wide on all
platforms.
Trying to do something with magic representation shimmering
is unlikely to work well, since it is hard to make the
processor math ops give some kind of trap when they lose
information during the processing of ints.  Getting a cheap
way to perform the type guards is the critical part, that
and defining a non-surprising way to deal with the situation
(which currently escapes me.)

If you want to try your hand at fixing math ops, their
semantics are defined entirely within tclExecute.c; the
math-related ops start at INST_EQ and are mostly
self-explanatory (if long.)

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2003-12-31 15:50

Message:
Logged In: YES 
user_id=80530


Note this is assigned to Donal Fellows,
who is only intermittently available 
during the holiday season.

People interested in this report might
want to have a look at TIP 72, and
the compromises made to get 64-bit
integer support into Tcl while limiting
the incompatibilities introduced.

http://purl.org/tcl/tip/72.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=866469&group_id=10894