A string doesn't equal itself

[J. Landman Gay]

Ken Ray wrote:
> On Sun, 8 Apr 2007 22:16:32 -0700, Mark Wieder wrote:
> 
>> string that represented a serial number she allowed the engine to
>> process the equality operator numerically. And gave it values beyond
>> those it could be expected to handle with a default margin of error.
> 
> Actually, Mark, this was her post:
> 
>>  put "09114E715806" = "09114E715806"
> 
> So she *did* quote it. I'd agree with you if it weren't quoted, but as 
> it was, I would expect this to be interpreted as a string and not a 
> number.

I'm torn between the two opinions. In a way, I agree with Mark. The 
flexibility of xtalk allows us to be very lax about variable typing -- 
we don't really have to do it at all. I believe the engine evaluates 
even quoted literals to try to type them. For example, this works:

  set the brush to "4"

If the engine were not evaluating the string, this example would fail. 
That means that even quoted literals are not always literals if they are 
numbers. I think it would be difficult to fix this problem without 
severely restricting the flexibility of the engine in general. We would 
be forced into pseudo-typing all variables by only using quotation marks 
when we really do mean exact literals. That wouldn't necessarily be a 
terrible thing, but it would break backward compatibility with 
traditional xtalk. The consequences of the engine change could affect 
lots more than the single, unique problem we're trying to fix. Here's 
another thing that works right now:

   put "4/9/2007" is a date

This isn't just a string. It is a string with numbers in it, and Rev has 
to evaluate them as such. The character "4" is not the number "4", which 
allows Rev to determine that "4/ew/2007" is not a date (an improvement 
over HC, which did think "ew" was a date.) If we remove the ability to 
parse quoted dates as numbers, then how do you solve the issue where 
1/1/2007 becomes an (incorrect) division command?

On the other side, as Richard says, a string should always equal itself. 
And in fact, it does, provided you force the engine to evaluate it as a 
string. I accomplished this by specifically adding quotation marks 
around the variables that contain the so-called "number". Jim points out 
that adding a null character does the same thing.

I think the engine performs flawlessly except in this one, narrow 
circumstance where there is a single "E" inside a group of numbers. I 
would be okay with RR just adding documentation clarifiying the possible 
pitfalls of using numerical strings. On the other hand, this behavior 
could throw people who weren't expecting it (and it threw me until I 
understood what was happening.) On the third hand, I've worked with 
numerical strings in Rev/MC for almost 10 years now and this issue has 
only occured once. It's a minor issue, though significant to the 
developer when it happens.

I guess I'll report it, and let the team figure out the best way to 
handle it.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com