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.