As was seen in the previous chapter, the "planner" output is surrounded by tags and looks something like this:-
How would this be translated into English?
Perl has a facility called "grep". Much like the Unix facility of the same name, it allows an expression to be applied to every element in an array. It became obvious that this facility would be of enormous help when it came to the translation program. For example, the commands "grep s:<I:to :, @output" and "grep s:I>::, @output" would add the phrase "to " in front of every "I" tag and strip off the tag. Or the command "grep s:<ENE>:heading North, @output" would convert every <ENE> tag to the phrase "heading North". It can be seen that a series of grepped regular expressions would convert the tagged machine-readable information into a set of human-comprehensible commands. This was used as the guts of the "translateintoenglish" program and enabled the translation of the route above into:-
Solecisms like "via crossing the road" could then easily be corrected by another expression. Please note that a full list of expressions for verbose and brusque translations can be found in appendix 8.
That was the clever part. You will note that our output contains things like <D100 metresD>, <IKeble Rd/Banbury Rd cnrI> and so on. These are already English phrases: where did they come from? The answer is that they were held in the same file that held the node and route information and were read in when the "planner" program accessed the file.
Yes. What was done was to split concepts like the "from" node into two parts: their "machine values" and "human values". "Machine values" were inevitably short and numeric (eg N000001) and "human values" were inevitably long, language-specific and contained spaces (eg "Keble Rd/Banbury Rd cnr"). The point to this was that the calculation programs referred only to the "machine values" throughout and never looked at the contents of the "human values" fields other than to include them in the output.
The advantages of this approach are that most of the translation is pre-done before the query is processed (which is much quicker than the alternative), the file will have meaningful contents rather than just a list of numbers, and – perhaps most importantly – the "planner" program becomes human language independent: the same program can be used to calculate the route regardless of whether it’s destined for a Francophone, Anglophone or whatever. This was a classic example of the seventh design principle: separation of concerns. The disadvantage is of course that you’d have to create a different file for (say) Japanese, and another one for French ("la route a Nord qui s’appelle Keble"), and so on. This does involve some data duplication but this disadvantage is outweighed by the speed increase.
Note that a fully worked example is given in appendix 8.