Re: [Opencxx-users] OpenC++ Core Lib -- prototype

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

Grzegorz Jakacki wrote:

> Yes with exceptions:
> 
> * ptree has to know about AbstractWalker (Visitor pattern)

No :-)
Yes, we need a Visitor, but this Visitor can be very minimal. Have a look
into my code: Walker with all its 'Translate' methods is just an implementation
of the Visitor.
Your AbstractWalker's 'Translate' methods are not nearly as neutral and generic
as my Visitor's 'visit' methods. Just imagine you wanted to implement a ptree
serializer with it...

> * putting encoding in ptree is in my view wrong, because ptree should
>   not be concerned with how the higher levels represent types

I don't quite understand what you have in mind. Do you suggest to remove
the PtreeDeclarator's 'name' and 'type' attributes ? I don't think that
would be a good idea, as the parser is the best place to generate the
encoding, so if you don't store it inside the ptree you either have to
store it elsewhere (but still build it from within the parser), or you
have to regenerate it in a second pass (aren't we trying to get rid of
the second pass ?).

> I think parser/ptree should not know about Class. However, parser should
> provide callbacks, so that the higher levels can construct semantic
> objects, if they wish (and how they wish, and whatever objects they wish).

hmm, the parser is a *very* rich class, so adding callbacks there appears
to me to be quite heavy.

> I see callbacks implemented as calls to members of some interface class.
> Clients of parser can provide implementation of this class and register it
> with parser.

I believe this kind of flexibility is best provided by ptree visitors.

>>Where do you draw the line between 'core' and 'high
>>level' ?
> 
> 
> I can see several modules of the Core:
> 
> (1) elaboration (Class, Member, TypeInfo, Encoding, concrete walkers)
> 
> (2) Ptree hierarchy, abstract walkers
> 
> (3) parser
> 
> (4) Lexer
> 
> (5) Program/Buffer
> 
>       ,------------------->|ptree|----------.
>       |             ,----->|     |          |
>       |             |                       v
> |elaboration |--> |parser| --> |lexer| --> program/buffer
> 
> 
> Class above is in fact only part of the original Class, with all things
> petraining to reflexivity and source-to-source translation ripped out
> (e.g. all Translate... functions, statics such as SetDefaultMetaclass()
> etc.).

interesting idea. Wouldn't a 'Class' type that is stripped down as you suggest
be a good candidate for the AST API as we discussed some months ago ?
In other words, couldn't that be the basis for the second layer on top
of the PTree API ?

> And that's it for Core.
> 
> On top of that goes "Greater OpenC++", ie. classes that constitute the
> reflexivity model (things ripped out from the class above). These are the

now I'm a little confused again. What do you refer to as 'reflexivity' ?
If I strip off the 'Translate' methods, i.e. all the generating methods,
I'm still left with accessors that I would call 'reflexive'.

> classes that should be visible to the end-user of Greater OpenC++ after
> including "mop.h", all stuff related to user-defined metaclasses etc.

metaclasses are concerned about code generation, not strictly reflection,
right ? So high level reflection (AST) would be the layer on top of PTree
which would be the basis for metaclasses and code generation.

> Yet on top of that goes simple driver, which is an executable that reads
> preprocessed source from stdin and writes translated source to stdout.

yep.

> And on very top of that goes full-blown driver, that calls preprocessor,
> linker, compiler etc.

yep.

And at each of these levels we could offer both an C++ as well as a python
API, so users can choose the API that fits there needs.

>> >>'Encoding' is a 'passive' data holder (similar to std::string). In this
>> >>role I placed it into PTree nodes, to make them more type safe.
>> >
>> >
>> >Personally I don't like it, because it forces clients data structure on
>> >parser library.
>>
>>not in my case, where 'Encoding' has become part of the 'parser library'.
> 
> 
> In my view yes, because parser should not care how its client represent
> something (types). IMHO parser should provide means for clients to store

I wouldn't call 'Encoding' a 'representation'. It's very minimal and
just enough to identify types and look them up. They can then be used as
keys into a user provided table to store 'client data', though.

>>what is the 'OpenC++ license' ?
> 
> 
> See file COPYING.

that file doesn't contain a license, nor a copyright. It contains
a bunch of different licenses. That's precisely why I suggested
some months ago to reconsider this issue: it's quite a mess, and
you'll have a hard time to convince any layer about what this 'OpenC++
license' is all about. If, in contrast, you choose a well known
license, lawyers may already know them. At least there exist various
text explaining the issues, so it's much more easy.

>>How is it different from LPGL ?
> 
> 
> Does not require redistribution of linkable binary code.

right, that much I understand. Why is that a problem ? IMO it just
improves the rights of end-users: they have free access to OpenC++
even if used inside a proprietary program.

>>What makes you not want to use LGPL ?
> 
> 
> (1) LGPL is more restrictive than OpenC++ license.

It doesn't restrict *my* right as a developer at all.
It gives more freedom to the developer and the end-user.
But well, I don't want this to become a license flame war, so
let's just agree to disagree then.

> (2) Part of OpenC++ license is a license from Xerox. I am not sure if
>     and how should we distribute files under mixed license (LGPL + Xerox)
>     and what implications it has.

while I don't see any problem with the current distribution modus, I'm
working to replace all the code that Xerox has a copyright on. If you
look into the synopsis repository you'll notice that two of the main offenders
are already gone (the 'Program' and the 'Lexer' are rewritten from scratch).

Regards,
		Stefan