Re: Parse

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Harry Binswanger  on Wed, 22 Jan 2003
17:42:13 -0500

> Could you say a little more about error conditions in parsing--or point me
> to the relevant docs (nothing is in "XPL User's Guide")?

Aren't any docs. Error conditions: basically you want to go to considerable
lengths to prevent them from ever happening. That means, you want to check
(using an IF...EI conditional) that the input separator is indeed contained in
the input$, before you let an XS parse happen. Looping especially must have
this check. Ignore that, and your program will crash or go haywire --
guaranteed.

> I get from above
> that if XS fails, due to nothing in s/g 01, then what was already in 03 and
> 05, if anything, might still be in them.

Correct, presupposing that the program itself survives the crash of XS. It
might, especially if XS was in a SUbroutine (the SUbroutine crashes back to the
program, like a child process crashing and restoring control to the parent).
Then again, it might not survive.

> And later, you indicate that 03
> and 05 may not get flushed when they should be giving a null.

Occasionally. I'm talking about a legal XS parse where 03 or 05 will
(properly) have length=0 -- only in that case. If length>0, then 03/05 will
hold accurate result strings, as long as the parse is itself correctly
constructed. If however the parse is illegal, all bets are off.

> is it kosher to use the same s/g twice as in:
>  or ?

General answer, yes -- but neither of the above examples is legal. Look, an XS
parse consists of five elements (assign positions aka S/Gs to them):

01,  02,       03,     04,       05
input$,input separator,output left$,output separator,output right$

Rules:
-----
You may not use the input$ S/G anywhere in the result output. It is
sacrosanct, and used once only. Cannot be omitted, must have content.

The input separator must have a separate S/G. That S/G may be repeated on the
result (output) side of XS. Cannot be omitted, must have content.

Either output position 03 or 04 may be omitted, but not both.

Position 05 may not be omitted.

Any omitted output position acquires, by the general rules of XyWrite, a value
of zero -- which translates in Save/Getland as S/G 00 (so the result is not
really "omitted", it is truly S/G 00). Luckily, S/G 00 is a special Save/Get
which sometimes plays a fundamental role in passing arguments to an XPL
[sub]routine, but most of the time is useless, and thus a good repository of
omitted values -- omitted either because the result is known (an output
separator, for example) or not useful:




These are also legal:





In the last example, S/G 02 will finally hold the result assigned to position
05 in the template above. You might use this where you only run the parse once
(and won't need again the input separator), and the only output you care about
is the right$ result. Also wastes just two Save/Gets -- very efficient.

A key discipline is to conserve Save/Gets -- and re-use them where possible.
The bigger the program, the more important that is -- it's easy to use up all
your memory when you leave Save/Gets lying around (it is exactly analogous to a
memory leak; when data is no longer required, the memory that it used should be
returned to the available pool). Transient Save/Gets only, of course (range
01-99) -- you have to fill out fifteen forms to get permission to use a
Permanent Save/Get 100-1999, and even then, may be denied.

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