Re: OOD in Ada?

[tmoran@acm.org]

> deriving some sort of syntax elements from a base class or not. What do
> you mean by: "use the Ada type system to encode particular syntax rules"?
   I presume the OP wants to have things along the line of

     type Adding_Operator is tagged record ...
       Op_Char : character;
     end record;
     type Simple_Expression is tagged record
       Left : Access_Simple_Expression;
       Add_Op : Access Adding_Operator;
       Right  : Access_Term;
     end record;

etc. and the problem is this can't be broken into one class = one package
because of mutual references.
  The alternative under discussion has

     type Non_Terminal is abstract tagged null record;
     type Access_Non_Terminal is access all Non_Terminal'class;

     type Simple_Expression is new Non_Terminal with record
       Components : List_Of_Non_Terminals;
     end record;

and so forth, and there's no problem with separate packages because
everything refers back to the base class Non_Terminal.  In the OP's
scenario, the compiler will catch, as a type mismatch, an attempt to set
The_Simple_Expression.Right := Access_Adding_Operator;
In the alternative, the compiler won't know that
The_Simple_Expression.Components(3) := Adding_Operator'access
is a mistake and thus the compiler can't warn you.

  It seems to me that the type system of a program should be rather basic
and one should at least hope there are no, or minimal, changes during
development.  The particular BNF for a language, in my experience, may
however be modified quite late in the game.  You may actually want to
modify the language you are parsing, or, more commonly, you want to
relabel and shuffle around some things so that certain productions are
recognized, and call semantic routines, at slightly different points.
For instance, you might want to change

  simple_expression : term       {process_term($1);}
    | simple_expression adding_operator term  {add_expr($1,$2,$3);}
to
  simple_expression : term       {calculate_term($1);}
      | first_part term          {apply_op_to($2);}
  first_part :  simple_expression adding_operator {push_then_note_op($2);}

  The more closely the BNF is mapped to the types, the more any simple
change to the BNF will require changes to the types.  Worse, if the types
are one-one mapped to packages, even the package structure of the program
must change.  The likelihood of such changes late in development seems to
me a very bad idea.

  In the Access_Non_Terminal version you do indeed lose compiler type
checking.  But in this sort of app, the parser is supposed to be
guaranteeing that only legitimate things get stored, eg, the parser
should disallow "2 + -" and thus the semantic routine add_expr will
never be called with its third parameter an adding operator.
So giving up type checking is not much of a loss.