Menu
▾
▴
Re: [Opencxx-users] OpenC++ Core Lib -- prototype
|
From: Grzegorz J. <ja...@he...> - 2004-09-15 09:57:42
|
On Tue, 14 Sep 2004, Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
[...]
> >>As we now agree to redesign the parser such that it does the declarator
> >>recording (Environment...) itself instead of letting it done by a Walker, it
> >>could mean that the Walker could be part of the high level.
> >>Right now it can't because parsing isn't complete (i.e. self-contained)
> >>without ClassWalker.
> >
> >
> >Wait a moment. I don't think it is *that* easy with C++. As I already
> >mentioned here several weeks ago, I don't see a way to perform type
> >elaboration in one pass. This is because
> >
> > The potential scope of a name declared in a class consists not only of
> > the declarative region following the name s declarator, but also of all
> > function bodies, default arguments, and constructor ctor-initializers
> > in that class. [3.6.6p1]
>
> yes, yes, I acknowledge. My wording was poor. I understand that parsing
> can't be a linear sequential process. The design I have a problem with is
> the fact that in the Walker framework multiple things seem to be lumped
> together: on the one hand it appears to operate on the meta object level
> (user keywords), and on the other it seems to participate in the parsing
> (the 'second stage'). Is that not so ?
Yes.
> The construction of scopes (i.e. symbol lookup tables) can be done during
> the parsing, right ?
Yes.
> There is just no reason to do this stuff in the same
> object that looks for user keywords !
Yes.
> Walkers *should* only care about the mop stuff, and thus all the lower level
> classes (ptree, parser, encoding, etc.) should be free of any reference
> to Walkers.
Yes with exceptions:
* ptree has to know about AbstractWalker (Visitor pattern)
* putting encoding in ptree is in my view wrong, because ptree should
not be concerned with how the higher levels represent types
> >Here we just cannot rely just on one pass. It seems to me that a reasonable
> >solution is that parser stores the function bodies, default arguments and
> >ctor-initializers and parses them after the class is parsed. At that
> >time the symbol table can meaningfully answer if a given name represents
> >a template.
>
> yes, sounds good. What I'm not clear about is whether this would involve
> high level types such as 'Class'. Put differently: should 'Class' be part
> of this parse process ?
Yes and no.
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).
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.
> 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.).
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
classes that should be visible to the end-user of Greater OpenC++ after
including "mop.h", all stuff related to user-defined metaclasses etc.
Yet on top of that goes simple driver, which is an executable that reads
preprocessed source from stdin and writes translated source to stdout.
And on very top of that goes full-blown driver, that calls preprocessor,
linker, compiler etc.
> >>It records declarations to the Environments, and these are then necessary
> >>to complete the parsing, no ?
> >
> >
> >I don't think OpenC++ does it now in such manner. AFAIK parser does not use
> >type information to resolve any syntax ambiguities (ie. at template
> >instantiations).
>
> that may answer my question why I don't see any ptree changes between
> before and after the translation. If I understand you right, the translation
> only changes the ptree if there are user keywords ('metaclass' and co.) in
> the
> input, which may be expanded. Can you confirm this ?
Translation changes anything only if you specify nontrivial metaclass for
some class. You can do it by with "metaclass NontrivialMetaclass MyClass;"
declaration in translated source code, or with "SetDefaultMetaclass()"
somewhere in 'compiler' code (most likely in
'NontrivialMetaclass::Initialize()').
> >>'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
something with AST nodes, but the type of stored data should be opaque
to the parser. Yes, it is type unsafe, but it cannot be otherwise without
loss of reusability or without parametrizing all AST with client's storage
type. If clients cares for type safety, it can use AST via wrapper
(normally it is costly, because wrapper is very much sensitive to changes
in AST, but it looks like it can be made cheaper with some templates
tricks.)
> >Putting functions from EncodingUtil into Environment makes sense only if
> >they need private access to Environment. They don't.
>
> hmm, from my point of view a function belongs to a class if it is
> conceptually
> related, not if it needs access to the class' private members.
>
> Things like
> 'GetBaseName' operate on both, Encodings as well as Environments. You could
> argue for both, associating them with Encodings as well as Environments.
> But as since without it Encoding wouldn't depend on Environment, I think it
> is more natural to put it into the Environment...
Putting such functions into class increases coupling. If you modify
private details of implementation, then you have to go through all member
functions, to see if they need to be updated. Making free functions
members adds more work.
Another argument is that member functions that need only public interface
obfuscate the class, because by looking at class definition you assume,
that these functions need to access implementation details, while they
don't.
For more arguments see Herb Sutter "Exceptional C++", Addison-Wesley 2000.
> >If you feel that 4 functions in EncodingUtil namespace does not warrant its
> >existence, then I would suggest putting them in Environment.h (but not as
> >member functions), according to Sutter's "interface principle".
>
> yeah, they may be static.
I did not mean this. I meant to add them as *free* function to
Environment.h. See Sutter.
> [while I think 'principles' reflect 'common sense' and generally accepted
> 'good practice',
> I wouldn't want to be dogmatic enforcing them. They are just principles
> after all...]
See above for arguments why I think my point makes sense.
> >I think that your contributions to original OpenC++ that currently
> >constitute C++ submodule of Synopsis are very valuable and I would be glad
> >to leverage them in OpenC++ Core. As I understand the only changes that
> >were made under LGPL to OpenC++ 2.5.12 under Synopsis are yours, right?
>
> No, they are mine as well as from Stephen Davies (whom I'v lost track of,
> unfortunately).
>
> >If so,
> >would you consider donating them to OpenC++ under OpenC++ license?
>
> what is the 'OpenC++ license' ?
See file COPYING.
> How is it different from LPGL ?
Does not require redistribution of linkable binary code.
> What makes you not want to use LGPL ?
(1) LGPL is more restrictive than OpenC++ license.
(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.
> And, without wanting to get into a flame war, a question to all developers
> on this list:
> Does anybody *not* want the code to be distributed under LGPL ? If so, why ?
Myself. Putting apart the downsides listed above, the only benefit of LGPL
I can see is that it is better known and better tested. However, if I was
to get down to relicensing OpenC++ I would first think about other
licenses (MIT? Boost?). Every such move, however, most likely involves
negotiations with Xerox and I don't think that such time investment will
pay off.
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. #
##################################################################
|
