[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

[Stefan R. <sr...@ma...>]

Hello,

On Thu, Mar 13, 2003 at 01:52:52PM +0800, Grzegorz Jakacki wrote:
> This is very important, as this allows somebody who is not a guru to come
> and commit some fixes without fear that he/she breaks some distant parts
> of the package. Our testsuite is pathetically small at the moment, but
> it already helps and I believe that it can grow.

I think, there are two problems, at least with the parser. The
interface consists of two parts, namely the Ptree descendants
and their contents.

1) Every Ptree descendant has a method "Translate" which calls
   a method of Walker. Adding a new Ptree class means adding a
   method to Walker. User code must override that method, or
   they'll (accidentially, maybe) run into the default behaviour
   which just recurses into the subtrees. This problem can be
   solved with an abstract base class, so people who want to be
   paranoid can derive from that. Their code will automatically
   fail to compile when we add a new node type, which is a Good
   Thing(tm), IMHO.

   So far, everything nice.

2) The bigger problem is with the content of the nodes. For
   example, the new wide-char constants turn into Leafs. Old
   programs might assume that all Leafs are either numeric, char
   or string literals, and break now. Or, my "if(decl)" patch[1]
   would add the new property that the third child of "if" can
   be a declaration instead of an expression. I don't see a good
   solution for that problem. Okay, one could go away from the
   Lispy data structure towards a more "explicit" syntax, i.e.
     class PtreeIfStatement {
       Ptree *if_keyword, *left_paren, *right_paren;
       PtreeExpressionOrDeclaration *condition;
       PtreeStatement *controlled_statement;
     };
   but that would need an enormous amount of work and break
   everything. Plus, OpenC++ started as a meta-object protocol
   and not as a parser library, so I'm perfectly happy when it
   fulfills its primary purpose best :-)

[1] Since the CVS code currently can't be built, I'll wait with
checking it in.

> But now comes the problem: when we just extend Frontend itself, without
> proper support in Translator (e.g. your patches will make 'if ({...}) '
> parse, but Translator will choke on it), we do not have way to add tests
> that make sure the new Frontend functionality works.

My 1) is a partial solution. 2) can be solved by very defensive
programming. My code checks every Ptree node it encounters
whether it fits into its imagination. For example, my "if"
handling code starts with (the equivalent of)
   assert(p->First()->Eq("if"));
   assert(p->Second()->Eq('('));
   assert(p->Nth(3)->Eq(')'));
so if someone now adds an "unless" statement which also
generates a PtreeIfStatement ("it's almost the same"), my code
will see that it can't handle it. I think we can't get much
better.

> BTW: Over a year ago there was a resolution on this forum to factor out the
> Driver subsystem and make it a shell script (for easier maintenance
> and to make underlying compiler/preproc/linker settable with Autoconf).

Personally, I don't care whether the driver is in C, Perl, Shell
or Intercal.

What about generating a ".h" file and including that in the
driver? In another project of mine, I have this in "configure.in":
----8<----
define(CREATE1, [AC_OUTPUT_COMMANDS([echo "creating $1..."
cat >conftest.tmp <<_EOF
$2
_EOF
if cmp -s $1 conftest.tmp; then
  echo $1 is unchanged
  rm -f conftest.tmp
else
  rm -f $1
  mv conftest.tmp $1
fi])])dnl

CREATE1(arch/platform.h, [#ifndef PCC_V2_ARCH_PLATFORM_H
#define PCC_V2_ARCH_PLATFORM_H
#define PCC2_SRCDIR "`cd "$srcdir" && pwd`"
#define PCC2_DATADIR "$pdatadir"
#include "arch/unix/platform.h"
#endif
])
----8<----
This creates a file ("arch/platform.h") which contains the
specified code, with shell variables expanded (Disclaimer: I'm
not an Autoconf expert, maybe what I did can be done much
easier).

In addition, setting these variables with options to the driver
is a nice thing to have. Shouldn't be too hard. I'm currently
fiddling around with symlinks in $HOME/bin. Not too great :-P
On the other hand, there's always the option to just translate
the source (-E) and compile manually.


  Stefan