On May 22, 2006, at 11:06 AM, Mark Wieder wrote:
I *do* regard tacking on an empty string to trick
the parser as a hack, and I haven't tried it in conjunction with
setting a non-default numberFormat. But I always thought numberFormat
was a post-numeric-processing display thing.
I had not thought of the process as "trick the parser", but that is a
good point.
We are forcing compiling of something that causes a coerce-to-string
to occur some place.
For historical (HyperCard) reasons, the result of arithmetic is
stored internally as a floating point number. If it is next used in
arithmetic, this is pretty handy.
But '&' needs a string. Though some compiler optimization is
possible, in general, that means checking the value to see if it is
in fp or string format and then converting to string if the first.
So--just guessing--the expression 'x&""' might be compiled like this:
concatenate( toString( getLocalVar("x") ), toString( literal
("") ) )
So in a sense, the hack is to get at the toString(). (This is for
illustration, the toString() might well be in the concatenate()
function.)
We like to think (ignoring arrays) that there is only one type of
values in Rev. That is _almost_ true. We can tell that there are fp
numbers inside. It would be nice if that was hidden. To do that
would require a 1-to-1 correspondence between fp values and some
string values. In that case, the fp would be some shortcut internal
notation for those string values. Virtually*, everything would be
strings. As far as the language is concerned or all these
discussions, there is no other form; it's all strings. It makes no
sense to get at toString(). There are no trunc() problems.
Well, not quite. We still have the heritage of numberFormat. What I
said would be true if numberFormat can then be ignored. That problem
is both technical and political.
Dar
* Virtually -- literally "from the view of the observer", but
especially "Don't panic, the geniuses at RunRev will make it run fast
and do whatever is needed internally to make it cool."
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
