Re: Testing strategy for compiler

On 21/06/10 22:16, George Neuner wrote:
> In Pascal it's also illegal to write
> FOR<var> :=<start> TO<finish> where start> finish
[...]
> [... Some] Modula 2, Modula 3, Oberon 2[*] -
> [...] compilers required the step be specified to
> count backwards rather than inferring it from start and finish. Most
> of the compilers I've tried will warn if they can determine statically
> that the sign of the step doesn't match the direction implied by start
> and finish.


This is the sort of thing that would drive me *scranny* if I
were ever forced to use these languages/compilers. You have some
items to process in order, so you write


FOR n := 1 TO nitems DO processitem (n) DONE


What could be more natural? In sensible languages, that works whether
"nitems" is 1, 100, 100000, ... or 0. If you want better control over
possible values of "nitems", then you associate that control with the
declaration of and assignments to "nitems", not with uses of it.


I don't want to have to test that "nitems >= 1" every time I use
it, even less do I want compilers inferring that I want to process items
1 and 0 [in that order!] when there aren't any; nor do I want compilers
warning me that the number of items is zero at this point in the program
[exc perhaps in some debugging mode].
--
Andy Walker
Nottingham
[You wouldn't like Fortran, in which the compiler is allowed to put the
test at the bottom of a DO loop and always run the loop at least once. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.