The reasons are historical. I started long ago with the premise that
one call into the parser returned one or fewer tags. This worked
well, and the bovine parser was pretty easy to use, but quite
limiting. You could write no optional lambda expressions, and still
get an interesting parse tree.
We have since made things more flexible, and added the TAG style
macros to help simplify things which, apparently, leads to some
It is unclear to me what the right answer is. At a minimum, a
useful error message out of that routine would be good.
Probably if you put your tag list in as the NAME slot in a tag, then
your extract mechanism would be pretty easy.
>>> Joseph Kiniry <kiniry@...> seems to think that:
>Why can a rule used in an EXPANDFULL not return a list?
>binding_list-expandfull : LPAREN
> | RPAREN
> | COMMA
> | typedid
> | typedids
>typedid returns a single variable tag like
> ("n" 'variable (:type "BOOL"))
>and typeids returns a list of variable tags like
> ( ("n" 'variable (:type "BOOL")) ("m" 'variable (:type "BOOL")))
>In such a case, semantic signals and error and provides the backtrace:
>Debugger entered: ((("n" variable (:type "BOOL") nil nil 637 647) ("m" variable (:type "BOOL") nil nil 637 647)))
> semantic--tag-expand((("n" variable (:type "BOOL") nil nil 637 647) ("m" variable (:type "BOOL") nil nil 637 647)))
> semantic-repeat-parse-whole-stream(((LPAREN 636 . 637) (IDENTIFIER 637 . 638) (COMMA 638 . 639) (IDENTIFIER 640 . 641) (COLON 641 . 642) (IDENTIFIER 643 . 647) (RPAREN 647 . 648)) binding_list-expandfull nil)
> semantic-parse-region-default(636 648 binding_list-expandfull 1 nil)
> semantic-parse-region(636 648 binding_list-expandfull 1)
>Perhaps semantic--tag-expand should be modified to handle lists of
>I guess I must lift the handling of the grouped variable tag handling
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org