package and type identifiers in classes

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

package and type identifiers in classes

Graydon Hoare-3
Hi,

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?

-graydon

Reply | Threaded
Open this post in threaded view
|

Re: package and type identifiers in classes

Graydon Hoare-3
Graydon Hoare wrote:
> Hi,
>
> I'm working on the portion of the definition phase that composes
> fixtures for classes now...

Oops, this mail was meant for the committee list; it's a little more
technical than I imagine most of the participants of the public list
care about!

Sorry for the distraction.

-graydon

Reply | Threaded
Open this post in threaded view
|

Re: package and type identifiers in classes

zwetan-3
On 1/4/07, Graydon Hoare <[hidden email]> wrote:
...
>
> Oops, this mail was meant for the committee list; it's a little more
> technical than I imagine most of the participants of the public list
> care about!
>

I personally find that kind of internal details very interesting
even if it's over my head (lack of knowledge, doc and source code :p)

zwetan