package and type identifiers in classes
# Graydon Hoare (19 years ago)
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.
# zwetan (19 years ago)
On 1/4/07, Graydon Hoare <graydon at mozilla.com> 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
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?
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