Re: [3.0.4] Request: please revive the deleted arrays yyrhs and yyprhs

[box12009]

Dear Akim, 

  OK, I'll tell you a little bit about why and how I am utilizing the vanished 
variable values  :-)

  I have completed a large-scale 'COBOL to Java' converter, written in Java, 
importing only the Java Core Libraries.
  My initial target was making a COBOL language parser written in Java, which 
reads any COBOL source and writes its AST (abstract syntax tree) made and 
linked of Java objects. 

  I decided to utilize the traditional yacc technology, but bison command can 
create only parser sources in C language, you know. 
  Bison cannot create any parser program in Java. 

  My idea is regarding the COBOL parser 'y.tab.c' generated by bison command 
with option '-y' (POSIX yacc mode) from my COBOL syntax definition file in yacc 
format, not as a program, but as a simple input data for my COBOL parser. 

  I do not know how Bison works internally as a parser generator, but I could 
know deeply enough how the created program 'y.tab.c' is processing internally 
by reading its codes. 

  Then I ported the 'y.tab.c' from C to Java, erasing initial values of the 
number/symbol tables, making loading process of the tables, rewriting under the 
structured coding policy, deleting ACTION function (because Java has no 
real-time evaluation such as Perl), and adding a new mechanism in Java to 
execute specific actions while parsing. 

  My parser reads 'y.tab.c' initially to create number/symbol arrays in Java 
objects, corresponding to the number/symbol arrays in 'y.tab.c' such as 
YYTRANSLATE. 
  And then my parser starts parsing the currently given COBOL application 
source, like the behaviour of 'y.tab.c', referring the loaded tables.

  In my parser, YYRHS and YYPRHS are also absolutely necessary. 

  For example, when some error occurs, displayed information for user must 
include symbolic string of some token or nterm.

  YYPRHS[YYN] is the index of the first RHS symbol of rule number YYN in YYRHS.
  So, it enables conversion from any rule number + 1 to the index in YYRHS. 

  Next, YYRHS is the `-1'-separated list of the rules' RHS (right hand side). 
  This is a vector consisting of items of all the rules. 
  Each number other than -1 is a symbol number of some token or nterm. 
  '-1' is a delimiter and also shows that the rule is not used when -1 is 
pointed from YYPRHS.

  After all, we can get any symbol by 

Old y.tab.c:
|      yy_symbol_print (stderr, yyrhs[yyprhs[yyrule] + yyi],
|                      &(yyvsp[(yyi + 1) - (yynrhs)])
|                                      );

  I wrote the equivalent procedure in Java to the above code.

  The above code has been changed in bison 3 as follows:

New y.tab.c:
|      yy_symbol_print (stderr,
|                       yystos[yyssp[yyi + 1 - yynrhs]],
|                       &(yyvsp[(yyi + 1) - (yynrhs)])
|                                              );

  Anyway, in many point of my own additional code, for example in editing rule 
information for displaying, I use YYRHS and YYPRHS many times. 
  I added error displaying functionalities for easier debugging in my parser. 
  My parser is calling displaying symbol routine more than 'y.tab.c', I think.

  Token/nterm symbol displaying is seriously imortant thing for me.
  From Bison 3, YYRHS and YYPRHS came to be unavalilable, so I made a new 
analyzer inputting 'y.output' file outputting tables in Java array objects with 
initial values which are identical to them in the YYRHS and YYPRHS. 


  Is this explanation enough for you?

  I'm very happy to hear thay you'll reold the outputting option of these 
debugging information, because it could save my some unexpected crisis in the 
future!

---
  box12009

-------------- Original Message ONLY --------------
From:     Akim Demaille <address@hidden>
Sent:     2018/09/15 13:44:12
To:       address@hidden
Cc:       Bison Bugs <address@hidden>
Subject:  Re: [3.0.4] Request: please revive the deleted arrays yyrhs and yyprhs

> Hi!
> 
> > Le 13 sept. 2018 à 09:03, address@hidden a écrit :
> > 
> > Thank you, Akim!
> > 
> >  At that time, I was puzzled. 
> >  Had some rapid rescue been done, it could saved our much time. 
> > 
> >  Not so long time after the time, I decided to write my own program to 
> > compute the lost information from the rest information in generated C 
> > program sources. 
> > 
> >  Fortunately, my computation coding effort succeeded．
> >  So, I am not facing the trouble now.
> > 
> >  I appreciate your great offer, thank you! 
> 
> I’m sorry I arrived too late.  I could just add this as an option
> anyway.
> 
> Could you tell us a bit more about the use case?  Why were these
> tables useful to you?  Did you use them really from the parser, or
> did you have some other process that relies on the tables generated
> by Bison but not on its generated parser?