Conference iosg::all-in-1_v30

    F,
    
    Maybe another problem and I don't know if it is a typo but why haven't
    you included a continuation sign after the four backslashes? The next
    example works fine for me, I get function 2 and function 3 as output.
    
    FWIW, Sjaak.
    
    FOR PROFIL WITH .USER EQS "BOSMAN" DO       -
       .IF .USER EQS "BOSMAN" THEN              -
          .IF .USER NES "BOSMAN" THEN           -
             GET OA$DISPLAY = "function 1"      -
          ELSE                                  -
             GET OA$DISPLAY = "function 2" \\\\ -
          GET OA$DISPLAY = "function 3"
    .EXIT

Nested .IF statements are notoriously hazardous, due to the interesting way
they are "parsed".  My advice would be to avoid them: even if you get it to
work, a subsequent, seemingly innocuous, change to the code could break it.

However, in V3.0 there are new script directives .THEN and .ENDIF, which allow
conditionals to be nested more easily.

Scott

    Re -1: See 80 (.3)
    
    Sjaak.

	RE: .1 -- Yes, it was a typo; there *is* a continuation marker on each
line.

	RE: .0 -- What I was most interested in was *WHY* the addition of an
OA$NULL function made the line "work"!  The only difference between my second
and third examples was that silly OA$NULL, yet it made the difference in the
operation of the line.  Why?

	F

    
    	The script processor looks for lines starting with a "." and
    	treats them differently, compare these two:
    
    	.if xxx then .goto blah
    
    	and
    
    	.if xxx then oa$null \\ .goto blah
    
    	The second one is illegal (if I got the wrong number of backslashes
    	I am sorry, but I never understood them!).
    
    	I have had a similar problem with FOR loops and needed an OA$NULL.
    
    Regards,
    Paul

    You don't really want to hear about this do you Frank????
    It has to do with 2 things, 1 the number of times you went through the
    COMMAND dispatcher, and 2, the way a .IF is parsed.
    
    Starting with the easy one, when a .IF is encountered, ALL-IN-1 looks
    for a THEN and and ELSE to break the statement up into the clauses it
    needs. Thus in your first example the ELSE is seen as part of the 
    FIRST if, not the second. So it would only do function 2 if condition1
    were false. ALL-IN-1 isn't smart enough to know that your inside a
    second .IF and to go to the end and look backwards for the ELSE, it
    just assumes the first ELSE must go with the first .IF.
    
	FOR rse DO -
IF	  .IF condition1 -
THEN	    THEN -
	      .IF condition2 -
		THEN -
		  function1 -
ELSE		ELSE -
		  function2\\\\
	      function3

    
    Your second attempt fixes this by adding the second ELSE which
    makes things balance. BUT it has the wrong number of backslashes!
    It might look right, but its wrong. Remeber my old formula:
    backslashes = 2 (to the power of [times through COMMAND dispatcher]-1)
    
    Anything beging with a . after a THEN or an ELSE does not go back
    to the command dispatcher. So in your example 2 you will find that
    the second .IF has only been through the command dispatcher twice
    which requires 2 backslashes (2^[2-1]). But this would have been
    confusing to the FOR function. You really need to force 4 backslashes
    to make the FOR function happy. You could have fixed this via
    a .FU (thereby forcing the command dispatch to happen again). Your use
    of the OA$NULL causes it to NOT be a '.' after the THEN and so it
    goes to the command dispatcher again for the second .IF. Leaving off
    the . on the .IF use to also work, but I don't know if it still would.
    All of this is courtesy of the consistency of use of backslashes :^)
    between scripts and functions!
    
	FOR rse DO -
	  .IF NOT condition1 -
	    THEN -
    	      OA$NULL -
	    ELSE -
	      .FU .IF condition2 -
		THEN -
		  function1 -
		ELSE -
		  function2\\\\
	      function3

    
    Now I bet your more confused than you were, and wish you hadn't asked.
    
    Rick

    Rick,
    
    Only last week someone here at the CSC was asking where the "secret
    backslash formula" was defined and being too lazy to search for it
    in one of the old notes file I cheated and pulled it from the class
    you gave in Reading in June of 87 - now it lives in notes once more!
    
    there is the old saying "whenever 2 or more application programmers
    gather together then they shall recite the backslash formula
    2 to the power of number of times through the command dispatcher -1"
    
    Of course you don't need all those backslashes anymore with the new
    syntax stuff or so my old neighbour Ian told me and he's always right.
    
    Regards,
    
    Andrew.D.Wicks
                                     

    Talking about that formula always caused glassy eyes.... The major
    problem being most people don't know when you go though the command
    dispatcher levels.
    
    I just thought I'd pull it out to make Frank wish he hadn't asked
    his question!

    You don't even have to use backslashes if you negotiate the expression
    and jump over the clause!! This will always work!!
    
    .IF NOT (expression) THEN .GOTO else_if
    
       {IF clause when expression is true}
    
       .GOTO end_if
    .LABEL else_if   
    
       {ELSE clause when expression is false}
    
    .LABEL end_if
    
    
    Regards, Sjaak.

    Unfortunately .-1 wouldn't work in Frank's example, because you cannot
    do .GOTOs while you are inside the FOR function!
    
    He'd haveto do a FOR x DO DO y. And DO DO's should be considered
    DON'Ts! The IO of opening and closing the file for each iteration
    can be quite time consuming.
    
    RIck

    One point on the new .THEN...
    
    You cannot use a flow control . command (ie: .ABORT, .EXIT or .GOTO)
    from within one of these little beauties. Therefore half the time you
    have to go back to the golden oldie format and half the time that won't
    work like Frank's *SENSIBLE* example. (the second two are hard logic to
    follow and make for a maintenance nightmare.)
    
    I know I'll get yelled at but why is this sooooo hard! All I wanted to
    do is write a little script... I know I'll do it like this:
    
    	FOR {condition} DO COMMAND dcl_command_procedure
    
    then I'll be able to IF..THEN..ELSE to my hearts content. It may be
    slow but at least I'll know it works! (and the customer will buy a
    bigger box anyway!)
    
    regards,
    ajb
    
    PS: I'm not being serious, just sarcastic. ;-)

	It gets back to the fact that the argument to the THEN or ELSE clause
has to be either another script directive (e.g., .GOTO, .EXIT, .IF), or a single
command line.  The backslashes get confusing, since each pass through the
command dispatcher, backslashes are "halved" (i.e., two become one) -- just like
processing double quotes within a quoted string.

	So the "fun" is in determining just how many times this little "halving"
has been done.  That's what Rick's formula attempts to do.  The other way around
the problem, of course, is to "shield" the command line from this "backslash
biter", and make sure that it never gets processed until it's time to actually
execute the command line.  One way to do this is to use the GET OA$FUNCTION
syntax, since -- up until the time that the GET OA$FUNCTION gets executed --
its argument is merely a string... nothing more, nothing less.

	So let's suppose we're "buried" at a level that would normally require
8 backslashes:

	...
	    ELSE -
		function1\\\\\\\\ -
		function2\\\\\\\\ -
		function3

	You *could* reduce this "clutter" by doing something like:

	...
	    ELSE -
		GET OA$FUNCTION = "function1\function2\function3"