[Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping

Neal Gompa ngompa13 at gmail.com
Sat Feb 18 12:40:42 UTC 2017


On Tue, Feb 7, 2017 at 3:46 AM, Panu Matilainen
<pmatilai at laiskiainen.org> wrote:
> On 02/07/2017 10:04 AM, Vít Ondruch wrote:
>>
>>
>>
>> Dne 6.2.2017 v 19:43 Panu Matilainen napsal(a):
>>>
>>> On 02/06/2017 06:51 PM, Vít Ondruch wrote:
>>>>
>>>>
>>>>
>>>> Dne 6.2.2017 v 16:00 Panu Matilainen napsal(a):
>>>>>
>>>>>
>>>>> One open question I have is what to do with %undefine's: currently rpm
>>>>> allows %undefining anything from any scope, and that is at odds with
>>>>> any attempt to rationalize and formalize the scoping to something
>>>>> actually comprehensible. A simple approach is that you can only
>>>>> undefine something from your local scope or the global scope. But what
>>>>> if there's something by the same name in between?
>>>>>
>>>>
>>>> What is wrong with this? You always undefine the value from the top of
>>>> the stack ...
>>>
>>>
>>> What do you mean by "this" - the current behavior or the alleged
>>> scoping aware new version?
>>>
>>> The current behavior indeed just removes from top of the stack with no
>>> consideration as to who defined the macro and where. And this in a
>>> system that makes claims about scoping...
>>>
>>
>> Right, now I see ... but then I don't understand what you meant by "But
>> what if there's something by the same name in between?"
>
>
> Right, maybe an example will make it clearer. Indenting and missing
> line-continuation characters are supposed to be for readers benefit:
>
> ---
> %define foo 1
>
> %define dofoo()
>     %define foo foo
>     %undefine foo
>     %undefine foo
>
> %define dobar()
>     %define foo bar
>     %dofoo
>     echo %foo
>
> %dobar
> ---
>
> So dobar() defines a local %foo which shadows the global %foo. Then it calls
> dofoo() which creates its own local %foo, and then %undefines it twice. What
> is supposed to happen in this case?
>
> The way I see it, if we're supposed to have some sort of meaningful scopes,
> the undefines in dofoo() cannot possibly affect the definition of foo in
> dobar(). So does the second undefine affect the globally defined foo? That's
> one possible interpretation, but this is a problem with the rpm
> implementation of things as the macros stack globally, so instead of popping
> the macro at top of stack, it'd be popping it from bottom of it because
> there's the dobar() definition in between.
>
> Without violating the principles of the global macro stack, the only
> possible interpretation I see is declaring the second undefine a no-op (as
> in try to undefine a non-existent macro). Whether that is sensible at all is
> an entirely different question - it almost certainly is not.
>
> It's also quite possible the only sane answer here is "implement a proper
> local stack then"...
>

Laid out like that, I think "implement a proper local stack" is the
right way to go...



-- 
真実はいつも一つ!/ Always, there's only one truth!


More information about the Rpm-ecosystem mailing list