Re: [Opencxx-users] Makefile.am fixes

[Yann D. <yd...@us...>]

On Thu, Sep 11, 2003 at 09:16:37AM +0800, Grzegorz Jakacki wrote:
> I see. Go ahead and implement it if you think it is important, but to be
> honest I don't think it is a cruicial feature. Implementing it involves
> some maintenance burden (now anybody writting '$libdir' in docs should add
> a link to directories.html to be consistient; and most likely that person
> will not do it, because there is no mechanism or process that would
> require him/her to do so), but we don't change docs often, so I don't see
> a problem. I would encourage you to rather invest your time in
> implementing your ideas about walkers, but if you think 'directories.html'
> is a good thing, go ahead. Provided you get down to walkers afterwards :-)

That's not so much work, so I can do this while we're discussing walker
issues :)


> > > > All of this seems to be easily achieved if we can add hooks to the
> > > > translation of arbitrary language constructs (casts, statements...)
> > >
> > > Right. However after you expand the existing walker you need to have a way
> > > to coerce it back into the old functionality, so that the occ itself and
> > > legacy applications compile. However this seems doable.
> >
> > Hm.  My idea was that without any hooks the behaviour would be the current
> > one.  But it's surely both more flexible and less intrusive to provide my
> > own walker in many cases.
> 
> I think I did not understand what you mean by "adding hooks". Could you
> elaborate on this?

In the case of TranslateCast what I'd have needed would be a call to some
user-defined code within TranslateCast().  AFAICT, since TranslateCast()
calls cannot be tied to a particular class, it could not be done with the
metaclass mechanism.  I originally thought it could probably be done if we
could access from the metaprogram, and derive something like the Program
instance for the file being translated.  But I now realize that it would be
mostly similar, but probably less flexible than deriving the walker, so
let's assume the latter.

In this case, once we're able to use a custom walker, we could add to
TranslateCast() a call to a BeforeTranslateCast(), which the default walker
would implement as a no-op, therefore being non-intrusive.  In the case of
TranslateCast I don't see myself the need for running an additional
translation, but I'll still use this example, since this is a much simpler
method that TranslateFunctionImplementation().  A fully hooked TranslateCast
(simplified by not avoiding useless copies, and probably missing some calls
to ShallowSubst or similar) would give something like:

Ptree* Walker::TranslateCast(Ptree* exp)
{
    Ptree exp2 = BeforeTranslateCast(exp);
    Ptree* e = exp2->Nth(3);
    Ptree* e2 = AfterTranslateCastedExpression(Translate(BeforeTranslateCastedExpression(e)));
    return AfterTranslateCast(new PtreeCastExpr(TranslateCastType(exp2->First()),
    	       	   		                Ptree::ShallowSubst(e2, e, exp2->Cdr())));
}

As you see that'd cause in the case of the default walker a large number of
calls to methods just returning their argument, but that's the simplest way
of adding hooks that I can see.


> > or to call the current one and manipulate the result Ptree
> > again (useless copy of (part of) the Ptree).
> 
> What if you provide your own walker, which derives or delegates to the
> existing walker? In your implementation of
> 'YourWalker::TranslateFunctionImplementation()' you could either call the
> original walker (and possibly postprocess the result) or not call it and
> do all processing by yourself. Is this what you are looking for?

Yes, the same could possibly be done by pre-processing and post-processing
the Ptrees manipulated by the default walker, and I now realize that it
would be much more lightweight to do so than to add all those hooks.


> > I'm under the impression that if we were given translator hooks within each
> > call to Translate(), with the default implementation just returning its
> > Ptree* argument, that would be sufficient.  I noticed a
> > TranslateFunctionBody(), but a quick code browsing does not make it obvious
> > to me that it's be taken into account here.  Clearly I'd need to experiment.
> 
> I am not sure: are you talking about accessing the code from user-defined
> metaclass methods or about writting your own derivative of Walker?

Just the code of methods and functions in standard code.

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>