RE: Full Thrust Format for Email games

Alex Williams writes:
@:) On Fri, 30 May 1997, Joachim Heck - SunSoft wrote:
@:) 
@:) > [ stuff to the list ]

  I am having more problems replying to the right places these
days....

@:) Its probably counter-productive to use curley-braces as a
@:) block-definition system; it makes parsing sequences a lot more
@:) complex than necessary.

  That's funny - that's just the problem I find with the system you
propose here.  Braces, or any delimiter are nice because they make a
recursive parse easy to keep track of.

@:) A better method might be to use a nested RFC822 (the UseNet format
@:) for email/news headers) structure.
@:) 
@:) ===
@:) DSIIVehicle: Medium Battle Tank (Tracked)
@:) Description: Standard MBT, relatively low-tech.
@:) Class: 3
@:) Mobility: Fast Tracked
@:) Powerplant: HMT
@:) Armour: 3
@:) ECM: Enhanced
@:) PDS: Enhanced
@:) 
@:) Weapon: HKP
@:) Class: 3
@:) Number: 1
@:) Turret: Yes
@:) Mount: Full Traverse
@:) 
@:) Weapon: RFAC
@:) Class: 3
@:) Number 1
@:) Turret: Yes
@:) Mount: Full Traverse
@:) ===

  The only problem I have with this is that you need to use look-ahead
logic to parse it.  Example: I have read in the data in your example.
Now imagine there's another DSIIVehicle: line in the file.  In order
to correctly read in the information, I need to recognize that that
line signifies not only the beginning of a new vehicle description,
but the end of the current description.  So I have to finalize my
parsing of the current vehicle and begin parsing the next one.	This
happens, unfortunately, after I've already read in the first line for
the new vehicle.  Ideally (as far as I'm concerned) the program would
never have to deal with two objects simultaneously - putting braces
around things allows this since a closing brace can always be matched
with its opening brace to figure out whether the description is
finished or not.

  I should point out that A) I don't do this for a living, and B) I
have something of an object-oriented perspective on these matters,
since the only FT parser I've written was OO.  So the idea there was
that I could have objects read themselves out of a file.  This scheme
gets tricky when the object has to prime the pump for the next object
(about which it should know nothing).

  That might be a more complicated way of going about things than is
necessary.  Actually, other than the delimiters marking the beginning
and ending of objects, our formats are quite similar.

-joachim