Peter N Lewis wrote:
Obviously, the easiest thing for me would be just to implement the {$unused(b)} directive,
I think this would be quite a bit more difficult, and raises some new questions, since directives are outside of the syntax rules. E.g.:
procedure foo (a: Integer);
{$unused(a)}
procedure bar (a: Integer); begin end;
begin end;
Which `a' is meant here? The outer one? What if you move the directive after the word `procedure', is it the inner one now? If not, it would seem confusing. If so, it would need to reference an identifier before it's declared, also bad ...
Basically I guess since it is accessing the symbol table it would apply to the same thing the compiler currently considered as the "current in scope variable", which would be ambiguous at best everywhere from "procedure" up to the ";" (and possibly one more token.
Exactly, that's the problem. Since the compiler processes things not on a token basis, but in semantic groups, produced by the parser, this uncertainty doesn't arise normally, because there's no place, say before and after the `:' where the compiler would do anything.
For myself (and we could certainly recommend it as the way to go), I generally write the {$unused(a,b,c)} line on the first line after the begin. That ensures the compiler and the parser are pretty much guaranteed to be in sync.
While this is a useful principle from the programmer's point of view, it still doesn't answer the question from the compiler's point of view. IMHO, a feature whose meaning can't even be clearly defined (in any situation) is highly suspicious. (My favourite example are BP's `^X' char constants. Borland's implementation of them only works in some situations, where there are probably most often used, and they simply forgot about other cases, so the resulting syntax of their language is hard to even describe properly ...)
BTW, many of us (including myself) have complained about the convoluted language of the Pascal standards. At least it's to achieve the goal of defining things unambiguously (though IMHO this goal is not necessarily incompatible with better readability -- perhaps by using a little more formalism than writing everything out in long English sentences) ...
Frank