Weird type/identifier conflicts

Frank Heckenbach 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.

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

-- 
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707




More information about the Gpc mailing list