Re: Optimzed vs. readable code

[Ian Lance Taylor <ian at airs dot com>]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> I suspect, you meant
> 
>     #scope
>     #define COMB ::
>     #define combine(a,b) a COMB b
>     #export combine
>     #endscope

Umm, yeah.  Whoops.

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


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


> | 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?

Ian