Re: xpl parsing prob

["Carl L. Distefano" CLDistefano@xxxxxxxx]

** 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. I see nothing in The Book
-> about this, although The Herb discusses xyW generating ascii
-> 4s and 19s when it regards strings as numeric data. I get the
-> odd ascii 18 as well as the many 1s, but no 4s or 19s. He
-> recommends using {sxNN,{isNN}} in ambiguous situations. Fixes
-> nothing for me.

Annie:

What Herb discusses and the Ascii-1 phenomenon you've observed are two
different things. There's a bug in XyIII+ that persisted at least
through v3.55, whereby certain operations generated extraneous Ascii-
1's when error suppression is on (ES 1). One such operation is the
manipulation of programming Save/Gets whose values are assigned via an
XS statement (as opposed to direct assignment with  or
). 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 (). To this
day, even in Xy4|XyWin, RUNning "" yields an extraneous
{1}. In a statement like , the
XyIII+ 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}.

So, the short answer to your problem is to turn error suppression off
(ES 0) before parsing. In fact, because the bug rears its head in many
contexts, not just parsing, the accepted wisdom among III+ programmers,
as I recall, was to leave ES off and set default EB to 0,0 (restoring
the original value on EXit). See, e.g., the III+ versions of
REORGaNiZE for examples. ES 1 was toggled on only in the special
situations where it was required, and then immediately turned off.

I hope this helps.


--------------
Carl Distefano * * * CLDistefano@xxxxxxxx
--------------