Suppose that once in a while you arrive early for lunch at your usual eating place and find that the full menu is on. What do you do? You consider the situation, chew over the relevant facts, and then act appropriately. Mm! It's hot today, so I'll just have a salad or perhapsIt's a long time since breakfast. I'll start with . . . and then have some of that . . .. In designing any sizable LOGO microworld you will frequently find it necessary to replicate this tactic of inspecting the circumstances (testing the water, examining the data) and then proceeding accordingly.
Whatever you may think, that is a tall order, and, in making a start, we would do well to simplify the task initially. We might perhaps reduce the complication (from the programming point of view) by requiring the English forms to be identified using grammatical terminology like [first.person singular past speak] [second.person plural future leave] - this sidesteps the problem of getting the system to figure out what the English forms mean. We could also simplify things by ignoring for the moment the fact that Spanish verbs belong to a range of different groups or classes each of which uses different endings for the same meanings. (So too do various irregular verbs which we could likewise avoid.) But even setting our sights low in this way, translate is still going to need to react differentially to whatever lists we give it as input. If the input contains first.person and and singular and past, then translate should output the base of the appropriate verb with é added to its end. But if the input contains second.person and plural and future then the output should be the base plus -areis. The procedure, in other words, will need the capability to test its input against certain conditions and react differently depending on the result of the tests.
If we take a closer look, we will see that if is a command which accepts either two or three inputs. (In some versions of LOGO, the three input form is distinguished by having a different name, ifelse, but its workings are the same.)
The first input to if is a test. A test is a Logo expression which evaluates to (either is or reduces to) the word "true or the word "false. In other words it is like a question which gets the answer yes or the answer no.
The second input is a list containing instructions - perfectly normal Logo instructions - which are to be followed if the test outputs "true (if the condition is met, if the answer is yes).
The third (optional) input is a list of instructions - again normal Logo instructions - which are to be followed if the test outputs "false (if the condition is not met, if the answer is no).
Abstracting away from any particular content, then, the form of an instruction beginning with if can be schematized as either
if test [what.to.do.if.true]
if test [what.to.do.if.true] [what.to.do.if.false]
If you feel the need to put some content into this, well then if tired? [go.to.bed] [do.some.work] is a perfectly acceptable LOGO instruction (as long as you have defined a test tired? and two procedures, one called go.to.bed, the other do.some.work.
You will probably find it best to look first at form of tests (on the next page) and then more closely at the way in which the flow of control may engineered (and varied) by the use of different if.constructions.