If the translator is of the opinion that a specific symbol was omitted or if it expects a specific syntactic construction (identifier; attribute <#8055#>VAR <#8055#>or <#8056#>CONST<#8056#>; unit or declaration ...) it gives an error message to that effect in the lower left corner of the screen and offers the directly surrounding definition for local editing. The cursor is positioned at the place of the supposed error. As an example, suppose the user types as a unit
The translator complains <#8059#>Number of elements ?<#8059#> and offers
The user dutifully inserts <#8062#>10<#8062#> and hits the return key. The translator now complains <#8063#>VAR/CONST ?<#8063#> and offers
The user changes <#8066#>VOR <#8066#>into <#8067#>VAR<#8067#> and hits the return key <#8068#>;SPMlt;RET;SPMgt;<#8068#>, whereupon the translator accepts the rest of the line in silence and waits for the next line. This same incremental correction facility is available for correcting input during reading from a file.
As the Elan Programming Environments does not impose restrictions on the order of the definitions and the user might introduce all kinds of weird operators, like <#8069#>THAN<#8069#>, situations can occur in which the error signalling is not so helpful. For example, if the user types
the Elan Programming Environment will now complain <#8072#>THEN ?<#8072#> and offer
apparently considering <#8075#>THAN <#8075#>to be meant as an operator and so interpreting this construction as
The error reported on the bottom line of the screen should be seen as just a suggestion! It is the best the programming environment can do, but it is up to the user to decide what it was he wanted to express and how to repair the error.