Re: Why put type information into syntax?

Allister Cross wrote:
>
> Does anyone know of any reasons why built-in type names should be
> incorporated in the syntax of a language. I have been looking at the


I can think of two reasons, first, in C and C++ I know, built-in type
names are keywords. By enforcing this rule in the grammar your parser
becomes a lot cleaner. Also, conveniently, by treating them as
keywords you can prevent parse conflicts. Take for example,


  int long (A);


is long a function taking type A and returning an int, or is A an
object of type long int? (Or is long an object of type int direct
initialized with expression A? :)


Furthermore, in C and C++ you can have any number of built-in type
names in the declaration specifier sequence but only one user type
name.


    unsigned long int i;
    A A;


Are valid if A is a type name. This, too, you can encode in the
grammar, making your semantic side easier ...


    # start rule
    start -> decl


    # decl (a very simple declaration)
    decl -> decl-spec-seq IDENT SEMI


    # declaration specifier seq
    # one user type specifier, or
    # sequence of built-in type specifiers, or
    # sequence of built-in type specifiers and other specifiers, or
    # sequence of one user type specifier and other specifiers
    decl-spec-seq -> user-type-spec
    decl-spec-seq -> decl-spec-seq-b
    decl-spec-seq -> decl-spec-seq-c
    decl-spec-seq -> decl-spec-seq-d


    # built-in type specifier (int char signed ...)
    bltn-type-spec -> INT
    bltn-type-spec -> CHAR
    bltn-type-spec -> SIGNED


    # user type specifier (perform semantic type check on reduction)
    user-type-spec -> IDENT


    # other specifiers (const volatile inline static ...)
    other-spec -> CONST
    other-spec -> VOLATILE
    other-spec -> INLINE
    other-spec -> STATIC


    # sequence of other specifiers
    decl-spec-seq-a -> other-spec
    decl-spec-seq-a -> decl-spec-seq-a other-spec


    # sequence of built-in type specifiers
    decl-spec-seq-b -> bltn-type-spec
    decl-spec-seq-b -> decl-spec-seq-b bltn-type-spec


    # sequence of built-in type specifiers and other specifiers
    decl-spec-seq-c -> decl-spec-seq-a bltn-type-spec
    decl-spec-seq-c -> decl-spec-seq-b other-spec
    decl-spec-seq-c -> decl-spec-seq-c bltn-type-spec
    decl-spec-seq-c -> decl-spec-seq-c other-spec


    # sequence of one user type specifier and other specifiers
    decl-spec-seq-d -> decl-spec-seq-a user-type-spec
    decl-spec-seq-d -> user-type-spec other-spec
    decl-spec-seq-d -> decl-spec-seq-d other-spec


By the way, in this grammar, a type name is not a token. The type (in
C++) 'A::B <X>::C <a + b>::D' is not something I want to try to parse
in the lexer!


Mike
michael.prqa@indigo.ie

Return to the comp.compilers page.
Search the comp.compilers archives again.