Re: xpl parsing prob

[Robert Holmgren holmgren@xxxxxxxx]

** Reply to note from "Carl L. Distefano"  Tue, 22 Oct 1996 01:18:01 EST

> Reply to note from "..."  Mon, 21 Oct 96 21:26:33 +0000

>> When I do parse, I find it crucial to keep the cursor on the
>> CMline, then to BC, because parsing--as I do it--works fine
>> but throws around ascii 1s like mad . . .
>> [Tyson] recommends using {sxNN,{isNN}} in ambiguous situations.
>> Fixes nothing for me . . .

> Annie:
> . . . Generally, the unexpected printing of Ascii-1 is a symptom
> of an illegal attempt to manipulate a value that was saved as an
> expression () as though it were a string () . . .
> EDITOR for some reason erroneously interprets the contents of
> S/G 03 as an expression rather than a string, and prints the unwanted
> Ascii {1} . . .

An old, still baffling issue, isn't it? It hasn't cropped up on my screen
in years, and I think it scarcely exists in Xy4 except insofar as you can
force it out by GT-ing a number. Carl's explanation is correct. The
problem reflects the way numeric data is maintained in XyWrite's internal
memory (although smileys are not "a kind of multiplier for numerical data"
per Tim Baehr). What happens is that, First, every Save Get is labeled to
indicate the type of Save/Get it is: string, number, concatenation,
subroutine, et cetera. Second, the actual data is stored either in literal
form or in a condensed numeric form. Suppose we save the current year. A
string literal, saved as , acquires the type label "0"
(=0) and occupies four bytes in memory (=4). The same value,
saved numerically as , receives the type label "4" (=4)
and occupies six bytes in memory (=6). How are numeric Save/Gets
stored? Here are a few examples, generated with this piece of RUNCODE:

)>   

S/G      Length     Contents         Value
    6    1996{Ascii-0}{Ascii-1}    1996
    4    15{Ascii-0}{Ascii-1}     15
    5    200{Ascii-2}{Ascii-1}    2.0
   4    51{Ascii-5}{Ascii-1}     .00051
   6    2211{Ascii-2}{Ascii-1}    22.11

The first of two trailing bytes indicates the position of the decimal point
within the data. Thus, in the fourth example , the data ends
five -- {Ascii-5} -- places to the right of the decimal point (the data,
"51", therefore needs to be padded with three leading zeroes). Notice that
a terminal {Ascii-1} marks the end of numeric data in _all_ cases -- and
that is the source of all the smiley vagrant Ascii-1s you see on your
screen. Why do they come? Obviously they appear because, under v3.5x, XS
treats some of these numeric variables as strings! Most people use math in
XPL as simple counters or whatever, i.e. as integers. Note that the two
trailing bytes after a positive integer are always going to be Ascii-0
(which XyWrite can't display and therefore is essentially 'tossed away',
i.e. you don't see it), and then Ascii-1, which prints to your screen. Xy4
seems to be quite careful about not allowing parses of non-string data,
although if you simply GT such data, both of the trailing bytes show
(unless Ascii-0). Xy3 was much less aware of this issue.

> So, the short answer to your problem is to turn error suppression off
> (ES 0) before parsing.

True. But my recollection is that you can also just convert the number to
a string (e.g. >) before XS-ing it. If not, please give a
specific example of the phenomenon (simplest you can construct).

Mercifully, all this is bye-bye with Xy4.



-----------
Robert Holmgren
holmgren@xxxxxxxx
-----------