From: Stefan S. <se...@sy...> - 2004-06-17 02:03:57
|
Grzegorz Jakacki wrote: > Hi Stefan, > > Stefan Seefeld wrote: > >> you make some good points. However, your arguments all gravitate >> around some requirements which I'm not sure I agree with. (That >> was the reason for my 'future directions' thread, so I could better >> appreciate user requirements to base my judgement on) >> I'm not sure the API enhancement I'v been suggesting would be >> one-among-many. In my mind such a typed AST simply reflects the >> C++ language, so there isn't that much freedom to choose. > I don't think that the language itself detemines the canonical AST > architecture. ok. >> The API should allow the definition >> of such extensions, but they remain extensions on a single (high-level) >> API, instead of being just another API. > > > That's my target too. In particular I would like to let clients > *nonintrusively* extend OpenC++ frontend library so that they can > > * obtain API that presents e.g. ternary '+', or > * API that hides parentheses in expressions, or these two seem to me to be just a special *view* on the AST, but not the AST itself. Read: For this I wouldn't provide a different AST, but rather a tool to filter the unwanted tokens or generally to present the same data in different ways. Anyways, I'm sure we agree on this as the highlevel Node<> API you are suggesting is nothing but a high-level view on the Ptree, too... > * API that has an extra construct (e.g. 'metaclass ID' declaration) that > I can typesafely insert into AST obtained from the parser. that one is different since this really requires the parser (ptree factory) to be aware of the extension. It's thus more difficult to achieve this type of extensibility (but the OpenC++ parser already has hooks for this). >> Ok, but even if we go for wrapper instead of subclasses, >> I don't see any reason not to use the C++ type system, i.e. I'd still >> suggest 'Statement', 'Expression', etc. to form a type system, > > > I assume you meant "type hierarchy". right >> instead >> of having Node be a template type. > > > I don't get it. Are you talking about (a) Statement and Expression being > wrappers around Ptree* or about (b) putting more type info into Ptree > hierarchy? that's exactly the question. If we use wrappers we don't touch Ptree, i.e. we don't add type info into the Ptree hierarchy, but instead build another hierarchy on top of the Ptree. > If (a), than I fail to understand how this should work --- Statement > and Expression would be polymorphic, so how can they work as wrappers? > What copy semantics do you want for them? Will Expression be a concrete > base class??? This link describes the ctool API (the C parser backend synopsis provides now): http://synopsis.fresco.org/docs/Manual/ctool/index.html Have a look into the 'Inheritance Graph'. That's about the AST hierarchy I have in mind (with the required additions to cover C++, of course). Expression is indeed an abstract base class, And as such it can't simply be copied, at least not on the stack. Thus, when I'm talking about 'wrappers', I'm not talking about temporary objects, but a superstructure on top of the parse tree. > If (b), then I sustain my argument that this is a viable solution, > but it requires lots of *revolutionary* changes in parser, elaborator > and translator. Hmm, I'd like to get a better understanding of what 'lots of revolutionary changes' actually means. For one, the Ptree type hierarchy already seems quite complete. It just doesn't provide a high-level API to access the structure without using Cdr() and Car(). Thus, adding a high-level API to the existing classes wouldn't be intrusive at all. The thing that would really need to be changed is the Walker interface. But isn't that a good thing ? Making Walker a true Visitor would be beneficial to everybody (there, too, I don't yet fully understand the ramifications, i.e. whether the required changes would have to be applied in one shot or whether we could do it incrementally). > This is a recurring point and I suppose that this is the source of > misunderstanding. It seems to me that you believe that Node<> solution > requires constructing another in-memory tree atop Ptree tree. This is > not true. Yes, see above. For Node<> to be able to live on the stack, it needs to be non-polymorphic, i.e. it can't use the C++ type system directly. Thus it requires an IMO ugly mechanism to dispatch methods based on the dynamic type of one of its members. Again, what I find confusing is that the high-level type hierarchy is part of the Ptree, but not the high-level API. If you suggest to add the high-level API on top, why not the type hierarchy, too ? What good is the current type hierarchy anyways, as there's no associated API to begin with ? Would anything stop working if I took out, say, the 'PTreeWhileStatement' class ? > Perhaps you are looking at Node<> through the existing solution from > Synopsis. With Node<> API *no* AST is *built*. See the code example that > I posted --- the only tree in memory is Ptree tree. yes, I noticed the difference. I just don't understand the rationale for this, see above. ... I'm sorry if this thread sounds confusing and doesn't seem to lead anywhere. At this point it just reflects my lack of understanding of the current design (i.e. either the presence of the PTree class hierarchy or the absence of a corresponding high-level API). Regards, Stefan |