Math problems?

Dar Scott dsc at
Mon May 22 14:27:06 EDT 2006

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()  

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.


* 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."

More information about the Use-livecode mailing list