Am 08.09.2010 03:10, schrieb Hans-Peter Diettrich: > Florian Klaempfl schrieb: > >>> I stopped searching after finding such code in aasmtai, aoptbase, >>> aoptobj, assemble, globals, nadd, ncgutil, nld, ogcoff, options, >>> optloop, pdecsub, pmodules, psub, symdef, systems. >> >> Well, I see no problem with it. Of course, one can do an overly complex >> design to avoid this but as I said before, I see no use in doing so. It >> makes only maintainance more complex. > > That's why I suggested solutions other than $IFDEF or virtual methods.
Using ifs is usually not possible because some symbols simply don't existing on certain architectures. > > >>> For logical (functional) grouping. Looking at the parser, a single unit >>> would be sufficient for every front-end. >> >> This is not logical to me. For me it is logical to group the parser by >> expression sub parser, declaration sub parser etc. and even split the >> declaration parser into type etc. one. > > A parser structure should support the maintenance of the language, i.e. > syntax. Well, it should also support the maintaince of the compiler code ;) > In so far I'd group together e.g. directive handling, to ease > the maintenance in case of new directives. Your suggested structure > applies to the semantics of the language, The distinction between e.g. expressions and declarations is completly syntax driven and has nothing to with semantics. > which should be implemented > outside a concrete parser (front-end). It's also a bad idea to move > procedure processing into a different class (tprocinfo), and let it call > paser methods from there. Actually the naming of t(cg)procinfo is probably bad, maybe it should be called now tproccompiler. > That's turning things upside down, breaking > the recommended separation between front-ends and compiler :-( Who recommends this? The writers of books like the dragon books? Those people never wrote a real world compiler and tried to solve the real problems of compiler writing. > > In an OO design the parser methods must reside in one class, so that the > means for further structuring are very limited. That's why I suggested > local subroutines for parsing specific (non-reusable) parts of the > language. > > >>>>> so that finally the compiler could be decomposed into a >>>>> small number of building blocks (packages...), with tiny interfaces to >>>>> each other. >>>> Counter example: your attempt of the OOP parser :) >>> What's wrong with the parser interface in TParser? >> >> That it inherits from TScanner. > > It's only a matter of taste, whether the parser should be a member or > the base of the parser class. Well, you can call a lot a matter of taste then. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel