Weird type/identifier conflicts
frank at g-n-u.de
Tue Mar 4 00:10:54 CET 2003
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' given
> >Perhaps 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.
bar = 1 .. 1;
BaR = 64;
Foo (n: Integer) = record
case Bar of
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.
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?
> 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
They can (according EP, module names are in a separate "name
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
> >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 Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
More information about the Gpc