Grant Jacobs wrote:
At 2:27 PM +0100 2/3/03, Frank Heckenbach wrote:
Grant Jacobs wrote:
You want to distinguish known and unknown identifiers in the error messages to make things clearer (?)
unknown identifier `%s'
type name expected, `%s' given
?
Yup. Such a major change, huh ;-) Being pedantic, I'd add 'unknown identifier' after the comma in the second line too:
type name expected, unknown identifier `%s' givenPerhaps I wasn't clear -- the second line is for the case where the identifier is known, but not a type name (but perhaps a variable).
Ah. You could just do variations on the one-liner... e.g.
type name expected, unknown identifier '%s' given type name expected, variable '%s' given type name expected, constant '%s' given
constant name expected, ...
variable name expected, ...
etc. Combinatorial logic :-)
And exponential complexity, as so often in combinatorics.
program Foo; type bar = 1 .. 1;
procedure Baz; const BaR = 64;
type Foo (n: Integer) = record BAR: Integer; case Bar of 1: () end; [...]
error: a variant selector that is a single identifier can be either a tag-type or a discriminant-identifier; however, the given identifier `Bar' is defined, albeit with different capitalization `BAR', as a field of the record being defined which is no discriminant, although the record is a schema type; the identifier is also defined as an ordinal type, with different capitalization `bar', at the global level, which would be suitable for a tag-type, but this type definition is shadowed by a constant definition, with yet another capitalization `BaR', within the current procedure `Baz'. There is also a type definition `bAr' in the file `myunits/foo42.pas', but this unit is not used in this program, so its declarations are not available, and if they were, this one would still be shadowed by the constant definition.
SCNR. ;-)
I mean, sure, the compiler could always tell if the identifier is a constant, variable, etc., perhaps if it has shadowed meanings, and some amount of other information, but how far should we go? (Or rather, who would like to implement it?) Usually, I think, it's enough to know whether the identifier is unknown ...
In your case, the real confusion arose of a different issue (how units work), and I don't think the error message could have really helped here ...
- If a name from the current interface occurs within the parentheses without renaming, this is redundant (maybe should be an error?).
A warning rather than an error since its only redundant?
OK.
Hmm. Good except for that last one, which isn't so hot for what I was after (but I suppose other will debate that!). If you added the ability to name an imported unit rather than its contents in an export statement, it looks like the sort thing I was after.
I thought so.
If people don't want to export unit interfaces (or parts thereof), they can just not do it. I assume unit names and other identifiers can't conflict...?
They can (according EP, module names are in a separate "name space").
Besides, it would be harder to implement than, say, a special form of `uses', since the compiler would have to keep track of which identifier was imported from which unit, so it can do the re-exports properly.
I meant your reference to the docs. `exports' is listed as not yet implemented (which is true), but where does it say that `export' is not yet implemented?
Sorry, you're right; export is listed as '(under construction)' (i.e. no docs for it).
If this is confusing, should it be changed to `(description under construction)' or so?
Sure, but I don't think this addresses my argument. You're right as long as the program doesn't need to check the array's upper bound in case 1 or fool around with things of type Foo in case 2. In either case they'd have to do a 'uses Unit1'.
Or use `High (Bar)' or `type of MyBar.Baz'. ;-)
If it wants to do more with type `Baz' (declare variables of this type etc.), I see nothing wrong in requiring that it actually uses the unit that declares this type ...
Frank