Subj : baja.c / unbaja.c
To   : Digital Man
From : Angus McLeod
Date : Fri Sep 09 2005 12:14 am

  Re: baja.c / unbaja.c
  By: Digital Man to Angus McLeod on Thu Sep 08 2005 18:09:00

 >  > You may recall that I wrote a BAJA de-compiler long ago.
 > 
 > That does seem vaguely familiar. Do you still have that code around anywhere

No, it was LONG ago.  

 >  > That was before SBBS source code became publicly available.  At the 
 >  > time you sent me a copy of the header file containing all the 
 >  > current op-codes (probably cmdshell.h, unless the name has changed).  
 > 
 > Oh how nice it is to have CVS. :-)

Indeed!  :-)

 > Can you give me an example of a postfix version of the following ARS:

Hmmm.  It's been a while since I did this by hand, but let's see what we 
get...

 > ((LEVEL 80 OR FLAG S) AND AGE 18) OR LEVEL 90

 LEVEL 80 FLAG S OR AGE 18 AND LEVEL 90 OR

In fact, the operands here are really a shorthand, so the final postfix 
might be different, depending on how the low-level BAJA code functioned.  
LEVEL 80 for instance is not an atomic operand.  It really stands for 
LEVEL >= 80 which is itself infix and could be 'postfixed' along with the 
rest of the expression.  So if we expand and rewrite the infix using 
symbols instead of keywords:

 (($L >= 80 OR $F = S) AND $A >= 18) OR $L >= 90

This would then become

 $L 80 >= $F S = OR $A 18 >= AND $L 90 >= OR

But again, it depends how the various key words are implemented at low 
level.

 > LEVEL 90 OR (TIME 12:00 AND TIME NOT 18:00)

Note that "TIME NOT 18:00" is a very unusual construct.  It would be more 
usual (in another language) to say "NOT TIME 18:00".  But expanding 
shorthand:

 $L >= 90 OR ($T >= 12:00 AND $T ! >= 18:00)

See what I mean about "$T ! >= 18:00"?  I don't recall how this is 
actually implemented.  Does the NOT simply invert the sense of the 
following operator?   If so that should really be "$T < 18:00" which is 
what the code intends anyway.  So you might then get

 $L 90 >= $T 12:00 >= $T 18:00 < AND OR

or possibly

 $L 90 >= $T 12:00 >= $T 18:00 >= NOT AND OR

All this done without reference to any of my old reference books, so I 
wouldn't be surprised if a handful of errors crept in.....

 >  > I have never looked back on any non-trivial code I ever wrote without
 >  > experiencing the disturbing thought that I could have done better.  Even
 >  > with code that worked flawlessly over a long lifespan without any problem
 >  > ever being isolated, I always end up feeling that I could improve on it.
 > 
 > Me too! I wrote some programs that looked and worked great on the surface bu
 > under the hood were horrendous examples of programming. <shrug>

I suppose it isn't such a surprise.  By the time you have finished any 
significant project you are probably more knowledgeable about the end- 
user requirements *and* the tools and resources you have available than 
when you started.  The feeling that you could have done better is probably 
doe to the fact that you COULD have -- if you had known then what you know 
now!  :-)


---
 þ Synchronet þ Great programs on the Synchronet Channel at The ANJO BBS

.