Aha, that explains it. I don't use that fcn by itself when developing a
grammar. I tend to use misc debugging routines for examining what happens.
semantic-parse-region does have an nreverse in it to flip the order.
The log says I added it in 2000, but not why. It was before I adopted
ChangLog format in the logs.
Anyway, sorry, but I don't know why this is. I'm glad it is working in
the regular parsing environment though. ;)
On 01/31/2013 05:43 AM, kototama kototama wrote:
> What is strange is that if I invoke manually the parsing as follow
> (semantic-parse-region 39 46 'fn_content_simple_arity)
> then the variables list are in the wrong order but nonetheless when I
> get the tag from the function with semantic-fetch-tags the argument
> are then in the good order.
> My grammar just contains
> fn_content_simple_arity: BRACK_BLOCK
> (EXPANDFULL $1 argument)
> argument: IDENTIFIER
> (VARIABLE-TAG $1 nil nil)
> On Thu, Jan 31, 2013 at 2:27 AM, Eric M. Ludlam<eric@...> wrote:
>> On 01/29/2013 04:05 AM, kototama kototama wrote:
>>> I'm using the following rule to match arguments of functions defined as
>>> (defn function-name [arg1 arg2]) :
>>> fn_content_simple_arity: BRACK_BLOCK
>>> (EXPANDFULL $1 argument)
>>> I'm also reusing this rule for functions defined as
>>> (defn function-name ([arg1 arg2])):
>>> fn_content_multi_arity: PAREN_BLOCK
>>> (EXPANDFULL $1 fn_content_simple_arity)
>>> | // some other code here
>>> When fn_content_multi_arity calls expandfull on
>>> fn_content_simple_arity, the tags are returned in reverse order.
>>> Instead of getting the variable tag (arg1 arg2), I get (arg2, arg1).
>>> Why are the tags return in the wrong order? I called but reverse on
>>> the list but is there a more appropriate way of doing that? I also
>>> tried EXPAND $1 fn_content_simple_arity but it didn't work.
>> I have no idea why your arguments might be reversed. I have used that
>> feature many times and not see that happen.
>> You can use 'wisent-debug-on-entry' for a rule, and it will allow you to
>> step through your actions when they are encountered in a source file. You
>> should step through argument, and fn_content_simple_arity and see if you can
>> identify where the flip happens.