Menu
▾
▴
Re: [Opencxx-users] OpenC++ Core Lib -- prototype
|
From: Grzegorz J. <ja...@he...> - 2004-09-16 04:52:15
|
On Wed, 15 Sep 2004, Stefan Seefeld wrote:
> 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...
I don't get your point. AbstractWalker is deprived of any implementaion.
Are you refering to the fact that its method are called "Translate..." not
"Visit..." ?
> > * 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,
Why?
Parsing is the best time to generate them. But parser is not the best
place to generate them. Let the higher layer hook up to parser and
generate whatever encodings it likes.
> 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)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why?
> , or you
> have to regenerate it in a second pass (aren't we trying to get rid of
> the second pass ?).
It does not matter when they are generated. My point is that dependence of
parser on one particular encoding used by one particular client is
improper.
> > 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.
Look at this design:
+----------------+ |
| Parser | |
+----------------+ +------------------------------+ |
| ParseFoo... |------>| AbstractParserClient | |
| ParseBar... | +------------------------------+ |
| RegisterClient | | ParsedFunctionHeader(Ptree*) | |
| ... | | ... | ;
+----------------+ +------------------------------+ /
A /
| /
LIBRARY .-------------------------------------'
.---------' |
.-----' CLIENT +--------------------------------+
/ | ParsedFunctionHeader(Ptree* p) |
| \ |
+-------------------\------------+
\
+---
| annotates p node
| with client-specific
| encoding
How does it make Parser class "richer"?
Besides that, Parser is "rich" only because all parsing functions are there.
It hardly provides any other functionality.
My personal view on implementing parsers is that it does not make sense to
lump Parse... methods in one big class. Dependency hell, especially when
parser state is private data and you need to add some helper functions in
parser implementation. My opinion is that is is much better to define parser
state as an object, and have Parse... functions enclosed in namespace. (But
this is just a side-note, I don't think that this refactoring of parser
would benefit the project at the current stage.)
> > 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.
I don't get you again. You said yourself that it is suboptimal to generate
encodings by 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 ?
Maybe. I must give it a thought.
> > 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' ?
Chiba invented some object model of C++ programs, where classes are
instances of a class called 'Metaclass'. This object allows for inspecting
and changing C++ programs. I call this model "reflexive", because it "models
itself", in a sense that Metaclass is treated as one of program's classes
(thus it is an instance of itself).
On the other hand, the interface provided by parser and, in my vision,
elaboration, are slightly different in nature. They provide "introspection",
i.e. means to manipulate an object model of C++ program "from the outside",
not "from the inside".
My point is that reflexivity should be implemented on top of
introspection. In current design those two things are tangled.
> If I strip off the 'Translate' methods, i.e. all the generating methods,
> I'm still left with accessors that I would call 'reflexive'.
This is what I would like to call "introspection".
> > 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 ?
Metaclasses provide both a mechanism for specifying code transformations
*and* mechanism of introspection. I would like to untangle those two things.
Apart of that they have lots of small things related to yet higher levels,
e.g. some parts of an interface of the high-level driver are placed as
statics in Class.
> So high level reflection (AST) would be the layer on top of PTree
> which would be the basis for metaclasses and code generation.
What is "reflection (AST)" ?
> > 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.
As for those two top-level modules, I think that scripting implementation is
the best. Why do you think C++ API is imporant (at this level)?
> >> >>'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.
Is it specific to client or not?
> >>what is the 'OpenC++ license' ?
> >
> >
> > See file COPYING.
>
> that file doesn't contain a license,
Sorry, but this statement is clearly false. (Especially that in the next
para you write, that it contains many licenses.) What do you mean?
> nor a copyright.
Again, what do you mean?
Copyrigh is a right ("the exclusive legal right to reproduce, publish, and
sell the matter and form"), so how can this file contain "copyright" ?
> It contains a bunch of different licenses.
It contains licenses that describe how you are allowed to use the code. What
is your point?
> That's precisely why I suggested
> some months ago to reconsider this issue:
As far as I remember you reaised licensing issue in Nov 2001. I don't
remember you bringing this issue to this forum several months ago. If I am
not mistaken you were discussing it with Chiba around that time, apparently
off-line. I got one or two e-mails from this conversation kindly CC-ed by
Chiba, but, frankly, I don't reacall any discussion in this forum.
> it's quite a mess,
You are using quite derogative term in connection with collective work of
volunteers working on OpenC++. Please do not do this. Pointing out specific
flaws would be more constructive.
> and
> you'll have a hard time to convince any layer about what this 'OpenC++
> license' is all about.
Could you be more specific?
> 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.
Yes, I agree.
> >>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.
It also limits the usage of OpenC++ in proprietary software (much the same
way GPL does, but to smaller extent). If OpenC++ was under LGPL I would have
not been able to use it in my project 3 years ago.
> >>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 can prevent you from using OpenC++ in proprietary software.
> It gives more freedom to the developer and the end-user.
In Stallman's sense, yes.
> 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).
Anyway, I believe that what you are doing is illegal. First of all, your
COPYING file does not include statements required by Xerox's part of
the original OpenC++ license, but you are still using Xerox's files.
Second, even if you phase them out, your work will still be a derivative
work of the original sources, I believe.
The risk for yourself is minimal. The risk for somebody who leverages
Synopsis in a commercial product may be substantial --- if they make a
profitable bussines out of it, Xerox can sue them for damages.
I think it is important to keep licensing issues clean. As for OpenC++
licensing let me try to find legal advice on that issue, as well as learn
more about opinions of this forum.
I hope the licensing issues can be solved, however this will most likely
take some time. Before it happens, maybe we can continue under respective
licensing terms of Synopsis and OpenC++. In particular, it would help if
you could answer the question from my last e-mail, namely would you
relicense your changes to OpenC++ code that are now part of Synopsis, so
that they can be merged into OpenC++ and distributed under terms described
in opencxx/COPYING?
Best regards
Grzegorz
##################################################################
# Grzegorz Jakacki Huada Electronic Design #
# Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074 Beijing 100015, China #
# Copyright (C) 2004 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################
|
