package and type identifiers in classes

Graydon Hoare graydon at
Wed Jan 3 16:20:12 PST 2007


I'm working on the portion of the definition phase that composes 
fixtures for classes now -- committed enough code for simple functions 
to work this morning -- and have run into some confusion. I do not know 
what I might find in the "extends" slot of a class definition. The AST 
permits a full IDENT_EXPR, but this is clearly over-general: several 
forms of IDENT_EXPR are dynamic and cannot be used to describe classes.

When I look at the parser, it appears to think it's parsing only a 
TypeIdentifier, but the Ast.TypeIdentifier constructor has its fields 
marked (* deprecated *) and feeds back into the IDENT_EXPR type in its 
body anyways. Furthermore the production that *makes* 
Ast.TypeIdentifiers -- Parser.typeIdentifier -- has a sub-production 
called simpleTypeIdentifier that uses Token.PackageIdentifier. But Lexer 
never *returns* a Token.PackageIdentifier; as far as I knew package 
identifiers were impossible to differentiate at a lexical level anyways.

I'm a bit lost. I'd like to do something like the following:

   - Make a separate type Ast.TYPE_IDENT like this:

     and TYPE_IDENT =
         TypeIdent of { qual: IDENT list,
                        ident: IDENT,
                        params: IDENT list }

   - Make the parser produce these for the result of the
     typeIdentifier production. Teach the parser to treat "." as
     a qualifier when parsing a TypeIdentifier. Note that there is
     no need for the qualifiers to feed back into TYPE_IDENT since
     we do not permit nesting type names, so the qualifiers must name
     a nesting of packages -- that have simple IDENT names -- not types.

   - Make the fields that previously held an IDENT_EXPR but expected
     it to be limited to a TypeIdentifier just *specify* TYPE_IDENT
     as their field type. I'm thinking "#extends" and "#implements".

   - Purge the Token.PackageIdentifier constructor, since I don't
     think it's possible for the lexer to know when to produce them.

Is this reasonable?


More information about the Es4-discuss mailing list