For clarity: ABC#### is the format of the flight number. eg: AAL2123,
CAL2260, FDX1001, etc... Sometimes, there are three digit flights like
BAA418, etc...
I like the way you have the parser call a function to isolate each
component. I have until this point been thinking in terms of... (pseudo-code
alert!)
IF " c " INSTR(cmd$) then it's a clearance
and
is rightmost character x?Set expedited flag. if not,
a$ = (right 3 characters of cmd$) (eg: "030" or " 10") (*note to self - this
won't work for single digit altitudes - doh!*)
check it makes a number
is it a 3-digit number? (including 020 or 000) - it's a heading
otherwise, it's an altitude.
The other way I thought of doing it was parsing a character at a time and
using the spaces as "EOFs" for each field.
I am aware the decision tree for this "language" is straightforward.
However, to me, it's not "trivial" if only because I haven't coded at this
level in many years and this is truly stretching my mental muscles - which
is why I am doing this ;)
This is wonderful exercise. Thanks!
Dave
On Sun, Feb 6, 2011 at 4:53 AM, Tobias Fröschle <
tobias.froesc...@t-online.de> wrote:
> Dave,
>
> ABC#### C NN - 2 digits is an altitude in thousands of feet
>> ABC#### C NN X - the X modifier expedites the altitude change (where
>> possible/reasonable)
>> ABC#### C NNN - 3 digits is a heading in degrees
>> ABC#### C NNN L (or R) - where a course change follows the shortest turn,
>> L
>> or R modifier makes the turn direction explicit
>> ABC#### C $$$ - where a valid beacon is given, the aircraft will fly to
>> that
>> beacon
>> ABC#### S NNN - change speed to...
>> ABC#### L XXX - cleared to land on runway XXX (eg: 14L)
>> ABC#### T - clearance to take off (an altitude must be set first
>>
> How would you handle more than one command per plane? (I.e. "Climb to xxx
> and turn left to yyy")
>
> Your examples are not clear to me: I guesst the "ABC" part is some sort of
> plane identification? A flight #?
>
> A typical approach in any language would be a function that breaks a line
> into syntactical pieces ("tokens") and returning the next token (here:
> anything separated by white space) from the input line as a string. Outside
> that, you'd have a lexical analyzer that checks whether the token you just
> got matches anything you'd expect.
>
> Your second line example would be handled lke:
> "InitParser("ABC#### C N X)
> x$ = getNextToken () - would return "ABC####", your analyzer checks whether
> this is a valid flight #
> the next "x$=getNextToken()" would return "C", you accept this because it
> is valid here
> the next "x$=getNextToken()" would return the new altitude - Your analyzer
> checks for valid numerical value
> the next "x$=getNextToken()" would return the "X" and
> the next one an empty string to signal to the analyzer that you're done
> with this line.
>
> obviously, the getNextToken function would need some non-local variables to
> keep track of where in the input line it currently is
> Those would need to be initialized along with the input line in initParesr
> for each new command line.
>
> The analyzer would be programmed as "finite state machine" that holds a
> non-local variable on "where I am currently" - i.e a state value that tells
> tehe analyzer what to expect next.
>
> Hope this helps
> Tobias
> _______________________________________________
> QL-Users Mailing List
> http://www.q-v-d.demon.co.uk/smsqe.htm
>
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
