opencxx-users

Re: [Opencxx-users] future directions

[SF M. E. <el...@us...>]

...
> This leads me to a couple of items on my wishlist, which I'd like
> to discuss / propose here:
> 
> * I suggest the ptree hierarchy to be refactored into a more typed
>    form. That could simply mean that a big number of new 'Statement',
>    'Expression', and other classes should be derived from 'Ptree', or
>    it could be done in a different way, I don't know yet.
>    However, this would mean that it would be much more straight forward
>    to inspect an AST, as these types would be more or less self-explanatory
>    (ever wondered what 'node->Cdr()->Cdr()->Car()' represents ??)
> 
> * I suggest to open up opencxx in a way that exposes the basic API
>    (parser / ptree generation, walkers / ptree transformation, metaclass and
>    the other introspection stuff) as a C++ library as well as a python module.
>    This means that the occ executable will be very much obsolete, or at least
>    it would only be a convenience for the most popular features, but more fine-grained
>    control would be accessible through the APIs, through which users can customize
>    opencxx to their needs. It also means that all the platform-specific code
>    to run subprocesses such as the preprocessor as well as load metaclass plugins
>    could be isolated such that the backend library would be more platform neutral and robust.
...

I would like to contribute some ideas to this discussion thread.

I tried to introduce the topic "C++ management extension".
http://sourceforge.net/mailarchive/message.php?msg_id=7576532

There are more approaches possible:
C++ source code can be mapped to XML. Superx++ comes near to such a solution.
http://en.wikipedia.org/wiki/Superx_Plus_Plus_programming_language

An object-oriented mapping between the sources and the MOP transformation can be used like it is decscribed in the section "1.1.4 Inheritance vs. Flattened Views of the API".
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1CED5498
- A node interface is available for OpenC++ at the moment.
- Higher level abstractions and corresponding classes seem to be missing so far. How do you think to define them with the CORBA interface definition language like it is specified for HTML?
http://www.w3.org/TR/DOM-Level-2-HTML/idl-definitions.html

Re: [Opencxx-users] future directions

[SF M. E. <el...@us...>]

> > C++ source code can be mapped to XML. Superx++ comes near to such a solution.
> > http://en.wikipedia.org/wiki/Superx_Plus_Plus_programming_language
> 
> Having just had little exposure to this, I fail to see the use of this mapping.
> Could you provide some rational for such a binding ? In particular, what's the
> relationship to introspection and metaprogramming ?

If C++ code would be mapped to XML text, the existing infrastructure like XSLT, XQuery and document object model can be used to transform the sources.
The mapping between DOM and IDL would be easier, too.

Examples:
- What should the interface for a constructor be?
- How do you design the IDL specification for a method or member function call?

Re: [Opencxx-users] future directions

[SF M. E. <el...@us...>]

> > (5) At this point we will have usable, type-safe interface.
> >     Moreover, clients not satisfied with this interface
> >     (e.g. those who prefer multiary "+") will have a chance
> >     to reuse it nonintrusively or just write another
> >     interface to Ptree structure from scratch.
> 
> That is a good point ! The generated tree could be visited in terms
> of ptree, *as well* as a typed syntax tree. A little like the other
> poster referring to the different DOM APIs...

Several internet browsers and other tools can process XML trees by the document object model.
Should their implementations be adjusted and reused for OpenC++ purposes?
How much do they have in common with "Ptrees"?

Re: [Opencxx-users] future directions

[Stefan S. <se...@sy...>]

SF Markus Elfring wrote:
> Several internet browsers and other tools can process XML trees by the document object model.
> Should their implementations be adjusted and reused for OpenC++ purposes?
> How much do they have in common with "Ptrees"?

besides being a 'tree object model' they don't have anything in common.
I don't believe that XML will help us much in this context, it's just
another syntax to express trees. Semantics have to be added on top.
It has its value, but not here. (you may be interested into this on-spot
and entertaining article: http://www.venge.net/graydon/markup-abuse.html)

In what way do you think 'internet browsers' would help us ? I guess you are
referring to the ability of modern browsers to display xml directly. Well,
I provide a synopsis formatter that dumps the (synopsis) AST as an XML tree.
But that's merely a debugging / validation aid. It's not meant to be used
in the work-flow directly.

Regards,
		Stefan

Re: [Opencxx-users] future directions

[SF M. E. <el...@us...>]

> besides being a 'tree object model' they don't have anything in common.

I mean that this is enough to generalize the node interfaces.


> I don't believe that XML will help us much in this context, it's just
> another syntax to express trees.

I agree.
But I see some benefits by using XSLT with its XPath expressions to analyze and process the parse trees by DOM methods.


> Semantics have to be added on top.

I agree.
The meaning and its validation should be done by the proposed API enhancements for the type management.


> It has its value, but not here. (you may be interested into this on-spot
> and entertaining article: http://www.venge.net/graydon/markup-abuse.html)

Nice.   ;-)
I hope that a door can be left open for use cases that do not use only binary processing for C++ source files.


> In what way do you think 'internet browsers' would help us ?

Such software contains function or class libraries for the work with DOM and XSLT that can be adapted to OpenC++.
I suggest to enable "browsing" of Ptrees by those well defined APIs.
http://www.w3.org/TR/DOM-Level-3-Core/introduction.html
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1590626202

Re: [Opencxx-users] future directions

[SF M. E. <el...@us...>]

> ... The generated tree could be visited in terms
> of ptree, *as well* as a typed syntax tree.

How do you think to map a C++ grammar that is defined by EBNF to a detailed class hierarchy?
A lot of specifications from the syntax may be good candidates for different classes. Their interfaces can be designed with OMG IDL.

This top-down approach can meet with the current class library of OpenC++ somewhere in the middle.

Re: [Opencxx-users] future directions

[SF M. E. <el...@us...>]

> In what way do you think 'internet browsers' would help us ? I guess you are
> referring to the ability of modern browsers to display xml directly.

Please look at the page "http://www.gccxml.org/". It shows more use cases.

Can the material on the following sites be useful for improvement of OpenC++?
1. http://www.cs.utexas.edu/users/lavender/courses/c++/
2. http://www.antlr.org/
3. http://codeworker.free.fr/

Re: [Opencxx-users] future directions

[Grzegorz J. <ja...@ac...>]

Stefan Seefeld wrote:
> Hi Grzegorz,
> 
> Grzegorz Jakacki wrote:
> 
>> You restrict yourself to modelling IsA by derived-to-base conversion.
> 
> 
> I try to avoid having to define and implement my own type system.
> C++ already provides one for us, so why not delegate all the related
> work to the C++ runtime (RTTI) and the compiler ?

If I were to write OpenC++ from scratch I would not revert to such
tricks. The value I see is that wrappers are the shortest path to
type-safe OpenC++ API:

(1) Implementing wrappers does not require any changes in existing
parser, type elaborator or translator.

(2) Wrappers can be later introduced into Parser one by one. You can
make one function use wrapped nodes, while leaving others using raw Ptrees.

(3) This solution does not commit OpenC++ to any particular high-level
interface.

> 
> I'm not (yet) convinced that the limitations of such an approach
> outwight the advantages.
> 
> 
>> struct PtreeBinaryOp : public NonLeaf
>> {
>>     PtreeBinaryOp(Ptree* l, Ptree* r) : NonLeaf(l, r) {}
>> };
> 
> 
> Why isn't the 'BinaryOp' part of the high level API ? 

It could be. My point was to demonstrate that high-level API can present
different structure than low-level API. For example I prefere to have
productions "plus", "minus", "times" etc. in the grammar exposed by API,
not just "binaryOp" (of course this is subjective and depends strongly
on how I want to use the API).

> If it was,
> it could have three members to directly access the operator as well
> as left and right operands:

Yes. (But you loose type safety, e.g. your client is not protected from
creating a node that has e.g. "#" or whatever as an operator.)

> struct BinaryOperator : public NonLeaf
> {
>   //. add appropriate constructor(s)
>   const Ptree *get_operator() const; // instead of 'const Ptree' this 
> could return a typed subclass
>   Expression *left();
>   Expression *right();
> };

Modulo my previous comment, this is the easiest point in this
discussion. I fully support adding accessors to existing Ptree
subclasses. No harm, much good.

> 
> by the way: if this returns a Ptree, it has to be const, so users can't 
> modify it to become
> something other than a binary operator. 

This is a limitation of your proposal, that high-level API does not
have. My point is to keep low-level API low-level (where users have to
look out) and provide safe high-level wrapper API (where type system
guarantees this kind of correctness).

It is also not obvious if returning pointer to const does the trick,
since it depends on how you define Ptree accessors (AFAIU there are two
semantics: "smart pointer" where constness of the pointer is orthogonal
to the constness of the pointee and "handle" where constness of a handle
is equivalent to the constness of handlee).

> As Expressions would hide the
> un(type)safe Ptree API,
> they don't need to be const, i.e. users can modify them as long as it 
> remains an Expression.

I think I don't get it.

>> // Fourth part of high-level API is a dispatcher --
>> // a mechanism that lets you find out more detailed
>> // type information about node (e.g. you pass
>> // Node<Expr>, and dispatcher calls, say,
>> // v.Visit(Node<Plus>), if your Node<Expr> was indeed
>> // a plus expression).
> 
> 
> yes, I think this is the central point we are disagreeing on: if we 
> don't use the C++
> type system, we have to build our own. That's quite heavy and I don't 
> see any advantage
> in such an approach.

(0) The code identifying a node based on a raw Ptere* and context
     must be put somewhere. Why not in Dispatcher()?

(1) This solution is non-intrusive, i.e. can be implemented without in
     fact
     touching existing parser, type evaluator and backend
     (I don't say they don't need touching; I just see it is a huge
     work, much more than writting the wrappers; moreover, once
     we have wrappers, we can move them to parser piece by piece;
     after we replace everything in parser, we will be free
     to replace wrappers with standard implementation of Composite
     (honest, polymorphic hierarchy, modeling IsA with inheritance;
     e.g. AstIf* derived from AstStatement* instead of Node<If>
     convertible to Node<Statement> etc.);
     I am not sure if the last step will be useful, however it
     will is perfetly viable; observe also, that it will be difficult
     to move parser to standard implementation of Composite
     in an evolutionary manner --- either you plant new Composite
     hierarchy everywhere or nowhere)

(2) This solution is open. It does not commit the parser proper
     to any specific API. Raw parser exports low-level API; on top of
     that one can use supplied high-level API. If this API is not
     what the clients want, they are free to use low-level API to
     implement a new one (or extend this one), so that they have
     e.g. multiary plus, or whole instructions as terminals.

To recap: the one point where I see closure now is that we both agree
that adding accessors for existing Ptree subclasses is beneficial.


Best regards
Grzegorz

Re: [Opencxx-users] future directions

[Stefan S. <se...@sy...>]

SF Markus Elfring wrote:

> C++ source code can be mapped to XML. Superx++ comes near to such a solution.
> http://en.wikipedia.org/wiki/Superx_Plus_Plus_programming_language

Having just had little exposure to this, I fail to see the use of this mapping.
Could you provide some rational for such a binding ? In particular, what's the
relationship to introspection and metaprogramming ?

> An object-oriented mapping between the sources and the MOP transformation can be used like it is decscribed in the section "1.1.4 Inheritance vs. Flattened Views of the API".
> http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1CED5498
> - A node interface is available for OpenC++ at the moment.
> - Higher level abstractions and corresponding classes seem to be missing so far. How do you think to define them with the CORBA interface definition language like it is specified for HTML?
> http://www.w3.org/TR/DOM-Level-2-HTML/idl-definitions.html

yes, that sounds like what I'v been proposing, i.e. deriving more typed
classes from 'Ptree' with a more high-level API to access the AST structure.
As such an undertaking involves quite a bit of work, I encourage everybody
to get involved.

Regards,
		Stefan