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

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

On Fri, 17 Sep 2004, Stefan Seefeld wrote:

> Grzegorz Jakacki wrote:
>
> >>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..." ?
>
> not really. More about the signature. The methods take a ptree and return
> one. Why should a generic visitor return something ? As I said, just imagine
> you'd implement a Visitor (Walker) that traverses the ptree to print it.
> Or one that you use to find the type of a given ptree...
> The 'Translate' method is just not sufficiently generic.

I agree.

> >>>* 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.
>
> sounds very complex.

Any specific issues?

> >>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?
>
> yeah, I get your point, but I don't agree about the usefulness of
> a split there. I don't think parser is the right place to hook up
> user code. As I said, Visitors to introspect the generated ptree
> seems to me a much more elegant way.

In general I agree. However, how should parser know if given identifier is
a template (it has to know to resolve 'a < 1 > ( 0 )' ) ? I don't want to
put whole symbol table in parser, to prevent e.g. parser depending on
Class (which would introduce cyclic dependency between, say, Class and
Ptree).

> >>, or you
> >>have to regenerate it in a second pass (aren't we trying to get rid of
> >>the second pass ?).

What do you mean by "second pass" exactly? What is the first pass then? My
impression was that the first pass is parsing, second pass is anything
that goes after that. If so, then I kind of don't understand if you are
aiming and minimizing or maximizing 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.
>
> As I said, I don't see Encoding as 'one particular' representation. It's
> OpenC++'s  internal representation. clients can certainly hook up their
> own with it.

The whole point of my effort is to make different parts of OpenC++
reusable in separation. Encoding is a class with operations specific to
its semantics, which is representing a type. This is not a generic data,
this is data specific to one of the parser clients. I am thinking of the
parser reusable also outside of the context of OpenC++ and Synopsis.

> >>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"?
>
> well, you want to be able to hook up callbacks for individual ParseSomething methods,
> i.e. you require the Parser to collaborate with AbstractParserClient so you can
> implement it in the client.
> I stand to what I said earlier: I believe you can get the same flexibility by running
> a client visitor over the generated ptree and keep the parser as simple as it is now.

That would be great. If you know how can parser resolve templates in such
set-up, I am all for it.

> > Besides that, Parser is "rich" only because all parsing functions are there.
> > It hardly provides any other functionality.
>
> right, and that's quite enough.

I think not, because of templates resolution. I would be glad to be proved
wrong on that.

[...]
> >>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.
>
> right. I suggest to use the Visitor to glue client-side functionality to the
> ptree. The Parser class should not be 'public' to clients. It should be
> considered as a 'ptree factory' without much customizability. (client keywords
> may be an exception, because there's no way around this.)

What is "ptree factory"? I view a parser as a black-box that gets:

  * a generator of token (Lex interface),
  * a facility to report errors (ErrorLog interface),

and outputs:

  * a Ptree (as a return value of a member function),
  * errors (as a sequence of calls to member functions of ErrorLog object).

This is how it works today. In such form it is usable for external
clients. I don't understand what you mean by "not 'public' for clients".
Could you explain?

> > 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)?
>
> I don't think it's important, I just consider the possibility. If everybody
> is happy with a python interface I'm quite happy.

I see.

> >>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?
>
> The Encoding ? Definitely not. The client data you store in (client side) tables
> for which encodings act as keys ? Definitely yes.

Sorry, but I don't buy it. Have a look at the list of methods of Encoding
class. Parser should not be concerned about types, while Encoding is all
about types.

> [...]
>
> >>>>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?
>
> sorry for the misunderstanding. I obviously didn't express myself clearly.
> I didn't mean to hurt anybody's feelings with my description of the situation.
> Sorry. Let me try to rephrase:
>
> The COPYING file doesn't contain a single license (something I thought you
> referred to as the 'OpenC++ license'). Instead, it contains five licenses
> (sections starting with 'Permission to use, copy, ...'). Now please try to
> view this from a lawyer's perspective who needs to assess the risks associated
> with the use and distribution of this package. (Yes, I'v had to deal with
> IP lawyers in various occasions, and I found it to be easiest when I could
> *name* the license and show how it was already used elsewhere.)
>
> In this sense I do believe the current situation is a mess. License proliferation
> is a Bad Thing !

I agree, but OpenC++ license is not just something that can be changed at
will, at once and just by myself.

> Anyways, I really want to avoid this to become a long thread, these topics
> are being discussed elsewhere to death. Suffice it to say that I did choose
> the LGPL for the reasons I outlined, notably what I consider to be developer
> and end-user freedom. I'm not forcing this on anybody, but whoever wants to
> use my code obviously has to comply with it (or else the license would be
> meaningless).

As a copyright holder you have the right to relicense under another
licenses if the license does not forbid it. You also have the right to
give the user choice of licensing terms from two (or more) licenses.

My question was if you would agree to contribute the Synopsis code that
you hold copyrights on to OpenC++ project under terms described in
opencxx/COPYING. (Especially that LGPL puts more restrictions on
redistribution than opencxx/COPYING.)

Let me research the possibilities of converting OpenC++ to some well-known
license and get back to this subject late next week.

BR
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. #
##################################################################