Re: Optimzed vs. readable code

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Ian Lance Taylor <ian@airs.com> writes:

[...]

| > I don't remember that was discussed either in the paper, or
| > iinformally over lunch.  I'll pass it over; thanks!
| > 
| > | How should it work?
| > 
| > Assuming no modification to the current idea, I would expect my
| > rewrite to produce
| > 
| >    int x = foo quux bar;
| > 
| > which may fail.  Did I transmute your example too much?
| 
| That is indeed the problem I was trying to point out.  If that is what
| happens, it means that you can't freely use private macros within
| #scope/#endscope with #export.

You're right.

| > | We could argue that this will only work as desired if we #export
| > | EFUNC.  Then we would have to make sure to only rewrite CHECK to use a
| > | private version of EFUNC if EFUNC is not #exported.  That's slightly
| > | nasty since at the time of the #define of CHECK we don't know whether
| > | or not EFUNC is exported.
| > 
| > An alternative is to have the expansion occur in such a way that
| > if a replacement list contains references to tokens reachable from the
| > definition macro #scope block, then those are what used in the
| > expansion.   That would mean that you would not have to #export EFUNC
| > but its expansion would expand to EFUNC no matter whether EFUNC was
| > redefined later.
| 
| What I was trying to get at by requiring #export EFUNC was to permit
| both the COMB case and the EFUNC case.  In the COMB case we want to
| always use the version of COMB within the corresponding
| #scope/#endscope.  In the EFUNC case we want to use the current
| definition of EFUNC, whatever it is.  If we want to support both
| cases, then we need some way to tell them apart.  If we only want to
| support one case, I think we should support the COMB case, as it is
| more clearly useful.

That is a good point.  

I suspect at this point, we might want to start playing with
implementations... 

| > | Generally a cool idea, though.
| > 
| > Thanks.  We observed that the name "scope" tend to sloightly convey a
| > different notion (e.g. C++' notion of scope), so we're thinking about
| > using something different because the last thing we want to have is
| > people confuse C++'s notion of scope with CPP -- and avoid exporting
| > C++ scope rules to CPP.  Maybe #group or #block.
| 
| #nest?  #private?  #namespace?  #hide?

I'll toss your suggestions aroound.
Thanks!

-- Gaby