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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 10. Objects
Group: None
>Status: Pending
>Resolution: Accepted
Priority: 5
Submitted By: Lars Hellström (lars_h)
>Assigned to: Don Porter (dgp)
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: Don Porter (dgp)
Date: 2005-10-21 22:35

Message:
Logged In: YES 
user_id=80530


This ought to be fixed now.

Comment here if not.

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

Comment By: Kevin B KENNY (kennykb)
Date: 2005-05-10 15:12

Message:
Logged In: YES 
user_id=99768

TIP #132 doesn't fix this, but TIP #237 should.

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

Comment By: Donal K. Fellows (dkf)
Date: 2004-09-18 13:22

Message:
Logged In: YES 
user_id=79902

Doing anything about this "bug" requires a TIP and a great
deal of head-scratching. Transferring to the FRQ track...

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

Comment By: Donal K. Fellows (dkf)
Date: 2004-01-20 04:59

Message:
Logged In: YES 
user_id=79902

In speed terms, I don't think it would make much odds.  Any
string operations about will dominate for sure. :)

The problem is the semantic difference; nobody's sure how
much code exists out there that depends on 32-bit widths of
values.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-01-20 04:02

Message:
Logged In: NO 

Question.
 Would making all Tcl integers 64 bit quantities
 actually make a *noticeable* difference to speed
 even on 32bit machines?



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

Comment By: Lars Hellström (lars_h)
Date: 2004-01-02 16:02

Message:
Logged In: YES 
user_id=938835

The quickest way of fixing this bug is probably to keep the 
behaviour of the bytecode instructions, but change the string 
representation of wides so that this behaviour becomes 
proper. Such a string representation could be as that 
generated by the [format] specifier

   wide(%d)

since this has the merit of surviving an unbraced [expr]. 
From this would then follow that anything matching the RE

   wide\(-?(0|[1-9][0-9]*|0[0-7]*|0x[0-9a-f])\)

ought to be a valid integer. The main side-effect should be 
that output of wides which is not [format]ed may look a 
little strange, and that is probably acceptable.




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

Comment By: Donal K. Fellows (dkf)
Date: 2004-01-01 11: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 10: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=360894&aid=866469&group_id=10894