Re: Optimzed vs. readable code

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

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

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| >   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1614.pdf
| 
| Interesting, but it doesn't seem to describe:
| 
| #scope
| #define COMB ::
| #define combine(a,b) a::b
| #export combine
| #endscope
| 
| #define COMB quux
| int x = combine(foo,bar);
| 
| Has this issue been discussed anywhere?

With the current specification, I would expect it to produce

    int x = foo::bar;

I suspect, you meant

    #scope
    #define COMB ::
    #define combine(a,b) a COMB b
    #export combine
    #endscope

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?

|  In the above example, it seems clear that combine
| should be rewritten internally to refer to a renamed, private, version
| of COMB.
| 
| But that would prohibit a capability which currently exists, to have a
| macro refer another macro and to have the code #undef and #define that
| other macro.  For example:
| 
| #scope
| #define EFUNC standard_error
| #define CHECK(x) ((x) || EFUNC (__FILE__, __LINE__))
| #export CHECK
| #endscope
| 
| CHECK(foo);
| #undef EFUNC
| #define EFUNC my_error
| CHECK(bar);
| 
| 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.

| It gets nastier if we have nested scopes.  We might #export both CHECK
| and EFUNC to the enclosing scope, but then only #export CHECK to the
| next enclosing scope.  That would imply that we have to rewrite CHECK
| again when the enclosing scope closes.
| 
| 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.

-- Gaby