home *** CD-ROM | disk | FTP | other *** search
/ Geek Gadgets 1 / ADE-1.bin / ade-dist / bison-1.25-diffs.gz / bison-1.25-diffs
Text File  |  1996-10-13  |  257KB  |  6,495 lines
  1. This file contains patches that transform the baseline version into
  2. the amiga version.  Assuming that you have unarchived the baseline
  3. version in the current directory, just run the command:
  4.  
  5.     patch -p1 -E -b .pbak <diff-file
  6.  
  7. where 'diff-file' is this patch file.  After running patch you should
  8. remove all the generated *.pbak files, and look for any *.rej files
  9. that indicate a problem patching the baseline source.
  10.  
  11. diff -rup --new-file baseline/fsf/bison/BeOS.diffs amiga/fsf/bison/BeOS.diffs
  12. --- baseline/fsf/bison/BeOS.diffs    Wed Dec 31 17:00:00 1969
  13. +++ amiga/fsf/bison/BeOS.diffs    Sat Sep 28 00:00:00 1996
  14. @@ -0,0 +1,324 @@
  15. +This patch works around current bugs in the BeOS shell that affect
  16. +configure, and also patch up some Makefile targets that are not
  17. +yet fully supported.
  18. +
  19. +============================================================================
  20. +
  21. +diff -rc bison-ref/Makefile.in bison/Makefile.in
  22. +*** bison-ref/Makefile.in    Thu Sep 12 16:51:51 1996
  23. +--- bison/Makefile.in    Mon Sep 16 01:47:29 1996
  24. +***************
  25. +*** 107,113 ****
  26. +        warshall.o version.o                        \
  27. +        getopt.o getopt1.o $(ALLOCA)
  28. +  
  29. +! all: bison bison.info bison.s1 bison.guide bison.dvi bison.ps
  30. +  
  31. +  Makefile: Makefile.in config.status
  32. +      ./config.status
  33. +--- 107,113 ----
  34. +        warshall.o version.o                        \
  35. +        getopt.o getopt1.o $(ALLOCA)
  36. +  
  37. +! all: bison bison.info bison.s1 bison.guide
  38. +  
  39. +  Makefile: Makefile.in config.status
  40. +      ./config.status
  41. +***************
  42. +*** 142,149 ****
  43. +      for f in bison.info*; \
  44. +      do $(INSTALL_DATA) $$f $(infodir)/$$f; done
  45. +      $(INSTALL_DATA) bison.guide $(guidedir)/bison.guide
  46. +!     $(INSTALL_DATA) bison.dvi $(dvidir)/bison.dvi
  47. +!     $(INSTALL_DATA) bison.ps $(psdir)/bison.ps
  48. +      $(INSTALL_DATA) $(srcdir)/bison.1 $(mandir)/bison.$(manext)
  49. +  
  50. +  # Make sure all installation directories, e.g. $(bindir) actually exist by
  51. +--- 142,149 ----
  52. +      for f in bison.info*; \
  53. +      do $(INSTALL_DATA) $$f $(infodir)/$$f; done
  54. +      $(INSTALL_DATA) bison.guide $(guidedir)/bison.guide
  55. +! #    $(INSTALL_DATA) bison.dvi $(dvidir)/bison.dvi
  56. +! #    $(INSTALL_DATA) bison.ps $(psdir)/bison.ps
  57. +      $(INSTALL_DATA) $(srcdir)/bison.1 $(mandir)/bison.$(manext)
  58. +  
  59. +  # Make sure all installation directories, e.g. $(bindir) actually exist by
  60. +diff -rc bison-ref/configure bison/configure
  61. +*** bison-ref/configure    Tue Sep 10 03:05:11 1996
  62. +--- bison/configure    Mon Sep 16 01:42:45 1996
  63. +***************
  64. +*** 599,605 ****
  65. +    yes;
  66. +  #endif
  67. +  EOF
  68. +! if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:603: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
  69. +    ac_cv_prog_gcc=yes
  70. +  else
  71. +    ac_cv_prog_gcc=no
  72. +--- 599,605 ----
  73. +    yes;
  74. +  #endif
  75. +  EOF
  76. +! if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:603: \"$ac_try\") 1>&5; xxx=`(eval $ac_try 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }; } | egrep yes >/dev/null 2>&1; then
  77. +    ac_cv_prog_gcc=yes
  78. +  else
  79. +    ac_cv_prog_gcc=no
  80. +***************
  81. +*** 737,743 ****
  82. +  Syntax Error
  83. +  EOF
  84. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  85. +! { (eval echo configure:741: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  86. +  ac_err=`grep -v '^ *+' conftest.out`
  87. +  if test -z "$ac_err"; then
  88. +    :
  89. +--- 737,743 ----
  90. +  Syntax Error
  91. +  EOF
  92. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  93. +! { (eval echo configure:741: \"$ac_try\") 1>&5; xxx=`(eval $ac_try 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }
  94. +  ac_err=`grep -v '^ *+' conftest.out`
  95. +  if test -z "$ac_err"; then
  96. +    :
  97. +***************
  98. +*** 752,758 ****
  99. +  Syntax Error
  100. +  EOF
  101. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  102. +! { (eval echo configure:756: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  103. +  ac_err=`grep -v '^ *+' conftest.out`
  104. +  if test -z "$ac_err"; then
  105. +    :
  106. +--- 752,758 ----
  107. +  Syntax Error
  108. +  EOF
  109. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  110. +! { (eval echo configure:756: \"$ac_try\") 1>&5; xxx=`(eval $ac_try 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }
  111. +  ac_err=`grep -v '^ *+' conftest.out`
  112. +  if test -z "$ac_err"; then
  113. +    :
  114. +***************
  115. +*** 783,789 ****
  116. +  #include <minix/config.h>
  117. +  EOF
  118. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  119. +! { (eval echo configure:787: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  120. +  ac_err=`grep -v '^ *+' conftest.out`
  121. +  if test -z "$ac_err"; then
  122. +    rm -rf conftest*
  123. +--- 783,789 ----
  124. +  #include <minix/config.h>
  125. +  EOF
  126. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  127. +! { (eval echo configure:787: \"$ac_try\") 1>&5; xxx=`(eval $ac_try 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }
  128. +  ac_err=`grep -v '^ *+' conftest.out`
  129. +  if test -z "$ac_err"; then
  130. +    rm -rf conftest*
  131. +***************
  132. +*** 852,858 ****
  133. +  #include "confdefs.h"
  134. +  main(){return(0);}
  135. +  EOF
  136. +! { (eval echo configure:856: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
  137. +  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  138. +    ac_cv_c_cross=no
  139. +  else
  140. +--- 852,858 ----
  141. +  #include "confdefs.h"
  142. +  main(){return(0);}
  143. +  EOF
  144. +! { (eval echo configure:856: \"$ac_link\") 1>&5; xxx=`(eval $ac_link 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }
  145. +  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  146. +    ac_cv_c_cross=no
  147. +  else
  148. +***************
  149. +*** 878,884 ****
  150. +  #include <float.h>
  151. +  EOF
  152. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  153. +! { (eval echo configure:882: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  154. +  ac_err=`grep -v '^ *+' conftest.out`
  155. +  if test -z "$ac_err"; then
  156. +    rm -rf conftest*
  157. +--- 878,884 ----
  158. +  #include <float.h>
  159. +  EOF
  160. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  161. +! { (eval echo configure:882: \"$ac_try\") 1>&5; xxx=`(eval $ac_try 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }
  162. +  ac_err=`grep -v '^ *+' conftest.out`
  163. +  if test -z "$ac_err"; then
  164. +    rm -rf conftest*
  165. +***************
  166. +*** 943,949 ****
  167. +  exit (0); }
  168. +  
  169. +  EOF
  170. +! { (eval echo configure:947: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
  171. +  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  172. +    :
  173. +  else
  174. +--- 943,949 ----
  175. +  exit (0); }
  176. +  
  177. +  EOF
  178. +! { (eval echo configure:947: \"$ac_link\") 1>&5; xxx=`(eval $ac_link 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }
  179. +  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  180. +    :
  181. +  else
  182. +***************
  183. +*** 975,981 ****
  184. +  #include <$ac_hdr>
  185. +  EOF
  186. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  187. +! { (eval echo configure:979: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  188. +  ac_err=`grep -v '^ *+' conftest.out`
  189. +  if test -z "$ac_err"; then
  190. +    rm -rf conftest*
  191. +--- 975,981 ----
  192. +  #include <$ac_hdr>
  193. +  EOF
  194. +  ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  195. +! { (eval echo configure:979: \"$ac_try\") 1>&5; xxx=`(eval $ac_try 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }
  196. +  ac_err=`grep -v '^ *+' conftest.out`
  197. +  if test -z "$ac_err"; then
  198. +    rm -rf conftest*
  199. +***************
  200. +*** 1055,1061 ****
  201. +  
  202. +  ; return 0; }
  203. +  EOF
  204. +! if { (eval echo configure:1059: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
  205. +    rm -rf conftest*
  206. +    ac_cv_c_const=yes
  207. +  else
  208. +--- 1055,1061 ----
  209. +  
  210. +  ; return 0; }
  211. +  EOF
  212. +! if { (eval echo configure:1059: \"$ac_compile\") 1>&5; xxx=`(eval $ac_compile 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }; then
  213. +    rm -rf conftest*
  214. +    ac_cv_c_const=yes
  215. +  else
  216. +***************
  217. +*** 1090,1096 ****
  218. +  char *p = alloca(2 * sizeof(int));
  219. +  ; return 0; }
  220. +  EOF
  221. +! if { (eval echo configure:1094: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
  222. +    rm -rf conftest*
  223. +    ac_cv_header_alloca_h=yes
  224. +  else
  225. +--- 1090,1096 ----
  226. +  char *p = alloca(2 * sizeof(int));
  227. +  ; return 0; }
  228. +  EOF
  229. +! if { (eval echo configure:1094: \"$ac_link\") 1>&5; xxx=`(eval $ac_link 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }; then
  230. +    rm -rf conftest*
  231. +    ac_cv_header_alloca_h=yes
  232. +  else
  233. +***************
  234. +*** 1138,1144 ****
  235. +  char *p = (char *) alloca(1);
  236. +  ; return 0; }
  237. +  EOF
  238. +! if { (eval echo configure:1142: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
  239. +    rm -rf conftest*
  240. +    ac_cv_func_alloca=yes
  241. +  else
  242. +--- 1138,1144 ----
  243. +  char *p = (char *) alloca(1);
  244. +  ; return 0; }
  245. +  EOF
  246. +! if { (eval echo configure:1142: \"$ac_link\") 1>&5; xxx=`(eval $ac_link 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }; then
  247. +    rm -rf conftest*
  248. +    ac_cv_func_alloca=yes
  249. +  else
  250. +***************
  251. +*** 1226,1232 ****
  252. +  
  253. +  ; return 0; }
  254. +  EOF
  255. +! if { (eval echo configure:1230: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
  256. +    rm -rf conftest*
  257. +    eval "ac_cv_func_$ac_func=yes"
  258. +  else
  259. +--- 1226,1232 ----
  260. +  
  261. +  ; return 0; }
  262. +  EOF
  263. +! if { (eval echo configure:1230: \"$ac_link\") 1>&5; xxx=`(eval $ac_link 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }; then
  264. +    rm -rf conftest*
  265. +    eval "ac_cv_func_$ac_func=yes"
  266. +  else
  267. +***************
  268. +*** 1277,1283 ****
  269. +    exit (find_stack_direction() < 0);
  270. +  }
  271. +  EOF
  272. +! { (eval echo configure:1281: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
  273. +  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  274. +    ac_cv_c_stack_direction=1
  275. +  else
  276. +--- 1277,1283 ----
  277. +    exit (find_stack_direction() < 0);
  278. +  }
  279. +  EOF
  280. +! { (eval echo configure:1281: \"$ac_link\") 1>&5; xxx=`(eval $ac_link 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }
  281. +  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  282. +    ac_cv_c_stack_direction=1
  283. +  else
  284. +***************
  285. +*** 1325,1331 ****
  286. +  
  287. +  ; return 0; }
  288. +  EOF
  289. +! if { (eval echo configure:1329: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
  290. +    rm -rf conftest*
  291. +    eval "ac_cv_func_$ac_func=yes"
  292. +  else
  293. +--- 1325,1331 ----
  294. +  
  295. +  ; return 0; }
  296. +  EOF
  297. +! if { (eval echo configure:1329: \"$ac_link\") 1>&5; xxx=`(eval $ac_link 2>&5 ; echo $?)` ; test "$xxx" = "0" ; }; then
  298. +    rm -rf conftest*
  299. +    eval "ac_cv_func_$ac_func=yes"
  300. +  else
  301. +***************
  302. +*** 1367,1375 ****
  303. +  EOF
  304. +  # Ultrix sh set writes to stderr and can't be redirected directly,
  305. +  # and sets the high bit in the cache file unless we assign to the vars.
  306. +! (set) 2>&1 |
  307. +    sed -n "s/^\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\)=\(.*\)/\1=\${\1='\2'}/p" \
  308. +!   >> confcache
  309. +  if cmp -s $cache_file confcache; then
  310. +    :
  311. +  else
  312. +--- 1367,1375 ----
  313. +  EOF
  314. +  # Ultrix sh set writes to stderr and can't be redirected directly,
  315. +  # and sets the high bit in the cache file unless we assign to the vars.
  316. +! (set) >cache.tmp 2>&1 
  317. +    sed -n "s/^\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\)=\(.*\)/\1=\${\1='\2'}/p" \
  318. +!   <cache.tmp >> confcache
  319. +  if cmp -s $cache_file confcache; then
  320. +    :
  321. +  else
  322. +***************
  323. +*** 1380,1386 ****
  324. +      echo "not updating unwritable cache $cache_file"
  325. +    fi
  326. +  fi
  327. +! rm -f confcache
  328. +  
  329. +  trap 'rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1' 1 2 15
  330. +  
  331. +--- 1380,1386 ----
  332. +      echo "not updating unwritable cache $cache_file"
  333. +    fi
  334. +  fi
  335. +! rm -f confcache cache.tmp
  336. +  
  337. +  trap 'rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1' 1 2 15
  338. +  
  339. diff -rup --new-file baseline/fsf/bison/Makefile.in amiga/fsf/bison/Makefile.in
  340. --- baseline/fsf/bison/Makefile.in    Sat May 11 12:17:40 1996
  341. +++ amiga/fsf/bison/Makefile.in    Sat Sep 28 00:00:00 1996
  342. @@ -27,6 +27,8 @@ INSTALL = @INSTALL@
  343.  INSTALL_PROGRAM = @INSTALL_PROGRAM@
  344.  INSTALL_DATA = @INSTALL_DATA@
  345.  MAKEINFO = makeinfo
  346. +TEXI2DVI = texi2dvi
  347. +DVIPS = dvips
  348.  
  349.  # Things you might add to DEFS:
  350.  # -DSTDC_HEADERS    If you have ANSI C headers and libraries.
  351. @@ -35,8 +37,8 @@ MAKEINFO = makeinfo
  352.  # -DHAVE_STRERROR    If you have strerror function.
  353.  DEFS = @DEFS@
  354.  
  355. -CFLAGS = -g
  356. -LDFLAGS =
  357. +CFLAGS = @CFLAGS@
  358. +LDFLAGS = @LDFLAGS@
  359.  
  360.  LIBS = @LIBS@
  361.  
  362. @@ -56,6 +58,15 @@ datadir = $(prefix)/share
  363.  # where the info files go
  364.  infodir = $(prefix)/info
  365.  
  366. +# where the guide files go
  367. +guidedir = $(prefix)/guide
  368. +
  369. +# where the dvi files go
  370. +dvidir = $(prefix)/dvi
  371. +
  372. +# where the ps files go
  373. +psdir = $(prefix)/ps
  374. +
  375.  # where manual pages go and what their extensions should be
  376.  mandir = $(prefix)/man/man$(manext)
  377.  manext = 1
  378. @@ -70,16 +81,18 @@ DISTFILES = COPYING ChangeLog Makefile.i
  379.      output.c print.c reader.c reduce.c symtab.c version.c \
  380.      warshall.c files.h gram.h lex.h machine.h new.h state.h \
  381.      symtab.h system.h types.h bison.cld build.com vmsgetargs.c \
  382. -    vmshlp.mar README INSTALL NEWS bison.texinfo bison.info* texinfo.tex \
  383. -    getopt.c getopt.h getopt1.c alloca.c mkinstalldirs install-sh
  384. +    vmshlp.mar README INSTALL NEWS bison.texinfo bison.info* \
  385. +    bison.guide bison.dvi bison.ps \
  386. +    texinfo.tex getopt.c getopt.h getopt1.c alloca.c mkinstalldirs install-sh
  387.  
  388.  
  389.  SHELL = /bin/sh
  390.  
  391.  # This rule allows us to supply the necessary -D options
  392.  # in addition to whatever the user asks for.
  393. +# ADE-local: Removed -I$(srcdir)/../include since it points nowhere.
  394.  .c.o:
  395. -    $(CC) -c $(DEFS) -I$(srcdir)/../include $(CPPFLAGS) $(CFLAGS) $<
  396. +    $(CC) -c $(DEFS) $(CPPFLAGS) $(CFLAGS) $<
  397.  
  398.  # names of parser files
  399.  PFILE = bison.simple
  400. @@ -94,7 +107,7 @@ OBJECTS = LR0.o allocate.o closure.o con
  401.        warshall.o version.o                        \
  402.        getopt.o getopt1.o $(ALLOCA)
  403.  
  404. -all: bison bison.info bison.s1
  405. +all: bison bison.info bison.s1 bison.guide bison.dvi bison.ps
  406.  
  407.  Makefile: Makefile.in config.status
  408.      ./config.status
  409. @@ -119,26 +132,30 @@ distclean: clean
  410.      rm -f Makefile config.status
  411.  
  412.  realclean: distclean
  413. -    rm -f TAGS *.info*
  414. +    rm -f TAGS *.info* *.guide *.dvi *.ps
  415.  
  416.  # Most of these deps are in case using RCS.
  417.  install: all bison.1 $(srcdir)/$(PFILE) $(srcdir)/$(PFILE1) installdirs uninstall
  418.      $(INSTALL_PROGRAM) bison $(bindir)/bison
  419.      $(INSTALL_DATA) bison.s1 $(datadir)/$(PFILE)
  420.      $(INSTALL_DATA) $(srcdir)/$(PFILE1) $(datadir)/$(PFILE1)
  421. -    cd $(srcdir); for f in bison.info*; \
  422. +    for f in bison.info*; \
  423.      do $(INSTALL_DATA) $$f $(infodir)/$$f; done
  424. -    -$(INSTALL_DATA) $(srcdir)/bison.1 $(mandir)/bison.$(manext)
  425. +    $(INSTALL_DATA) bison.guide $(guidedir)/bison.guide
  426. +    $(INSTALL_DATA) bison.dvi $(dvidir)/bison.dvi
  427. +    $(INSTALL_DATA) bison.ps $(psdir)/bison.ps
  428. +    $(INSTALL_DATA) $(srcdir)/bison.1 $(mandir)/bison.$(manext)
  429.  
  430.  # Make sure all installation directories, e.g. $(bindir) actually exist by
  431.  # making them if necessary.
  432.  installdirs:
  433. -    -sh $(srcdir)/mkinstalldirs $(bindir) $(datadir) $(libdir) $(infodir) $(mandir)
  434. +    -sh $(srcdir)/mkinstalldirs $(bindir) $(datadir) $(libdir) $(infodir) $(guidedir) $(mandir) $(dvidir) $(psdir)
  435.  
  436.  uninstall:
  437.      rm -f $(bindir)/bison
  438.      -cd $(datadir); rm -f $(PFILE) $(PFILE1)
  439.      rm -f $(mandir)/bison.$(manext) $(infodir)/bison.info*
  440. +    rm -f $(guidedir)/bison.guide $(dvidir)/bison.dvi $(psdir)/bison.ps
  441.  
  442.  check:
  443.      @echo "No checks implemented (yet)."
  444. @@ -149,7 +166,7 @@ bison: $(OBJECTS)
  445.  # We don't use $(srcdir) in this rule
  446.  # because it is normally used in the master source dir
  447.  # in which configure has not been run.
  448. -dist: bison.info
  449. +dist: bison.info bison.guide bison.dvi bison.ps
  450.      echo bison-`sed -e '/version_string/!d' -e 's/[^0-9.]*\([0-9.]*\).*/\1/' -e q version.c` > .fname
  451.      -rm -rf `cat .fname`
  452.      mkdir `cat .fname`
  453. @@ -160,7 +177,16 @@ dist: bison.info
  454.      -rm -rf `cat .fname` .fname
  455.  
  456.  bison.info: bison.texinfo
  457. -    $(MAKEINFO) $(srcdir)/bison.texinfo
  458. +    $(MAKEINFO) -I$(srcdir) $(srcdir)/bison.texinfo -o $@
  459. +
  460. +bison.guide: bison.texinfo
  461. +    $(MAKEINFO) --amiga $(srcdir)/bison.texinfo -o $@
  462. +
  463. +bison.dvi: bison.texinfo
  464. +    $(TEXI2DVI) $?
  465. +
  466. +bison.ps: bison.dvi
  467. +    $(DVIPS) -o $@ $?
  468.  
  469.  TAGS: *.c *.h
  470.      etags *.c *.h
  471. diff -rup --new-file baseline/fsf/bison/Product-Info amiga/fsf/bison/Product-Info
  472. --- baseline/fsf/bison/Product-Info    Wed Dec 31 17:00:00 1969
  473. +++ amiga/fsf/bison/Product-Info    Sat Sep 28 00:00:00 1996
  474. @@ -0,0 +1,26 @@
  475. +.name
  476. +bison
  477. +.fullname
  478. +GNU parser generator
  479. +.type
  480. +Programmer Tool
  481. +.short
  482. +GNU parser generator yacc replacement
  483. +.description
  484. +Bison is a parser generator in the style of yacc (1).  It should be
  485. +upwardly compatible with input files designed for yacc.  Input files
  486. +should follow the yacc convention of ending in ".y".  Unlike yacc, the
  487. +generated files do not have fixed names, but instead use the prefix of
  488. +the input file.  For instance, a grammar description file named
  489. +parse.y would produce the generated parser in a file named
  490. +parse.tab.c, instead of yacc 's y.tab.c.
  491. +.version
  492. +1.25
  493. +.author
  494. +Free Software Foundation
  495. +.requirements
  496. +Binary version requires ixemul.library.
  497. +.distribution
  498. +GNU Public License
  499. +.described-by
  500. +Fred Fish (fnf@ninemoons.com)
  501. diff -rup --new-file baseline/fsf/bison/bison.1 amiga/fsf/bison/bison.1
  502. --- baseline/fsf/bison/bison.1    Mon Aug 21 10:15:28 1995
  503. +++ amiga/fsf/bison/bison.1    Sat Sep 28 00:00:00 1996
  504. @@ -325,9 +325,9 @@ The long-named options can be introduced
  505.  for compatibility with previous releases.  Eventually support for `+'
  506.  will be removed, because it is incompatible with the POSIX.2 standard.
  507.  .SH FILES
  508. -/usr/local/lib/bison.simple    simple parser
  509. +/ade/lib/bison.simple    simple parser
  510.  .br
  511. -/usr/local/lib/bison.hairy    complicated parser
  512. +/ade/lib/bison.hairy    complicated parser
  513.  .SH SEE ALSO
  514.  .IR yacc (1)
  515.  .br
  516. diff -rup --new-file baseline/fsf/bison/bison.info amiga/fsf/bison/bison.info
  517. --- baseline/fsf/bison/bison.info    Sat Feb 17 09:46:08 1996
  518. +++ amiga/fsf/bison/bison.info    Wed Dec 31 17:00:00 1969
  519. @@ -1,129 +0,0 @@
  520. -This is Info file bison.info, produced by Makeinfo-1.64 from the input
  521. -file ./bison.texinfo.
  522. -
  523. -   This file documents the Bison parser generator.
  524. -
  525. -   Copyright (C) 1988, 89, 90, 91, 92, 93, 1995 Free Software
  526. -Foundation, Inc.
  527. -
  528. -   Permission is granted to make and distribute verbatim copies of this
  529. -manual provided the copyright notice and this permission notice are
  530. -preserved on all copies.
  531. -
  532. -   Permission is granted to copy and distribute modified versions of
  533. -this manual under the conditions for verbatim copying, provided also
  534. -that the sections entitled "GNU General Public License" and "Conditions
  535. -for Using Bison" are included exactly as in the original, and provided
  536. -that the entire resulting derived work is distributed under the terms
  537. -of a permission notice identical to this one.
  538. -
  539. -   Permission is granted to copy and distribute translations of this
  540. -manual into another language, under the above conditions for modified
  541. -versions, except that the sections entitled "GNU General Public
  542. -License", "Conditions for Using Bison" and this permission notice may be
  543. -included in translations approved by the Free Software Foundation
  544. -instead of in the original English.
  545. -
  546. -
  547. -Indirect:
  548. -bison.info-1: 1169
  549. -bison.info-2: 50097
  550. -bison.info-3: 97816
  551. -bison.info-4: 147524
  552. -bison.info-5: 195081
  553. -
  554. -Tag Table:
  555. -(Indirect)
  556. -Node: Top1169
  557. -Node: Introduction8402
  558. -Node: Conditions9675
  559. -Node: Copying11141
  560. -Node: Concepts30294
  561. -Node: Language and Grammar31327
  562. -Node: Grammar in Bison36343
  563. -Node: Semantic Values38267
  564. -Node: Semantic Actions40368
  565. -Node: Bison Parser41551
  566. -Node: Stages43861
  567. -Node: Grammar Layout45144
  568. -Node: Examples46401
  569. -Node: RPN Calc47536
  570. -Node: Rpcalc Decls48510
  571. -Node: Rpcalc Rules50097
  572. -Node: Rpcalc Input51897
  573. -Node: Rpcalc Line53358
  574. -Node: Rpcalc Expr54473
  575. -Node: Rpcalc Lexer56418
  576. -Node: Rpcalc Main58977
  577. -Node: Rpcalc Error59355
  578. -Node: Rpcalc Gen60360
  579. -Node: Rpcalc Compile61508
  580. -Node: Infix Calc62383
  581. -Node: Simple Error Recovery65090
  582. -Node: Multi-function Calc66977
  583. -Node: Mfcalc Decl68544
  584. -Node: Mfcalc Rules70567
  585. -Node: Mfcalc Symtab71947
  586. -Node: Exercises78121
  587. -Node: Grammar File78627
  588. -Node: Grammar Outline79395
  589. -Node: C Declarations80129
  590. -Node: Bison Declarations80709
  591. -Node: Grammar Rules81121
  592. -Node: C Code81581
  593. -Node: Symbols82511
  594. -Node: Rules87593
  595. -Node: Recursion89232
  596. -Node: Semantics90943
  597. -Node: Value Type92040
  598. -Node: Multiple Types92712
  599. -Node: Actions93728
  600. -Node: Action Types96513
  601. -Node: Mid-Rule Actions97816
  602. -Node: Declarations103385
  603. -Node: Token Decl104704
  604. -Node: Precedence Decl106701
  605. -Node: Union Decl108252
  606. -Node: Type Decl109096
  607. -Node: Expect Decl110002
  608. -Node: Start Decl111548
  609. -Node: Pure Decl111926
  610. -Node: Decl Summary113240
  611. -Node: Multiple Parsers116755
  612. -Node: Interface118249
  613. -Node: Parser Function119121
  614. -Node: Lexical119956
  615. -Node: Calling Convention121362
  616. -Node: Token Values124091
  617. -Node: Token Positions125239
  618. -Node: Pure Calling126131
  619. -Node: Error Reporting129088
  620. -Node: Action Features131213
  621. -Node: Algorithm134864
  622. -Node: Look-Ahead137157
  623. -Node: Shift/Reduce139289
  624. -Node: Precedence142200
  625. -Node: Why Precedence142851
  626. -Node: Using Precedence144706
  627. -Node: Precedence Examples145674
  628. -Node: How Precedence146375
  629. -Node: Contextual Precedence147524
  630. -Node: Parser States149315
  631. -Node: Reduce/Reduce150558
  632. -Node: Mystery Conflicts154119
  633. -Node: Stack Overflow157505
  634. -Node: Error Recovery158878
  635. -Node: Context Dependency164014
  636. -Node: Semantic Tokens164862
  637. -Node: Lexical Tie-ins167879
  638. -Node: Tie-in Recovery169427
  639. -Node: Debugging171599
  640. -Node: Invocation174950
  641. -Node: Bison Options175613
  642. -Node: Option Cross Key179726
  643. -Node: VMS Invocation180608
  644. -Node: Table of Symbols181392
  645. -Node: Glossary188790
  646. -Node: Index195081
  647. -
  648. -End Tag Table
  649. diff -rup --new-file baseline/fsf/bison/bison.info-1 amiga/fsf/bison/bison.info-1
  650. --- baseline/fsf/bison/bison.info-1    Sat Feb 17 09:46:05 1996
  651. +++ amiga/fsf/bison/bison.info-1    Wed Dec 31 17:00:00 1969
  652. @@ -1,1068 +0,0 @@
  653. -This is Info file bison.info, produced by Makeinfo-1.64 from the input
  654. -file ./bison.texinfo.
  655. -
  656. -   This file documents the Bison parser generator.
  657. -
  658. -   Copyright (C) 1988, 89, 90, 91, 92, 93, 1995 Free Software
  659. -Foundation, Inc.
  660. -
  661. -   Permission is granted to make and distribute verbatim copies of this
  662. -manual provided the copyright notice and this permission notice are
  663. -preserved on all copies.
  664. -
  665. -   Permission is granted to copy and distribute modified versions of
  666. -this manual under the conditions for verbatim copying, provided also
  667. -that the sections entitled "GNU General Public License" and "Conditions
  668. -for Using Bison" are included exactly as in the original, and provided
  669. -that the entire resulting derived work is distributed under the terms
  670. -of a permission notice identical to this one.
  671. -
  672. -   Permission is granted to copy and distribute translations of this
  673. -manual into another language, under the above conditions for modified
  674. -versions, except that the sections entitled "GNU General Public
  675. -License", "Conditions for Using Bison" and this permission notice may be
  676. -included in translations approved by the Free Software Foundation
  677. -instead of in the original English.
  678. -
  679. -
  680. -File: bison.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)
  681. -
  682. -   This manual documents version 1.25 of Bison.
  683. -
  684. -* Menu:
  685. -
  686. -* Introduction::
  687. -* Conditions::
  688. -* Copying::           The GNU General Public License says
  689. -                        how you can copy and share Bison
  690. -
  691. -Tutorial sections:
  692. -* Concepts::          Basic concepts for understanding Bison.
  693. -* Examples::          Three simple explained examples of using Bison.
  694. -
  695. -Reference sections:
  696. -* Grammar File::      Writing Bison declarations and rules.
  697. -* Interface::         C-language interface to the parser function `yyparse'.
  698. -* Algorithm::         How the Bison parser works at run-time.
  699. -* Error Recovery::    Writing rules for error recovery.
  700. -* Context Dependency::  What to do if your language syntax is too
  701. -                        messy for Bison to handle straightforwardly.
  702. -* Debugging::         Debugging Bison parsers that parse wrong.
  703. -* Invocation::        How to run Bison (to produce the parser source file).
  704. -* Table of Symbols::  All the keywords of the Bison language are explained.
  705. -* Glossary::          Basic concepts are explained.
  706. -* Index::             Cross-references to the text.
  707. -
  708. - -- The Detailed Node Listing --
  709. -
  710. -The Concepts of Bison
  711. -
  712. -* Language and Grammar::  Languages and context-free grammars,
  713. -                            as mathematical ideas.
  714. -* Grammar in Bison::  How we represent grammars for Bison's sake.
  715. -* Semantic Values::   Each token or syntactic grouping can have
  716. -                        a semantic value (the value of an integer,
  717. -                        the name of an identifier, etc.).
  718. -* Semantic Actions::  Each rule can have an action containing C code.
  719. -* Bison Parser::      What are Bison's input and output,
  720. -                        how is the output used?
  721. -* Stages::            Stages in writing and running Bison grammars.
  722. -* Grammar Layout::    Overall structure of a Bison grammar file.
  723. -
  724. -Examples
  725. -
  726. -* RPN Calc::          Reverse polish notation calculator;
  727. -                        a first example with no operator precedence.
  728. -* Infix Calc::        Infix (algebraic) notation calculator.
  729. -                        Operator precedence is introduced.
  730. -* Simple Error Recovery::  Continuing after syntax errors.
  731. -* Multi-function Calc::    Calculator with memory and trig functions.
  732. -                        It uses multiple data-types for semantic values.
  733. -* Exercises::         Ideas for improving the multi-function calculator.
  734. -
  735. -Reverse Polish Notation Calculator
  736. -
  737. -* Decls: Rpcalc Decls.  Bison and C declarations for rpcalc.
  738. -* Rules: Rpcalc Rules.  Grammar Rules for rpcalc, with explanation.
  739. -* Lexer: Rpcalc Lexer.  The lexical analyzer.
  740. -* Main: Rpcalc Main.    The controlling function.
  741. -* Error: Rpcalc Error.  The error reporting function.
  742. -* Gen: Rpcalc Gen.      Running Bison on the grammar file.
  743. -* Comp: Rpcalc Compile. Run the C compiler on the output code.
  744. -
  745. -Grammar Rules for `rpcalc'
  746. -
  747. -* Rpcalc Input::
  748. -* Rpcalc Line::
  749. -* Rpcalc Expr::
  750. -
  751. -Multi-Function Calculator: `mfcalc'
  752. -
  753. -* Decl: Mfcalc Decl.      Bison declarations for multi-function calculator.
  754. -* Rules: Mfcalc Rules.    Grammar rules for the calculator.
  755. -* Symtab: Mfcalc Symtab.  Symbol table management subroutines.
  756. -
  757. -Bison Grammar Files
  758. -
  759. -* Grammar Outline::   Overall layout of the grammar file.
  760. -* Symbols::           Terminal and nonterminal symbols.
  761. -* Rules::             How to write grammar rules.
  762. -* Recursion::         Writing recursive rules.
  763. -* Semantics::         Semantic values and actions.
  764. -* Declarations::      All kinds of Bison declarations are described here.
  765. -* Multiple Parsers::  Putting more than one Bison parser in one program.
  766. -
  767. -Outline of a Bison Grammar
  768. -
  769. -* C Declarations::    Syntax and usage of the C declarations section.
  770. -* Bison Declarations::  Syntax and usage of the Bison declarations section.
  771. -* Grammar Rules::     Syntax and usage of the grammar rules section.
  772. -* C Code::            Syntax and usage of the additional C code section.
  773. -
  774. -Defining Language Semantics
  775. -
  776. -* Value Type::        Specifying one data type for all semantic values.
  777. -* Multiple Types::    Specifying several alternative data types.
  778. -* Actions::           An action is the semantic definition of a grammar rule.
  779. -* Action Types::      Specifying data types for actions to operate on.
  780. -* Mid-Rule Actions::  Most actions go at the end of a rule.
  781. -                      This says when, why and how to use the exceptional
  782. -                        action in the middle of a rule.
  783. -
  784. -Bison Declarations
  785. -
  786. -* Token Decl::        Declaring terminal symbols.
  787. -* Precedence Decl::   Declaring terminals with precedence and associativity.
  788. -* Union Decl::        Declaring the set of all semantic value types.
  789. -* Type Decl::         Declaring the choice of type for a nonterminal symbol.
  790. -* Expect Decl::       Suppressing warnings about shift/reduce conflicts.
  791. -* Start Decl::        Specifying the start symbol.
  792. -* Pure Decl::         Requesting a reentrant parser.
  793. -* Decl Summary::      Table of all Bison declarations.
  794. -
  795. -Parser C-Language Interface
  796. -
  797. -* Parser Function::   How to call `yyparse' and what it returns.
  798. -* Lexical::           You must supply a function `yylex'
  799. -                        which reads tokens.
  800. -* Error Reporting::   You must supply a function `yyerror'.
  801. -* Action Features::   Special features for use in actions.
  802. -
  803. -The Lexical Analyzer Function `yylex'
  804. -
  805. -* Calling Convention::  How `yyparse' calls `yylex'.
  806. -* Token Values::      How `yylex' must return the semantic value
  807. -                        of the token it has read.
  808. -* Token Positions::   How `yylex' must return the text position
  809. -                        (line number, etc.) of the token, if the
  810. -                         actions want that.
  811. -* Pure Calling::      How the calling convention differs
  812. -                        in a pure parser (*note A Pure (Reentrant) Parser: Pure Decl.).
  813. -
  814. -The Bison Parser Algorithm
  815. -
  816. -* Look-Ahead::        Parser looks one token ahead when deciding what to do.
  817. -* Shift/Reduce::      Conflicts: when either shifting or reduction is valid.
  818. -* Precedence::        Operator precedence works by resolving conflicts.
  819. -* Contextual Precedence::  When an operator's precedence depends on context.
  820. -* Parser States::     The parser is a finite-state-machine with stack.
  821. -* Reduce/Reduce::     When two rules are applicable in the same situation.
  822. -* Mystery Conflicts::  Reduce/reduce conflicts that look unjustified.
  823. -* Stack Overflow::    What happens when stack gets full.  How to avoid it.
  824. -
  825. -Operator Precedence
  826. -
  827. -* Why Precedence::    An example showing why precedence is needed.
  828. -* Using Precedence::  How to specify precedence in Bison grammars.
  829. -* Precedence Examples::  How these features are used in the previous example.
  830. -* How Precedence::    How they work.
  831. -
  832. -Handling Context Dependencies
  833. -
  834. -* Semantic Tokens::   Token parsing can depend on the semantic context.
  835. -* Lexical Tie-ins::   Token parsing can depend on the syntactic context.
  836. -* Tie-in Recovery::   Lexical tie-ins have implications for how
  837. -                        error recovery rules must be written.
  838. -
  839. -Invoking Bison
  840. -
  841. -* Bison Options::     All the options described in detail,
  842. -            in alphabetical order by short options.
  843. -* Option Cross Key::  Alphabetical list of long options.
  844. -* VMS Invocation::    Bison command syntax on VMS.
  845. -
  846. -
  847. -File: bison.info,  Node: Introduction,  Next: Conditions,  Prev: Top,  Up: Top
  848. -
  849. -Introduction
  850. -************
  851. -
  852. -   "Bison" is a general-purpose parser generator that converts a
  853. -grammar description for an LALR(1) context-free grammar into a C
  854. -program to parse that grammar.  Once you are proficient with Bison, you
  855. -may use it to develop a wide range of language parsers, from those used
  856. -in simple desk calculators to complex programming languages.
  857. -
  858. -   Bison is upward compatible with Yacc: all properly-written Yacc
  859. -grammars ought to work with Bison with no change.  Anyone familiar with
  860. -Yacc should be able to use Bison with little trouble.  You need to be
  861. -fluent in C programming in order to use Bison or to understand this
  862. -manual.
  863. -
  864. -   We begin with tutorial chapters that explain the basic concepts of
  865. -using Bison and show three explained examples, each building on the
  866. -last.  If you don't know Bison or Yacc, start by reading these
  867. -chapters.  Reference chapters follow which describe specific aspects of
  868. -Bison in detail.
  869. -
  870. -   Bison was written primarily by Robert Corbett; Richard Stallman made
  871. -it Yacc-compatible.  Wilfred Hansen of Carnegie Mellon University added
  872. -multicharacter string literals and other features.
  873. -
  874. -   This edition corresponds to version 1.25 of Bison.
  875. -
  876. -
  877. -File: bison.info,  Node: Conditions,  Next: Copying,  Prev: Introduction,  Up: Top
  878. -
  879. -Conditions for Using Bison
  880. -**************************
  881. -
  882. -   As of Bison version 1.24, we have changed the distribution terms for
  883. -`yyparse' to permit using Bison's output in non-free programs.
  884. -Formerly, Bison parsers could be used only in programs that were free
  885. -software.
  886. -
  887. -   The other GNU programming tools, such as the GNU C compiler, have
  888. -never had such a requirement.  They could always be used for non-free
  889. -software.  The reason Bison was different was not due to a special
  890. -policy decision; it resulted from applying the usual General Public
  891. -License to all of the Bison source code.
  892. -
  893. -   The output of the Bison utility--the Bison parser file--contains a
  894. -verbatim copy of a sizable piece of Bison, which is the code for the
  895. -`yyparse' function.  (The actions from your grammar are inserted into
  896. -this function at one point, but the rest of the function is not
  897. -changed.)  When we applied the GPL terms to the code for `yyparse', the
  898. -effect was to restrict the use of Bison output to free software.
  899. -
  900. -   We didn't change the terms because of sympathy for people who want to
  901. -make software proprietary.  *Software should be free.*  But we
  902. -concluded that limiting Bison's use to free software was doing little to
  903. -encourage people to make other software free.  So we decided to make the
  904. -practical conditions for using Bison match the practical conditions for
  905. -using the other GNU tools.
  906. -
  907. -
  908. -File: bison.info,  Node: Copying,  Next: Concepts,  Prev: Conditions,  Up: Top
  909. -
  910. -GNU GENERAL PUBLIC LICENSE
  911. -**************************
  912. -
  913. -                         Version 2, June 1991
  914. -
  915. -     Copyright (C) 1989, 1991 Free Software Foundation, Inc.
  916. -     675 Mass Ave, Cambridge, MA 02139, USA
  917. -     
  918. -     Everyone is permitted to copy and distribute verbatim copies
  919. -     of this license document, but changing it is not allowed.
  920. -
  921. -Preamble
  922. -========
  923. -
  924. -   The licenses for most software are designed to take away your
  925. -freedom to share and change it.  By contrast, the GNU General Public
  926. -License is intended to guarantee your freedom to share and change free
  927. -software--to make sure the software is free for all its users.  This
  928. -General Public License applies to most of the Free Software
  929. -Foundation's software and to any other program whose authors commit to
  930. -using it.  (Some other Free Software Foundation software is covered by
  931. -the GNU Library General Public License instead.)  You can apply it to
  932. -your programs, too.
  933. -
  934. -   When we speak of free software, we are referring to freedom, not
  935. -price.  Our General Public Licenses are designed to make sure that you
  936. -have the freedom to distribute copies of free software (and charge for
  937. -this service if you wish), that you receive source code or can get it
  938. -if you want it, that you can change the software or use pieces of it in
  939. -new free programs; and that you know you can do these things.
  940. -
  941. -   To protect your rights, we need to make restrictions that forbid
  942. -anyone to deny you these rights or to ask you to surrender the rights.
  943. -These restrictions translate to certain responsibilities for you if you
  944. -distribute copies of the software, or if you modify it.
  945. -
  946. -   For example, if you distribute copies of such a program, whether
  947. -gratis or for a fee, you must give the recipients all the rights that
  948. -you have.  You must make sure that they, too, receive or can get the
  949. -source code.  And you must show them these terms so they know their
  950. -rights.
  951. -
  952. -   We protect your rights with two steps: (1) copyright the software,
  953. -and (2) offer you this license which gives you legal permission to copy,
  954. -distribute and/or modify the software.
  955. -
  956. -   Also, for each author's protection and ours, we want to make certain
  957. -that everyone understands that there is no warranty for this free
  958. -software.  If the software is modified by someone else and passed on, we
  959. -want its recipients to know that what they have is not the original, so
  960. -that any problems introduced by others will not reflect on the original
  961. -authors' reputations.
  962. -
  963. -   Finally, any free program is threatened constantly by software
  964. -patents.  We wish to avoid the danger that redistributors of a free
  965. -program will individually obtain patent licenses, in effect making the
  966. -program proprietary.  To prevent this, we have made it clear that any
  967. -patent must be licensed for everyone's free use or not licensed at all.
  968. -
  969. -   The precise terms and conditions for copying, distribution and
  970. -modification follow.
  971. -
  972. -    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
  973. -
  974. -  0. This License applies to any program or other work which contains a
  975. -     notice placed by the copyright holder saying it may be distributed
  976. -     under the terms of this General Public License.  The "Program",
  977. -     below, refers to any such program or work, and a "work based on
  978. -     the Program" means either the Program or any derivative work under
  979. -     copyright law: that is to say, a work containing the Program or a
  980. -     portion of it, either verbatim or with modifications and/or
  981. -     translated into another language.  (Hereinafter, translation is
  982. -     included without limitation in the term "modification".)  Each
  983. -     licensee is addressed as "you".
  984. -
  985. -     Activities other than copying, distribution and modification are
  986. -     not covered by this License; they are outside its scope.  The act
  987. -     of running the Program is not restricted, and the output from the
  988. -     Program is covered only if its contents constitute a work based on
  989. -     the Program (independent of having been made by running the
  990. -     Program).  Whether that is true depends on what the Program does.
  991. -
  992. -  1. You may copy and distribute verbatim copies of the Program's
  993. -     source code as you receive it, in any medium, provided that you
  994. -     conspicuously and appropriately publish on each copy an appropriate
  995. -     copyright notice and disclaimer of warranty; keep intact all the
  996. -     notices that refer to this License and to the absence of any
  997. -     warranty; and give any other recipients of the Program a copy of
  998. -     this License along with the Program.
  999. -
  1000. -     You may charge a fee for the physical act of transferring a copy,
  1001. -     and you may at your option offer warranty protection in exchange
  1002. -     for a fee.
  1003. -
  1004. -  2. You may modify your copy or copies of the Program or any portion
  1005. -     of it, thus forming a work based on the Program, and copy and
  1006. -     distribute such modifications or work under the terms of Section 1
  1007. -     above, provided that you also meet all of these conditions:
  1008. -
  1009. -       a. You must cause the modified files to carry prominent notices
  1010. -          stating that you changed the files and the date of any change.
  1011. -
  1012. -       b. You must cause any work that you distribute or publish, that
  1013. -          in whole or in part contains or is derived from the Program
  1014. -          or any part thereof, to be licensed as a whole at no charge
  1015. -          to all third parties under the terms of this License.
  1016. -
  1017. -       c. If the modified program normally reads commands interactively
  1018. -          when run, you must cause it, when started running for such
  1019. -          interactive use in the most ordinary way, to print or display
  1020. -          an announcement including an appropriate copyright notice and
  1021. -          a notice that there is no warranty (or else, saying that you
  1022. -          provide a warranty) and that users may redistribute the
  1023. -          program under these conditions, and telling the user how to
  1024. -          view a copy of this License.  (Exception: if the Program
  1025. -          itself is interactive but does not normally print such an
  1026. -          announcement, your work based on the Program is not required
  1027. -          to print an announcement.)
  1028. -
  1029. -     These requirements apply to the modified work as a whole.  If
  1030. -     identifiable sections of that work are not derived from the
  1031. -     Program, and can be reasonably considered independent and separate
  1032. -     works in themselves, then this License, and its terms, do not
  1033. -     apply to those sections when you distribute them as separate
  1034. -     works.  But when you distribute the same sections as part of a
  1035. -     whole which is a work based on the Program, the distribution of
  1036. -     the whole must be on the terms of this License, whose permissions
  1037. -     for other licensees extend to the entire whole, and thus to each
  1038. -     and every part regardless of who wrote it.
  1039. -
  1040. -     Thus, it is not the intent of this section to claim rights or
  1041. -     contest your rights to work written entirely by you; rather, the
  1042. -     intent is to exercise the right to control the distribution of
  1043. -     derivative or collective works based on the Program.
  1044. -
  1045. -     In addition, mere aggregation of another work not based on the
  1046. -     Program with the Program (or with a work based on the Program) on
  1047. -     a volume of a storage or distribution medium does not bring the
  1048. -     other work under the scope of this License.
  1049. -
  1050. -  3. You may copy and distribute the Program (or a work based on it,
  1051. -     under Section 2) in object code or executable form under the terms
  1052. -     of Sections 1 and 2 above provided that you also do one of the
  1053. -     following:
  1054. -
  1055. -       a. Accompany it with the complete corresponding machine-readable
  1056. -          source code, which must be distributed under the terms of
  1057. -          Sections 1 and 2 above on a medium customarily used for
  1058. -          software interchange; or,
  1059. -
  1060. -       b. Accompany it with a written offer, valid for at least three
  1061. -          years, to give any third party, for a charge no more than your
  1062. -          cost of physically performing source distribution, a complete
  1063. -          machine-readable copy of the corresponding source code, to be
  1064. -          distributed under the terms of Sections 1 and 2 above on a
  1065. -          medium customarily used for software interchange; or,
  1066. -
  1067. -       c. Accompany it with the information you received as to the offer
  1068. -          to distribute corresponding source code.  (This alternative is
  1069. -          allowed only for noncommercial distribution and only if you
  1070. -          received the program in object code or executable form with
  1071. -          such an offer, in accord with Subsection b above.)
  1072. -
  1073. -     The source code for a work means the preferred form of the work for
  1074. -     making modifications to it.  For an executable work, complete
  1075. -     source code means all the source code for all modules it contains,
  1076. -     plus any associated interface definition files, plus the scripts
  1077. -     used to control compilation and installation of the executable.
  1078. -     However, as a special exception, the source code distributed need
  1079. -     not include anything that is normally distributed (in either
  1080. -     source or binary form) with the major components (compiler,
  1081. -     kernel, and so on) of the operating system on which the executable
  1082. -     runs, unless that component itself accompanies the executable.
  1083. -
  1084. -     If distribution of executable or object code is made by offering
  1085. -     access to copy from a designated place, then offering equivalent
  1086. -     access to copy the source code from the same place counts as
  1087. -     distribution of the source code, even though third parties are not
  1088. -     compelled to copy the source along with the object code.
  1089. -
  1090. -  4. You may not copy, modify, sublicense, or distribute the Program
  1091. -     except as expressly provided under this License.  Any attempt
  1092. -     otherwise to copy, modify, sublicense or distribute the Program is
  1093. -     void, and will automatically terminate your rights under this
  1094. -     License.  However, parties who have received copies, or rights,
  1095. -     from you under this License will not have their licenses
  1096. -     terminated so long as such parties remain in full compliance.
  1097. -
  1098. -  5. You are not required to accept this License, since you have not
  1099. -     signed it.  However, nothing else grants you permission to modify
  1100. -     or distribute the Program or its derivative works.  These actions
  1101. -     are prohibited by law if you do not accept this License.
  1102. -     Therefore, by modifying or distributing the Program (or any work
  1103. -     based on the Program), you indicate your acceptance of this
  1104. -     License to do so, and all its terms and conditions for copying,
  1105. -     distributing or modifying the Program or works based on it.
  1106. -
  1107. -  6. Each time you redistribute the Program (or any work based on the
  1108. -     Program), the recipient automatically receives a license from the
  1109. -     original licensor to copy, distribute or modify the Program
  1110. -     subject to these terms and conditions.  You may not impose any
  1111. -     further restrictions on the recipients' exercise of the rights
  1112. -     granted herein.  You are not responsible for enforcing compliance
  1113. -     by third parties to this License.
  1114. -
  1115. -  7. If, as a consequence of a court judgment or allegation of patent
  1116. -     infringement or for any other reason (not limited to patent
  1117. -     issues), conditions are imposed on you (whether by court order,
  1118. -     agreement or otherwise) that contradict the conditions of this
  1119. -     License, they do not excuse you from the conditions of this
  1120. -     License.  If you cannot distribute so as to satisfy simultaneously
  1121. -     your obligations under this License and any other pertinent
  1122. -     obligations, then as a consequence you may not distribute the
  1123. -     Program at all.  For example, if a patent license would not permit
  1124. -     royalty-free redistribution of the Program by all those who
  1125. -     receive copies directly or indirectly through you, then the only
  1126. -     way you could satisfy both it and this License would be to refrain
  1127. -     entirely from distribution of the Program.
  1128. -
  1129. -     If any portion of this section is held invalid or unenforceable
  1130. -     under any particular circumstance, the balance of the section is
  1131. -     intended to apply and the section as a whole is intended to apply
  1132. -     in other circumstances.
  1133. -
  1134. -     It is not the purpose of this section to induce you to infringe any
  1135. -     patents or other property right claims or to contest validity of
  1136. -     any such claims; this section has the sole purpose of protecting
  1137. -     the integrity of the free software distribution system, which is
  1138. -     implemented by public license practices.  Many people have made
  1139. -     generous contributions to the wide range of software distributed
  1140. -     through that system in reliance on consistent application of that
  1141. -     system; it is up to the author/donor to decide if he or she is
  1142. -     willing to distribute software through any other system and a
  1143. -     licensee cannot impose that choice.
  1144. -
  1145. -     This section is intended to make thoroughly clear what is believed
  1146. -     to be a consequence of the rest of this License.
  1147. -
  1148. -  8. If the distribution and/or use of the Program is restricted in
  1149. -     certain countries either by patents or by copyrighted interfaces,
  1150. -     the original copyright holder who places the Program under this
  1151. -     License may add an explicit geographical distribution limitation
  1152. -     excluding those countries, so that distribution is permitted only
  1153. -     in or among countries not thus excluded.  In such case, this
  1154. -     License incorporates the limitation as if written in the body of
  1155. -     this License.
  1156. -
  1157. -  9. The Free Software Foundation may publish revised and/or new
  1158. -     versions of the General Public License from time to time.  Such
  1159. -     new versions will be similar in spirit to the present version, but
  1160. -     may differ in detail to address new problems or concerns.
  1161. -
  1162. -     Each version is given a distinguishing version number.  If the
  1163. -     Program specifies a version number of this License which applies
  1164. -     to it and "any later version", you have the option of following
  1165. -     the terms and conditions either of that version or of any later
  1166. -     version published by the Free Software Foundation.  If the Program
  1167. -     does not specify a version number of this License, you may choose
  1168. -     any version ever published by the Free Software Foundation.
  1169. -
  1170. - 10. If you wish to incorporate parts of the Program into other free
  1171. -     programs whose distribution conditions are different, write to the
  1172. -     author to ask for permission.  For software which is copyrighted
  1173. -     by the Free Software Foundation, write to the Free Software
  1174. -     Foundation; we sometimes make exceptions for this.  Our decision
  1175. -     will be guided by the two goals of preserving the free status of
  1176. -     all derivatives of our free software and of promoting the sharing
  1177. -     and reuse of software generally.
  1178. -
  1179. -                                NO WARRANTY
  1180. -
  1181. - 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
  1182. -     WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
  1183. -     LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
  1184. -     HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
  1185. -     WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
  1186. -     NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
  1187. -     FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE
  1188. -     QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
  1189. -     PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
  1190. -     SERVICING, REPAIR OR CORRECTION.
  1191. -
  1192. - 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
  1193. -     WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
  1194. -     MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
  1195. -     LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
  1196. -     INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
  1197. -     INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
  1198. -     DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
  1199. -     OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
  1200. -     OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
  1201. -     ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
  1202. -
  1203. -                      END OF TERMS AND CONDITIONS
  1204. -
  1205. -How to Apply These Terms to Your New Programs
  1206. -=============================================
  1207. -
  1208. -   If you develop a new program, and you want it to be of the greatest
  1209. -possible use to the public, the best way to achieve this is to make it
  1210. -free software which everyone can redistribute and change under these
  1211. -terms.
  1212. -
  1213. -   To do so, attach the following notices to the program.  It is safest
  1214. -to attach them to the start of each source file to most effectively
  1215. -convey the exclusion of warranty; and each file should have at least
  1216. -the "copyright" line and a pointer to where the full notice is found.
  1217. -
  1218. -     ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
  1219. -     Copyright (C) 19YY  NAME OF AUTHOR
  1220. -     
  1221. -     This program is free software; you can redistribute it and/or modify
  1222. -     it under the terms of the GNU General Public License as published by
  1223. -     the Free Software Foundation; either version 2 of the License, or
  1224. -     (at your option) any later version.
  1225. -     
  1226. -     This program is distributed in the hope that it will be useful,
  1227. -     but WITHOUT ANY WARRANTY; without even the implied warranty of
  1228. -     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  1229. -     GNU General Public License for more details.
  1230. -     
  1231. -     You should have received a copy of the GNU General Public License
  1232. -     along with this program; if not, write to the Free Software
  1233. -     Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  1234. -
  1235. -   Also add information on how to contact you by electronic and paper
  1236. -mail.
  1237. -
  1238. -   If the program is interactive, make it output a short notice like
  1239. -this when it starts in an interactive mode:
  1240. -
  1241. -     Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR
  1242. -     Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
  1243. -     type `show w'.
  1244. -     This is free software, and you are welcome to redistribute it
  1245. -     under certain conditions; type `show c' for details.
  1246. -
  1247. -   The hypothetical commands `show w' and `show c' should show the
  1248. -appropriate parts of the General Public License.  Of course, the
  1249. -commands you use may be called something other than `show w' and `show
  1250. -c'; they could even be mouse-clicks or menu items--whatever suits your
  1251. -program.
  1252. -
  1253. -   You should also get your employer (if you work as a programmer) or
  1254. -your school, if any, to sign a "copyright disclaimer" for the program,
  1255. -if necessary.  Here is a sample; alter the names:
  1256. -
  1257. -     Yoyodyne, Inc., hereby disclaims all copyright interest in the program
  1258. -     `Gnomovision' (which makes passes at compilers) written by James Hacker.
  1259. -     
  1260. -     SIGNATURE OF TY COON, 1 April 1989
  1261. -     Ty Coon, President of Vice
  1262. -
  1263. -   This General Public License does not permit incorporating your
  1264. -program into proprietary programs.  If your program is a subroutine
  1265. -library, you may consider it more useful to permit linking proprietary
  1266. -applications with the library.  If this is what you want to do, use the
  1267. -GNU Library General Public License instead of this License.
  1268. -
  1269. -
  1270. -File: bison.info,  Node: Concepts,  Next: Examples,  Prev: Copying,  Up: Top
  1271. -
  1272. -The Concepts of Bison
  1273. -*********************
  1274. -
  1275. -   This chapter introduces many of the basic concepts without which the
  1276. -details of Bison will not make sense.  If you do not already know how to
  1277. -use Bison or Yacc, we suggest you start by reading this chapter
  1278. -carefully.
  1279. -
  1280. -* Menu:
  1281. -
  1282. -* Language and Grammar::  Languages and context-free grammars,
  1283. -                            as mathematical ideas.
  1284. -* Grammar in Bison::  How we represent grammars for Bison's sake.
  1285. -* Semantic Values::   Each token or syntactic grouping can have
  1286. -                        a semantic value (the value of an integer,
  1287. -                        the name of an identifier, etc.).
  1288. -* Semantic Actions::  Each rule can have an action containing C code.
  1289. -* Bison Parser::      What are Bison's input and output,
  1290. -                        how is the output used?
  1291. -* Stages::            Stages in writing and running Bison grammars.
  1292. -* Grammar Layout::    Overall structure of a Bison grammar file.
  1293. -
  1294. -
  1295. -File: bison.info,  Node: Language and Grammar,  Next: Grammar in Bison,  Up: Concepts
  1296. -
  1297. -Languages and Context-Free Grammars
  1298. -===================================
  1299. -
  1300. -   In order for Bison to parse a language, it must be described by a
  1301. -"context-free grammar".  This means that you specify one or more
  1302. -"syntactic groupings" and give rules for constructing them from their
  1303. -parts.  For example, in the C language, one kind of grouping is called
  1304. -an `expression'.  One rule for making an expression might be, "An
  1305. -expression can be made of a minus sign and another expression".
  1306. -Another would be, "An expression can be an integer".  As you can see,
  1307. -rules are often recursive, but there must be at least one rule which
  1308. -leads out of the recursion.
  1309. -
  1310. -   The most common formal system for presenting such rules for humans
  1311. -to read is "Backus-Naur Form" or "BNF", which was developed in order to
  1312. -specify the language Algol 60.  Any grammar expressed in BNF is a
  1313. -context-free grammar.  The input to Bison is essentially
  1314. -machine-readable BNF.
  1315. -
  1316. -   Not all context-free languages can be handled by Bison, only those
  1317. -that are LALR(1).  In brief, this means that it must be possible to
  1318. -tell how to parse any portion of an input string with just a single
  1319. -token of look-ahead.  Strictly speaking, that is a description of an
  1320. -LR(1) grammar, and LALR(1) involves additional restrictions that are
  1321. -hard to explain simply; but it is rare in actual practice to find an
  1322. -LR(1) grammar that fails to be LALR(1).  *Note Mysterious Reduce/Reduce
  1323. -Conflicts: Mystery Conflicts, for more information on this.
  1324. -
  1325. -   In the formal grammatical rules for a language, each kind of
  1326. -syntactic unit or grouping is named by a "symbol".  Those which are
  1327. -built by grouping smaller constructs according to grammatical rules are
  1328. -called "nonterminal symbols"; those which can't be subdivided are called
  1329. -"terminal symbols" or "token types".  We call a piece of input
  1330. -corresponding to a single terminal symbol a "token", and a piece
  1331. -corresponding to a single nonterminal symbol a "grouping".
  1332. -
  1333. -   We can use the C language as an example of what symbols, terminal and
  1334. -nonterminal, mean.  The tokens of C are identifiers, constants (numeric
  1335. -and string), and the various keywords, arithmetic operators and
  1336. -punctuation marks.  So the terminal symbols of a grammar for C include
  1337. -`identifier', `number', `string', plus one symbol for each keyword,
  1338. -operator or punctuation mark: `if', `return', `const', `static', `int',
  1339. -`char', `plus-sign', `open-brace', `close-brace', `comma' and many
  1340. -more.  (These tokens can be subdivided into characters, but that is a
  1341. -matter of lexicography, not grammar.)
  1342. -
  1343. -   Here is a simple C function subdivided into tokens:
  1344. -
  1345. -     int             /* keyword `int' */
  1346. -     square (x)      /* identifier, open-paren, */
  1347. -                     /* identifier, close-paren */
  1348. -          int x;     /* keyword `int', identifier, semicolon */
  1349. -     {               /* open-brace */
  1350. -       return x * x; /* keyword `return', identifier, */
  1351. -                     /* asterisk, identifier, semicolon */
  1352. -     }               /* close-brace */
  1353. -
  1354. -   The syntactic groupings of C include the expression, the statement,
  1355. -the declaration, and the function definition.  These are represented in
  1356. -the grammar of C by nonterminal symbols `expression', `statement',
  1357. -`declaration' and `function definition'.  The full grammar uses dozens
  1358. -of additional language constructs, each with its own nonterminal
  1359. -symbol, in order to express the meanings of these four.  The example
  1360. -above is a function definition; it contains one declaration, and one
  1361. -statement.  In the statement, each `x' is an expression and so is `x *
  1362. -x'.
  1363. -
  1364. -   Each nonterminal symbol must have grammatical rules showing how it
  1365. -is made out of simpler constructs.  For example, one kind of C
  1366. -statement is the `return' statement; this would be described with a
  1367. -grammar rule which reads informally as follows:
  1368. -
  1369. -     A `statement' can be made of a `return' keyword, an `expression'
  1370. -     and a `semicolon'.
  1371. -
  1372. -There would be many other rules for `statement', one for each kind of
  1373. -statement in C.
  1374. -
  1375. -   One nonterminal symbol must be distinguished as the special one which
  1376. -defines a complete utterance in the language.  It is called the "start
  1377. -symbol".  In a compiler, this means a complete input program.  In the C
  1378. -language, the nonterminal symbol `sequence of definitions and
  1379. -declarations' plays this role.
  1380. -
  1381. -   For example, `1 + 2' is a valid C expression--a valid part of a C
  1382. -program--but it is not valid as an *entire* C program.  In the
  1383. -context-free grammar of C, this follows from the fact that `expression'
  1384. -is not the start symbol.
  1385. -
  1386. -   The Bison parser reads a sequence of tokens as its input, and groups
  1387. -the tokens using the grammar rules.  If the input is valid, the end
  1388. -result is that the entire token sequence reduces to a single grouping
  1389. -whose symbol is the grammar's start symbol.  If we use a grammar for C,
  1390. -the entire input must be a `sequence of definitions and declarations'.
  1391. -If not, the parser reports a syntax error.
  1392. -
  1393. -
  1394. -File: bison.info,  Node: Grammar in Bison,  Next: Semantic Values,  Prev: Language and Grammar,  Up: Concepts
  1395. -
  1396. -From Formal Rules to Bison Input
  1397. -================================
  1398. -
  1399. -   A formal grammar is a mathematical construct.  To define the language
  1400. -for Bison, you must write a file expressing the grammar in Bison syntax:
  1401. -a "Bison grammar" file.  *Note Bison Grammar Files: Grammar File.
  1402. -
  1403. -   A nonterminal symbol in the formal grammar is represented in Bison
  1404. -input as an identifier, like an identifier in C.  By convention, it
  1405. -should be in lower case, such as `expr', `stmt' or `declaration'.
  1406. -
  1407. -   The Bison representation for a terminal symbol is also called a
  1408. -"token type".  Token types as well can be represented as C-like
  1409. -identifiers.  By convention, these identifiers should be upper case to
  1410. -distinguish them from nonterminals: for example, `INTEGER',
  1411. -`IDENTIFIER', `IF' or `RETURN'.  A terminal symbol that stands for a
  1412. -particular keyword in the language should be named after that keyword
  1413. -converted to upper case.  The terminal symbol `error' is reserved for
  1414. -error recovery.  *Note Symbols::.
  1415. -
  1416. -   A terminal symbol can also be represented as a character literal,
  1417. -just like a C character constant.  You should do this whenever a token
  1418. -is just a single character (parenthesis, plus-sign, etc.): use that
  1419. -same character in a literal as the terminal symbol for that token.
  1420. -
  1421. -   A third way to represent a terminal symbol is with a C string
  1422. -constant containing several characters.  *Note Symbols::, for more
  1423. -information.
  1424. -
  1425. -   The grammar rules also have an expression in Bison syntax.  For
  1426. -example, here is the Bison rule for a C `return' statement.  The
  1427. -semicolon in quotes is a literal character token, representing part of
  1428. -the C syntax for the statement; the naked semicolon, and the colon, are
  1429. -Bison punctuation used in every rule.
  1430. -
  1431. -     stmt:   RETURN expr ';'
  1432. -             ;
  1433. -
  1434. -*Note Syntax of Grammar Rules: Rules.
  1435. -
  1436. -
  1437. -File: bison.info,  Node: Semantic Values,  Next: Semantic Actions,  Prev: Grammar in Bison,  Up: Concepts
  1438. -
  1439. -Semantic Values
  1440. -===============
  1441. -
  1442. -   A formal grammar selects tokens only by their classifications: for
  1443. -example, if a rule mentions the terminal symbol `integer constant', it
  1444. -means that *any* integer constant is grammatically valid in that
  1445. -position.  The precise value of the constant is irrelevant to how to
  1446. -parse the input: if `x+4' is grammatical then `x+1' or `x+3989' is
  1447. -equally grammatical.
  1448. -
  1449. -   But the precise value is very important for what the input means
  1450. -once it is parsed.  A compiler is useless if it fails to distinguish
  1451. -between 4, 1 and 3989 as constants in the program!  Therefore, each
  1452. -token in a Bison grammar has both a token type and a "semantic value".
  1453. -*Note Defining Language Semantics: Semantics, for details.
  1454. -
  1455. -   The token type is a terminal symbol defined in the grammar, such as
  1456. -`INTEGER', `IDENTIFIER' or `',''.  It tells everything you need to know
  1457. -to decide where the token may validly appear and how to group it with
  1458. -other tokens.  The grammar rules know nothing about tokens except their
  1459. -types.
  1460. -
  1461. -   The semantic value has all the rest of the information about the
  1462. -meaning of the token, such as the value of an integer, or the name of an
  1463. -identifier.  (A token such as `','' which is just punctuation doesn't
  1464. -need to have any semantic value.)
  1465. -
  1466. -   For example, an input token might be classified as token type
  1467. -`INTEGER' and have the semantic value 4.  Another input token might
  1468. -have the same token type `INTEGER' but value 3989.  When a grammar rule
  1469. -says that `INTEGER' is allowed, either of these tokens is acceptable
  1470. -because each is an `INTEGER'.  When the parser accepts the token, it
  1471. -keeps track of the token's semantic value.
  1472. -
  1473. -   Each grouping can also have a semantic value as well as its
  1474. -nonterminal symbol.  For example, in a calculator, an expression
  1475. -typically has a semantic value that is a number.  In a compiler for a
  1476. -programming language, an expression typically has a semantic value that
  1477. -is a tree structure describing the meaning of the expression.
  1478. -
  1479. -
  1480. -File: bison.info,  Node: Semantic Actions,  Next: Bison Parser,  Prev: Semantic Values,  Up: Concepts
  1481. -
  1482. -Semantic Actions
  1483. -================
  1484. -
  1485. -   In order to be useful, a program must do more than parse input; it
  1486. -must also produce some output based on the input.  In a Bison grammar,
  1487. -a grammar rule can have an "action" made up of C statements.  Each time
  1488. -the parser recognizes a match for that rule, the action is executed.
  1489. -*Note Actions::.
  1490. -
  1491. -   Most of the time, the purpose of an action is to compute the
  1492. -semantic value of the whole construct from the semantic values of its
  1493. -parts.  For example, suppose we have a rule which says an expression
  1494. -can be the sum of two expressions.  When the parser recognizes such a
  1495. -sum, each of the subexpressions has a semantic value which describes
  1496. -how it was built up.  The action for this rule should create a similar
  1497. -sort of value for the newly recognized larger expression.
  1498. -
  1499. -   For example, here is a rule that says an expression can be the sum of
  1500. -two subexpressions:
  1501. -
  1502. -     expr: expr '+' expr   { $$ = $1 + $3; }
  1503. -             ;
  1504. -
  1505. -The action says how to produce the semantic value of the sum expression
  1506. -from the values of the two subexpressions.
  1507. -
  1508. -
  1509. -File: bison.info,  Node: Bison Parser,  Next: Stages,  Prev: Semantic Actions,  Up: Concepts
  1510. -
  1511. -Bison Output: the Parser File
  1512. -=============================
  1513. -
  1514. -   When you run Bison, you give it a Bison grammar file as input.  The
  1515. -output is a C source file that parses the language described by the
  1516. -grammar.  This file is called a "Bison parser".  Keep in mind that the
  1517. -Bison utility and the Bison parser are two distinct programs: the Bison
  1518. -utility is a program whose output is the Bison parser that becomes part
  1519. -of your program.
  1520. -
  1521. -   The job of the Bison parser is to group tokens into groupings
  1522. -according to the grammar rules--for example, to build identifiers and
  1523. -operators into expressions.  As it does this, it runs the actions for
  1524. -the grammar rules it uses.
  1525. -
  1526. -   The tokens come from a function called the "lexical analyzer" that
  1527. -you must supply in some fashion (such as by writing it in C).  The
  1528. -Bison parser calls the lexical analyzer each time it wants a new token.
  1529. -It doesn't know what is "inside" the tokens (though their semantic
  1530. -values may reflect this).  Typically the lexical analyzer makes the
  1531. -tokens by parsing characters of text, but Bison does not depend on
  1532. -this.  *Note The Lexical Analyzer Function `yylex': Lexical.
  1533. -
  1534. -   The Bison parser file is C code which defines a function named
  1535. -`yyparse' which implements that grammar.  This function does not make a
  1536. -complete C program: you must supply some additional functions.  One is
  1537. -the lexical analyzer.  Another is an error-reporting function which the
  1538. -parser calls to report an error.  In addition, a complete C program must
  1539. -start with a function called `main'; you have to provide this, and
  1540. -arrange for it to call `yyparse' or the parser will never run.  *Note
  1541. -Parser C-Language Interface: Interface.
  1542. -
  1543. -   Aside from the token type names and the symbols in the actions you
  1544. -write, all variable and function names used in the Bison parser file
  1545. -begin with `yy' or `YY'.  This includes interface functions such as the
  1546. -lexical analyzer function `yylex', the error reporting function
  1547. -`yyerror' and the parser function `yyparse' itself.  This also includes
  1548. -numerous identifiers used for internal purposes.  Therefore, you should
  1549. -avoid using C identifiers starting with `yy' or `YY' in the Bison
  1550. -grammar file except for the ones defined in this manual.
  1551. -
  1552. -
  1553. -File: bison.info,  Node: Stages,  Next: Grammar Layout,  Prev: Bison Parser,  Up: Concepts
  1554. -
  1555. -Stages in Using Bison
  1556. -=====================
  1557. -
  1558. -   The actual language-design process using Bison, from grammar
  1559. -specification to a working compiler or interpreter, has these parts:
  1560. -
  1561. -  1. Formally specify the grammar in a form recognized by Bison (*note
  1562. -     Bison Grammar Files: Grammar File.).  For each grammatical rule in
  1563. -     the language, describe the action that is to be taken when an
  1564. -     instance of that rule is recognized.  The action is described by a
  1565. -     sequence of C statements.
  1566. -
  1567. -  2. Write a lexical analyzer to process input and pass tokens to the
  1568. -     parser.  The lexical analyzer may be written by hand in C (*note
  1569. -     The Lexical Analyzer Function `yylex': Lexical.).  It could also
  1570. -     be produced using Lex, but the use of Lex is not discussed in this
  1571. -     manual.
  1572. -
  1573. -  3. Write a controlling function that calls the Bison-produced parser.
  1574. -
  1575. -  4. Write error-reporting routines.
  1576. -
  1577. -   To turn this source code as written into a runnable program, you
  1578. -must follow these steps:
  1579. -
  1580. -  1. Run Bison on the grammar to produce the parser.
  1581. -
  1582. -  2. Compile the code output by Bison, as well as any other source
  1583. -     files.
  1584. -
  1585. -  3. Link the object files to produce the finished product.
  1586. -
  1587. -
  1588. -File: bison.info,  Node: Grammar Layout,  Prev: Stages,  Up: Concepts
  1589. -
  1590. -The Overall Layout of a Bison Grammar
  1591. -=====================================
  1592. -
  1593. -   The input file for the Bison utility is a "Bison grammar file".  The
  1594. -general form of a Bison grammar file is as follows:
  1595. -
  1596. -     %{
  1597. -     C DECLARATIONS
  1598. -     %}
  1599. -     
  1600. -     BISON DECLARATIONS
  1601. -     
  1602. -     %%
  1603. -     GRAMMAR RULES
  1604. -     %%
  1605. -     ADDITIONAL C CODE
  1606. -
  1607. -The `%%', `%{' and `%}' are punctuation that appears in every Bison
  1608. -grammar file to separate the sections.
  1609. -
  1610. -   The C declarations may define types and variables used in the
  1611. -actions.  You can also use preprocessor commands to define macros used
  1612. -there, and use `#include' to include header files that do any of these
  1613. -things.
  1614. -
  1615. -   The Bison declarations declare the names of the terminal and
  1616. -nonterminal symbols, and may also describe operator precedence and the
  1617. -data types of semantic values of various symbols.
  1618. -
  1619. -   The grammar rules define how to construct each nonterminal symbol
  1620. -from its parts.
  1621. -
  1622. -   The additional C code can contain any C code you want to use.  Often
  1623. -the definition of the lexical analyzer `yylex' goes here, plus
  1624. -subroutines called by the actions in the grammar rules.  In a simple
  1625. -program, all the rest of the program can go here.
  1626. -
  1627. -
  1628. -File: bison.info,  Node: Examples,  Next: Grammar File,  Prev: Concepts,  Up: Top
  1629. -
  1630. -Examples
  1631. -********
  1632. -
  1633. -   Now we show and explain three sample programs written using Bison: a
  1634. -reverse polish notation calculator, an algebraic (infix) notation
  1635. -calculator, and a multi-function calculator.  All three have been tested
  1636. -under BSD Unix 4.3; each produces a usable, though limited, interactive
  1637. -desk-top calculator.
  1638. -
  1639. -   These examples are simple, but Bison grammars for real programming
  1640. -languages are written the same way.  You can copy these examples out of
  1641. -the Info file and into a source file to try them.
  1642. -
  1643. -* Menu:
  1644. -
  1645. -* RPN Calc::          Reverse polish notation calculator;
  1646. -                        a first example with no operator precedence.
  1647. -* Infix Calc::        Infix (algebraic) notation calculator.
  1648. -                        Operator precedence is introduced.
  1649. -* Simple Error Recovery::  Continuing after syntax errors.
  1650. -* Multi-function Calc::  Calculator with memory and trig functions.
  1651. -                           It uses multiple data-types for semantic values.
  1652. -* Exercises::         Ideas for improving the multi-function calculator.
  1653. -
  1654. -
  1655. -File: bison.info,  Node: RPN Calc,  Next: Infix Calc,  Up: Examples
  1656. -
  1657. -Reverse Polish Notation Calculator
  1658. -==================================
  1659. -
  1660. -   The first example is that of a simple double-precision "reverse
  1661. -polish notation" calculator (a calculator using postfix operators).
  1662. -This example provides a good starting point, since operator precedence
  1663. -is not an issue.  The second example will illustrate how operator
  1664. -precedence is handled.
  1665. -
  1666. -   The source code for this calculator is named `rpcalc.y'.  The `.y'
  1667. -extension is a convention used for Bison input files.
  1668. -
  1669. -* Menu:
  1670. -
  1671. -* Decls: Rpcalc Decls.  Bison and C declarations for rpcalc.
  1672. -* Rules: Rpcalc Rules.  Grammar Rules for rpcalc, with explanation.
  1673. -* Lexer: Rpcalc Lexer.  The lexical analyzer.
  1674. -* Main: Rpcalc Main.    The controlling function.
  1675. -* Error: Rpcalc Error.  The error reporting function.
  1676. -* Gen: Rpcalc Gen.      Running Bison on the grammar file.
  1677. -* Comp: Rpcalc Compile. Run the C compiler on the output code.
  1678. -
  1679. -
  1680. -File: bison.info,  Node: Rpcalc Decls,  Next: Rpcalc Rules,  Up: RPN Calc
  1681. -
  1682. -Declarations for `rpcalc'
  1683. --------------------------
  1684. -
  1685. -   Here are the C and Bison declarations for the reverse polish notation
  1686. -calculator.  As in C, comments are placed between `/*...*/'.
  1687. -
  1688. -     /* Reverse polish notation calculator. */
  1689. -     
  1690. -     %{
  1691. -     #define YYSTYPE double
  1692. -     #include <math.h>
  1693. -     %}
  1694. -     
  1695. -     %token NUM
  1696. -     
  1697. -     %% /* Grammar rules and actions follow */
  1698. -
  1699. -   The C declarations section (*note The C Declarations Section: C
  1700. -Declarations.) contains two preprocessor directives.
  1701. -
  1702. -   The `#define' directive defines the macro `YYSTYPE', thus specifying
  1703. -the C data type for semantic values of both tokens and groupings (*note
  1704. -Data Types of Semantic Values: Value Type.).  The Bison parser will use
  1705. -whatever type `YYSTYPE' is defined as; if you don't define it, `int' is
  1706. -the default.  Because we specify `double', each token and each
  1707. -expression has an associated value, which is a floating point number.
  1708. -
  1709. -   The `#include' directive is used to declare the exponentiation
  1710. -function `pow'.
  1711. -
  1712. -   The second section, Bison declarations, provides information to
  1713. -Bison about the token types (*note The Bison Declarations Section:
  1714. -Bison Declarations.).  Each terminal symbol that is not a
  1715. -single-character literal must be declared here.  (Single-character
  1716. -literals normally don't need to be declared.)  In this example, all the
  1717. -arithmetic operators are designated by single-character literals, so the
  1718. -only terminal symbol that needs to be declared is `NUM', the token type
  1719. -for numeric constants.
  1720. -
  1721. diff -rup --new-file baseline/fsf/bison/bison.info-2 amiga/fsf/bison/bison.info-2
  1722. --- baseline/fsf/bison/bison.info-2    Sat Feb 17 09:46:06 1996
  1723. +++ amiga/fsf/bison/bison.info-2    Wed Dec 31 17:00:00 1969
  1724. @@ -1,1333 +0,0 @@
  1725. -This is Info file bison.info, produced by Makeinfo-1.64 from the input
  1726. -file ./bison.texinfo.
  1727. -
  1728. -   This file documents the Bison parser generator.
  1729. -
  1730. -   Copyright (C) 1988, 89, 90, 91, 92, 93, 1995 Free Software
  1731. -Foundation, Inc.
  1732. -
  1733. -   Permission is granted to make and distribute verbatim copies of this
  1734. -manual provided the copyright notice and this permission notice are
  1735. -preserved on all copies.
  1736. -
  1737. -   Permission is granted to copy and distribute modified versions of
  1738. -this manual under the conditions for verbatim copying, provided also
  1739. -that the sections entitled "GNU General Public License" and "Conditions
  1740. -for Using Bison" are included exactly as in the original, and provided
  1741. -that the entire resulting derived work is distributed under the terms
  1742. -of a permission notice identical to this one.
  1743. -
  1744. -   Permission is granted to copy and distribute translations of this
  1745. -manual into another language, under the above conditions for modified
  1746. -versions, except that the sections entitled "GNU General Public
  1747. -License", "Conditions for Using Bison" and this permission notice may be
  1748. -included in translations approved by the Free Software Foundation
  1749. -instead of in the original English.
  1750. -
  1751. -
  1752. -File: bison.info,  Node: Rpcalc Rules,  Next: Rpcalc Lexer,  Prev: Rpcalc Decls,  Up: RPN Calc
  1753. -
  1754. -Grammar Rules for `rpcalc'
  1755. ---------------------------
  1756. -
  1757. -   Here are the grammar rules for the reverse polish notation
  1758. -calculator.
  1759. -
  1760. -     input:    /* empty */
  1761. -             | input line
  1762. -     ;
  1763. -     
  1764. -     line:     '\n'
  1765. -             | exp '\n'  { printf ("\t%.10g\n", $1); }
  1766. -     ;
  1767. -     
  1768. -     exp:      NUM             { $$ = $1;         }
  1769. -             | exp exp '+'     { $$ = $1 + $2;    }
  1770. -             | exp exp '-'     { $$ = $1 - $2;    }
  1771. -             | exp exp '*'     { $$ = $1 * $2;    }
  1772. -             | exp exp '/'     { $$ = $1 / $2;    }
  1773. -           /* Exponentiation */
  1774. -             | exp exp '^'     { $$ = pow ($1, $2); }
  1775. -           /* Unary minus    */
  1776. -             | exp 'n'         { $$ = -$1;        }
  1777. -     ;
  1778. -     %%
  1779. -
  1780. -   The groupings of the rpcalc "language" defined here are the
  1781. -expression (given the name `exp'), the line of input (`line'), and the
  1782. -complete input transcript (`input').  Each of these nonterminal symbols
  1783. -has several alternate rules, joined by the `|' punctuator which is read
  1784. -as "or".  The following sections explain what these rules mean.
  1785. -
  1786. -   The semantics of the language is determined by the actions taken
  1787. -when a grouping is recognized.  The actions are the C code that appears
  1788. -inside braces.  *Note Actions::.
  1789. -
  1790. -   You must specify these actions in C, but Bison provides the means for
  1791. -passing semantic values between the rules.  In each action, the
  1792. -pseudo-variable `$$' stands for the semantic value for the grouping
  1793. -that the rule is going to construct.  Assigning a value to `$$' is the
  1794. -main job of most actions.  The semantic values of the components of the
  1795. -rule are referred to as `$1', `$2', and so on.
  1796. -
  1797. -* Menu:
  1798. -
  1799. -* Rpcalc Input::
  1800. -* Rpcalc Line::
  1801. -* Rpcalc Expr::
  1802. -
  1803. -
  1804. -File: bison.info,  Node: Rpcalc Input,  Next: Rpcalc Line,  Up: Rpcalc Rules
  1805. -
  1806. -Explanation of `input'
  1807. -......................
  1808. -
  1809. -   Consider the definition of `input':
  1810. -
  1811. -     input:    /* empty */
  1812. -             | input line
  1813. -     ;
  1814. -
  1815. -   This definition reads as follows: "A complete input is either an
  1816. -empty string, or a complete input followed by an input line".  Notice
  1817. -that "complete input" is defined in terms of itself.  This definition
  1818. -is said to be "left recursive" since `input' appears always as the
  1819. -leftmost symbol in the sequence.  *Note Recursive Rules: Recursion.
  1820. -
  1821. -   The first alternative is empty because there are no symbols between
  1822. -the colon and the first `|'; this means that `input' can match an empty
  1823. -string of input (no tokens).  We write the rules this way because it is
  1824. -legitimate to type `Ctrl-d' right after you start the calculator.  It's
  1825. -conventional to put an empty alternative first and write the comment
  1826. -`/* empty */' in it.
  1827. -
  1828. -   The second alternate rule (`input line') handles all nontrivial
  1829. -input.  It means, "After reading any number of lines, read one more
  1830. -line if possible."  The left recursion makes this rule into a loop.
  1831. -Since the first alternative matches empty input, the loop can be
  1832. -executed zero or more times.
  1833. -
  1834. -   The parser function `yyparse' continues to process input until a
  1835. -grammatical error is seen or the lexical analyzer says there are no more
  1836. -input tokens; we will arrange for the latter to happen at end of file.
  1837. -
  1838. -
  1839. -File: bison.info,  Node: Rpcalc Line,  Next: Rpcalc Expr,  Prev: Rpcalc Input,  Up: Rpcalc Rules
  1840. -
  1841. -Explanation of `line'
  1842. -.....................
  1843. -
  1844. -   Now consider the definition of `line':
  1845. -
  1846. -     line:     '\n'
  1847. -             | exp '\n'  { printf ("\t%.10g\n", $1); }
  1848. -     ;
  1849. -
  1850. -   The first alternative is a token which is a newline character; this
  1851. -means that rpcalc accepts a blank line (and ignores it, since there is
  1852. -no action).  The second alternative is an expression followed by a
  1853. -newline.  This is the alternative that makes rpcalc useful.  The
  1854. -semantic value of the `exp' grouping is the value of `$1' because the
  1855. -`exp' in question is the first symbol in the alternative.  The action
  1856. -prints this value, which is the result of the computation the user
  1857. -asked for.
  1858. -
  1859. -   This action is unusual because it does not assign a value to `$$'.
  1860. -As a consequence, the semantic value associated with the `line' is
  1861. -uninitialized (its value will be unpredictable).  This would be a bug if
  1862. -that value were ever used, but we don't use it: once rpcalc has printed
  1863. -the value of the user's input line, that value is no longer needed.
  1864. -
  1865. -
  1866. -File: bison.info,  Node: Rpcalc Expr,  Prev: Rpcalc Line,  Up: Rpcalc Rules
  1867. -
  1868. -Explanation of `expr'
  1869. -.....................
  1870. -
  1871. -   The `exp' grouping has several rules, one for each kind of
  1872. -expression.  The first rule handles the simplest expressions: those
  1873. -that are just numbers.  The second handles an addition-expression,
  1874. -which looks like two expressions followed by a plus-sign.  The third
  1875. -handles subtraction, and so on.
  1876. -
  1877. -     exp:      NUM
  1878. -             | exp exp '+'     { $$ = $1 + $2;    }
  1879. -             | exp exp '-'     { $$ = $1 - $2;    }
  1880. -             ...
  1881. -             ;
  1882. -
  1883. -   We have used `|' to join all the rules for `exp', but we could
  1884. -equally well have written them separately:
  1885. -
  1886. -     exp:      NUM ;
  1887. -     exp:      exp exp '+'     { $$ = $1 + $2;    } ;
  1888. -     exp:      exp exp '-'     { $$ = $1 - $2;    } ;
  1889. -             ...
  1890. -
  1891. -   Most of the rules have actions that compute the value of the
  1892. -expression in terms of the value of its parts.  For example, in the
  1893. -rule for addition, `$1' refers to the first component `exp' and `$2'
  1894. -refers to the second one.  The third component, `'+'', has no meaningful
  1895. -associated semantic value, but if it had one you could refer to it as
  1896. -`$3'.  When `yyparse' recognizes a sum expression using this rule, the
  1897. -sum of the two subexpressions' values is produced as the value of the
  1898. -entire expression.  *Note Actions::.
  1899. -
  1900. -   You don't have to give an action for every rule.  When a rule has no
  1901. -action, Bison by default copies the value of `$1' into `$$'.  This is
  1902. -what happens in the first rule (the one that uses `NUM').
  1903. -
  1904. -   The formatting shown here is the recommended convention, but Bison
  1905. -does not require it.  You can add or change whitespace as much as you
  1906. -wish.  For example, this:
  1907. -
  1908. -     exp   : NUM | exp exp '+' {$$ = $1 + $2; } | ...
  1909. -
  1910. -means the same thing as this:
  1911. -
  1912. -     exp:      NUM
  1913. -             | exp exp '+'    { $$ = $1 + $2; }
  1914. -             | ...
  1915. -
  1916. -The latter, however, is much more readable.
  1917. -
  1918. -
  1919. -File: bison.info,  Node: Rpcalc Lexer,  Next: Rpcalc Main,  Prev: Rpcalc Rules,  Up: RPN Calc
  1920. -
  1921. -The `rpcalc' Lexical Analyzer
  1922. ------------------------------
  1923. -
  1924. -   The lexical analyzer's job is low-level parsing: converting
  1925. -characters or sequences of characters into tokens.  The Bison parser
  1926. -gets its tokens by calling the lexical analyzer.  *Note The Lexical
  1927. -Analyzer Function `yylex': Lexical.
  1928. -
  1929. -   Only a simple lexical analyzer is needed for the RPN calculator.
  1930. -This lexical analyzer skips blanks and tabs, then reads in numbers as
  1931. -`double' and returns them as `NUM' tokens.  Any other character that
  1932. -isn't part of a number is a separate token.  Note that the token-code
  1933. -for such a single-character token is the character itself.
  1934. -
  1935. -   The return value of the lexical analyzer function is a numeric code
  1936. -which represents a token type.  The same text used in Bison rules to
  1937. -stand for this token type is also a C expression for the numeric code
  1938. -for the type.  This works in two ways.  If the token type is a
  1939. -character literal, then its numeric code is the ASCII code for that
  1940. -character; you can use the same character literal in the lexical
  1941. -analyzer to express the number.  If the token type is an identifier,
  1942. -that identifier is defined by Bison as a C macro whose definition is
  1943. -the appropriate number.  In this example, therefore, `NUM' becomes a
  1944. -macro for `yylex' to use.
  1945. -
  1946. -   The semantic value of the token (if it has one) is stored into the
  1947. -global variable `yylval', which is where the Bison parser will look for
  1948. -it.  (The C data type of `yylval' is `YYSTYPE', which was defined at
  1949. -the beginning of the grammar; *note Declarations for `rpcalc': Rpcalc
  1950. -Decls..)
  1951. -
  1952. -   A token type code of zero is returned if the end-of-file is
  1953. -encountered.  (Bison recognizes any nonpositive value as indicating the
  1954. -end of the input.)
  1955. -
  1956. -   Here is the code for the lexical analyzer:
  1957. -
  1958. -     /* Lexical analyzer returns a double floating point
  1959. -        number on the stack and the token NUM, or the ASCII
  1960. -        character read if not a number.  Skips all blanks
  1961. -        and tabs, returns 0 for EOF. */
  1962. -     
  1963. -     #include <ctype.h>
  1964. -     
  1965. -     yylex ()
  1966. -     {
  1967. -       int c;
  1968. -     
  1969. -       /* skip white space  */
  1970. -       while ((c = getchar ()) == ' ' || c == '\t')
  1971. -         ;
  1972. -       /* process numbers   */
  1973. -       if (c == '.' || isdigit (c))
  1974. -         {
  1975. -           ungetc (c, stdin);
  1976. -           scanf ("%lf", &yylval);
  1977. -           return NUM;
  1978. -         }
  1979. -       /* return end-of-file  */
  1980. -       if (c == EOF)
  1981. -         return 0;
  1982. -       /* return single chars */
  1983. -       return c;
  1984. -     }
  1985. -
  1986. -
  1987. -File: bison.info,  Node: Rpcalc Main,  Next: Rpcalc Error,  Prev: Rpcalc Lexer,  Up: RPN Calc
  1988. -
  1989. -The Controlling Function
  1990. -------------------------
  1991. -
  1992. -   In keeping with the spirit of this example, the controlling function
  1993. -is kept to the bare minimum.  The only requirement is that it call
  1994. -`yyparse' to start the process of parsing.
  1995. -
  1996. -     main ()
  1997. -     {
  1998. -       yyparse ();
  1999. -     }
  2000. -
  2001. -
  2002. -File: bison.info,  Node: Rpcalc Error,  Next: Rpcalc Gen,  Prev: Rpcalc Main,  Up: RPN Calc
  2003. -
  2004. -The Error Reporting Routine
  2005. ----------------------------
  2006. -
  2007. -   When `yyparse' detects a syntax error, it calls the error reporting
  2008. -function `yyerror' to print an error message (usually but not always
  2009. -`"parse error"').  It is up to the programmer to supply `yyerror'
  2010. -(*note Parser C-Language Interface: Interface.), so here is the
  2011. -definition we will use:
  2012. -
  2013. -     #include <stdio.h>
  2014. -     
  2015. -     yyerror (s)  /* Called by yyparse on error */
  2016. -          char *s;
  2017. -     {
  2018. -       printf ("%s\n", s);
  2019. -     }
  2020. -
  2021. -   After `yyerror' returns, the Bison parser may recover from the error
  2022. -and continue parsing if the grammar contains a suitable error rule
  2023. -(*note Error Recovery::.).  Otherwise, `yyparse' returns nonzero.  We
  2024. -have not written any error rules in this example, so any invalid input
  2025. -will cause the calculator program to exit.  This is not clean behavior
  2026. -for a real calculator, but it is adequate in the first example.
  2027. -
  2028. -
  2029. -File: bison.info,  Node: Rpcalc Gen,  Next: Rpcalc Compile,  Prev: Rpcalc Error,  Up: RPN Calc
  2030. -
  2031. -Running Bison to Make the Parser
  2032. ---------------------------------
  2033. -
  2034. -   Before running Bison to produce a parser, we need to decide how to
  2035. -arrange all the source code in one or more source files.  For such a
  2036. -simple example, the easiest thing is to put everything in one file.
  2037. -The definitions of `yylex', `yyerror' and `main' go at the end, in the
  2038. -"additional C code" section of the file (*note The Overall Layout of a
  2039. -Bison Grammar: Grammar Layout.).
  2040. -
  2041. -   For a large project, you would probably have several source files,
  2042. -and use `make' to arrange to recompile them.
  2043. -
  2044. -   With all the source in a single file, you use the following command
  2045. -to convert it into a parser file:
  2046. -
  2047. -     bison FILE_NAME.y
  2048. -
  2049. -In this example the file was called `rpcalc.y' (for "Reverse Polish
  2050. -CALCulator").  Bison produces a file named `FILE_NAME.tab.c', removing
  2051. -the `.y' from the original file name. The file output by Bison contains
  2052. -the source code for `yyparse'.  The additional functions in the input
  2053. -file (`yylex', `yyerror' and `main') are copied verbatim to the output.
  2054. -
  2055. -
  2056. -File: bison.info,  Node: Rpcalc Compile,  Prev: Rpcalc Gen,  Up: RPN Calc
  2057. -
  2058. -Compiling the Parser File
  2059. --------------------------
  2060. -
  2061. -   Here is how to compile and run the parser file:
  2062. -
  2063. -     # List files in current directory.
  2064. -     % ls
  2065. -     rpcalc.tab.c  rpcalc.y
  2066. -     
  2067. -     # Compile the Bison parser.
  2068. -     # `-lm' tells compiler to search math library for `pow'.
  2069. -     % cc rpcalc.tab.c -lm -o rpcalc
  2070. -     
  2071. -     # List files again.
  2072. -     % ls
  2073. -     rpcalc  rpcalc.tab.c  rpcalc.y
  2074. -
  2075. -   The file `rpcalc' now contains the executable code.  Here is an
  2076. -example session using `rpcalc'.
  2077. -
  2078. -     % rpcalc
  2079. -     4 9 +
  2080. -     13
  2081. -     3 7 + 3 4 5 *+-
  2082. -     -13
  2083. -     3 7 + 3 4 5 * + - n              Note the unary minus, `n'
  2084. -     13
  2085. -     5 6 / 4 n +
  2086. -     -3.166666667
  2087. -     3 4 ^                            Exponentiation
  2088. -     81
  2089. -     ^D                               End-of-file indicator
  2090. -     %
  2091. -
  2092. -
  2093. -File: bison.info,  Node: Infix Calc,  Next: Simple Error Recovery,  Prev: RPN Calc,  Up: Examples
  2094. -
  2095. -Infix Notation Calculator: `calc'
  2096. -=================================
  2097. -
  2098. -   We now modify rpcalc to handle infix operators instead of postfix.
  2099. -Infix notation involves the concept of operator precedence and the need
  2100. -for parentheses nested to arbitrary depth.  Here is the Bison code for
  2101. -`calc.y', an infix desk-top calculator.
  2102. -
  2103. -     /* Infix notation calculator--calc */
  2104. -     
  2105. -     %{
  2106. -     #define YYSTYPE double
  2107. -     #include <math.h>
  2108. -     %}
  2109. -     
  2110. -     /* BISON Declarations */
  2111. -     %token NUM
  2112. -     %left '-' '+'
  2113. -     %left '*' '/'
  2114. -     %left NEG     /* negation--unary minus */
  2115. -     %right '^'    /* exponentiation        */
  2116. -     
  2117. -     /* Grammar follows */
  2118. -     %%
  2119. -     input:    /* empty string */
  2120. -             | input line
  2121. -     ;
  2122. -     
  2123. -     line:     '\n'
  2124. -             | exp '\n'  { printf ("\t%.10g\n", $1); }
  2125. -     ;
  2126. -     
  2127. -     exp:      NUM                { $$ = $1;         }
  2128. -             | exp '+' exp        { $$ = $1 + $3;    }
  2129. -             | exp '-' exp        { $$ = $1 - $3;    }
  2130. -             | exp '*' exp        { $$ = $1 * $3;    }
  2131. -             | exp '/' exp        { $$ = $1 / $3;    }
  2132. -             | '-' exp  %prec NEG { $$ = -$2;        }
  2133. -             | exp '^' exp        { $$ = pow ($1, $3); }
  2134. -             | '(' exp ')'        { $$ = $2;         }
  2135. -     ;
  2136. -     %%
  2137. -
  2138. -The functions `yylex', `yyerror' and `main' can be the same as before.
  2139. -
  2140. -   There are two important new features shown in this code.
  2141. -
  2142. -   In the second section (Bison declarations), `%left' declares token
  2143. -types and says they are left-associative operators.  The declarations
  2144. -`%left' and `%right' (right associativity) take the place of `%token'
  2145. -which is used to declare a token type name without associativity.
  2146. -(These tokens are single-character literals, which ordinarily don't
  2147. -need to be declared.  We declare them here to specify the
  2148. -associativity.)
  2149. -
  2150. -   Operator precedence is determined by the line ordering of the
  2151. -declarations; the higher the line number of the declaration (lower on
  2152. -the page or screen), the higher the precedence.  Hence, exponentiation
  2153. -has the highest precedence, unary minus (`NEG') is next, followed by
  2154. -`*' and `/', and so on.  *Note Operator Precedence: Precedence.
  2155. -
  2156. -   The other important new feature is the `%prec' in the grammar section
  2157. -for the unary minus operator.  The `%prec' simply instructs Bison that
  2158. -the rule `| '-' exp' has the same precedence as `NEG'--in this case the
  2159. -next-to-highest.  *Note Context-Dependent Precedence: Contextual
  2160. -Precedence.
  2161. -
  2162. -   Here is a sample run of `calc.y':
  2163. -
  2164. -     % calc
  2165. -     4 + 4.5 - (34/(8*3+-3))
  2166. -     6.880952381
  2167. -     -56 + 2
  2168. -     -54
  2169. -     3 ^ 2
  2170. -     9
  2171. -
  2172. -
  2173. -File: bison.info,  Node: Simple Error Recovery,  Next: Multi-function Calc,  Prev: Infix Calc,  Up: Examples
  2174. -
  2175. -Simple Error Recovery
  2176. -=====================
  2177. -
  2178. -   Up to this point, this manual has not addressed the issue of "error
  2179. -recovery"--how to continue parsing after the parser detects a syntax
  2180. -error.  All we have handled is error reporting with `yyerror'.  Recall
  2181. -that by default `yyparse' returns after calling `yyerror'.  This means
  2182. -that an erroneous input line causes the calculator program to exit.
  2183. -Now we show how to rectify this deficiency.
  2184. -
  2185. -   The Bison language itself includes the reserved word `error', which
  2186. -may be included in the grammar rules.  In the example below it has been
  2187. -added to one of the alternatives for `line':
  2188. -
  2189. -     line:     '\n'
  2190. -             | exp '\n'   { printf ("\t%.10g\n", $1); }
  2191. -             | error '\n' { yyerrok;                  }
  2192. -     ;
  2193. -
  2194. -   This addition to the grammar allows for simple error recovery in the
  2195. -event of a parse error.  If an expression that cannot be evaluated is
  2196. -read, the error will be recognized by the third rule for `line', and
  2197. -parsing will continue.  (The `yyerror' function is still called upon to
  2198. -print its message as well.)  The action executes the statement
  2199. -`yyerrok', a macro defined automatically by Bison; its meaning is that
  2200. -error recovery is complete (*note Error Recovery::.).  Note the
  2201. -difference between `yyerrok' and `yyerror'; neither one is a misprint.
  2202. -
  2203. -   This form of error recovery deals with syntax errors.  There are
  2204. -other kinds of errors; for example, division by zero, which raises an
  2205. -exception signal that is normally fatal.  A real calculator program
  2206. -must handle this signal and use `longjmp' to return to `main' and
  2207. -resume parsing input lines; it would also have to discard the rest of
  2208. -the current line of input.  We won't discuss this issue further because
  2209. -it is not specific to Bison programs.
  2210. -
  2211. -
  2212. -File: bison.info,  Node: Multi-function Calc,  Next: Exercises,  Prev: Simple Error Recovery,  Up: Examples
  2213. -
  2214. -Multi-Function Calculator: `mfcalc'
  2215. -===================================
  2216. -
  2217. -   Now that the basics of Bison have been discussed, it is time to move
  2218. -on to a more advanced problem.  The above calculators provided only five
  2219. -functions, `+', `-', `*', `/' and `^'.  It would be nice to have a
  2220. -calculator that provides other mathematical functions such as `sin',
  2221. -`cos', etc.
  2222. -
  2223. -   It is easy to add new operators to the infix calculator as long as
  2224. -they are only single-character literals.  The lexical analyzer `yylex'
  2225. -passes back all non-number characters as tokens, so new grammar rules
  2226. -suffice for adding a new operator.  But we want something more
  2227. -flexible: built-in functions whose syntax has this form:
  2228. -
  2229. -     FUNCTION_NAME (ARGUMENT)
  2230. -
  2231. -At the same time, we will add memory to the calculator, by allowing you
  2232. -to create named variables, store values in them, and use them later.
  2233. -Here is a sample session with the multi-function calculator:
  2234. -
  2235. -     % mfcalc
  2236. -     pi = 3.141592653589
  2237. -     3.1415926536
  2238. -     sin(pi)
  2239. -     0.0000000000
  2240. -     alpha = beta1 = 2.3
  2241. -     2.3000000000
  2242. -     alpha
  2243. -     2.3000000000
  2244. -     ln(alpha)
  2245. -     0.8329091229
  2246. -     exp(ln(beta1))
  2247. -     2.3000000000
  2248. -     %
  2249. -
  2250. -   Note that multiple assignment and nested function calls are
  2251. -permitted.
  2252. -
  2253. -* Menu:
  2254. -
  2255. -* Decl: Mfcalc Decl.      Bison declarations for multi-function calculator.
  2256. -* Rules: Mfcalc Rules.    Grammar rules for the calculator.
  2257. -* Symtab: Mfcalc Symtab.  Symbol table management subroutines.
  2258. -
  2259. -
  2260. -File: bison.info,  Node: Mfcalc Decl,  Next: Mfcalc Rules,  Up: Multi-function Calc
  2261. -
  2262. -Declarations for `mfcalc'
  2263. --------------------------
  2264. -
  2265. -   Here are the C and Bison declarations for the multi-function
  2266. -calculator.
  2267. -
  2268. -     %{
  2269. -     #include <math.h>  /* For math functions, cos(), sin(), etc. */
  2270. -     #include "calc.h"  /* Contains definition of `symrec'        */
  2271. -     %}
  2272. -     %union {
  2273. -     double     val;  /* For returning numbers.                   */
  2274. -     symrec  *tptr;   /* For returning symbol-table pointers      */
  2275. -     }
  2276. -     
  2277. -     %token <val>  NUM        /* Simple double precision number   */
  2278. -     %token <tptr> VAR FNCT   /* Variable and Function            */
  2279. -     %type  <val>  exp
  2280. -     
  2281. -     %right '='
  2282. -     %left '-' '+'
  2283. -     %left '*' '/'
  2284. -     %left NEG     /* Negation--unary minus */
  2285. -     %right '^'    /* Exponentiation        */
  2286. -     
  2287. -     /* Grammar follows */
  2288. -     
  2289. -     %%
  2290. -
  2291. -   The above grammar introduces only two new features of the Bison
  2292. -language.  These features allow semantic values to have various data
  2293. -types (*note More Than One Value Type: Multiple Types.).
  2294. -
  2295. -   The `%union' declaration specifies the entire list of possible types;
  2296. -this is instead of defining `YYSTYPE'.  The allowable types are now
  2297. -double-floats (for `exp' and `NUM') and pointers to entries in the
  2298. -symbol table.  *Note The Collection of Value Types: Union Decl.
  2299. -
  2300. -   Since values can now have various types, it is necessary to
  2301. -associate a type with each grammar symbol whose semantic value is used.
  2302. -These symbols are `NUM', `VAR', `FNCT', and `exp'.  Their declarations
  2303. -are augmented with information about their data type (placed between
  2304. -angle brackets).
  2305. -
  2306. -   The Bison construct `%type' is used for declaring nonterminal
  2307. -symbols, just as `%token' is used for declaring token types.  We have
  2308. -not used `%type' before because nonterminal symbols are normally
  2309. -declared implicitly by the rules that define them.  But `exp' must be
  2310. -declared explicitly so we can specify its value type.  *Note
  2311. -Nonterminal Symbols: Type Decl.
  2312. -
  2313. -
  2314. -File: bison.info,  Node: Mfcalc Rules,  Next: Mfcalc Symtab,  Prev: Mfcalc Decl,  Up: Multi-function Calc
  2315. -
  2316. -Grammar Rules for `mfcalc'
  2317. ---------------------------
  2318. -
  2319. -   Here are the grammar rules for the multi-function calculator.  Most
  2320. -of them are copied directly from `calc'; three rules, those which
  2321. -mention `VAR' or `FNCT', are new.
  2322. -
  2323. -     input:   /* empty */
  2324. -             | input line
  2325. -     ;
  2326. -     
  2327. -     line:
  2328. -               '\n'
  2329. -             | exp '\n'   { printf ("\t%.10g\n", $1); }
  2330. -             | error '\n' { yyerrok;                  }
  2331. -     ;
  2332. -     
  2333. -     exp:      NUM                { $$ = $1;                         }
  2334. -             | VAR                { $$ = $1->value.var;              }
  2335. -             | VAR '=' exp        { $$ = $3; $1->value.var = $3;     }
  2336. -             | FNCT '(' exp ')'   { $$ = (*($1->value.fnctptr))($3); }
  2337. -             | exp '+' exp        { $$ = $1 + $3;                    }
  2338. -             | exp '-' exp        { $$ = $1 - $3;                    }
  2339. -             | exp '*' exp        { $$ = $1 * $3;                    }
  2340. -             | exp '/' exp        { $$ = $1 / $3;                    }
  2341. -             | '-' exp  %prec NEG { $$ = -$2;                        }
  2342. -             | exp '^' exp        { $$ = pow ($1, $3);               }
  2343. -             | '(' exp ')'        { $$ = $2;                         }
  2344. -     ;
  2345. -     /* End of grammar */
  2346. -     %%
  2347. -
  2348. -
  2349. -File: bison.info,  Node: Mfcalc Symtab,  Prev: Mfcalc Rules,  Up: Multi-function Calc
  2350. -
  2351. -The `mfcalc' Symbol Table
  2352. --------------------------
  2353. -
  2354. -   The multi-function calculator requires a symbol table to keep track
  2355. -of the names and meanings of variables and functions.  This doesn't
  2356. -affect the grammar rules (except for the actions) or the Bison
  2357. -declarations, but it requires some additional C functions for support.
  2358. -
  2359. -   The symbol table itself consists of a linked list of records.  Its
  2360. -definition, which is kept in the header `calc.h', is as follows.  It
  2361. -provides for either functions or variables to be placed in the table.
  2362. -
  2363. -     /* Data type for links in the chain of symbols.      */
  2364. -     struct symrec
  2365. -     {
  2366. -       char *name;  /* name of symbol                     */
  2367. -       int type;    /* type of symbol: either VAR or FNCT */
  2368. -       union {
  2369. -         double var;           /* value of a VAR          */
  2370. -         double (*fnctptr)();  /* value of a FNCT         */
  2371. -       } value;
  2372. -       struct symrec *next;    /* link field              */
  2373. -     };
  2374. -
  2375. -     typedef struct symrec symrec;
  2376. -     
  2377. -     /* The symbol table: a chain of `struct symrec'.     */
  2378. -     extern symrec *sym_table;
  2379. -     
  2380. -     symrec *putsym ();
  2381. -     symrec *getsym ();
  2382. -
  2383. -   The new version of `main' includes a call to `init_table', a
  2384. -function that initializes the symbol table.  Here it is, and
  2385. -`init_table' as well:
  2386. -
  2387. -     #include <stdio.h>
  2388. -     
  2389. -     main ()
  2390. -     {
  2391. -       init_table ();
  2392. -       yyparse ();
  2393. -     }
  2394. -
  2395. -     yyerror (s)  /* Called by yyparse on error */
  2396. -          char *s;
  2397. -     {
  2398. -       printf ("%s\n", s);
  2399. -     }
  2400. -     
  2401. -     struct init
  2402. -     {
  2403. -       char *fname;
  2404. -       double (*fnct)();
  2405. -     };
  2406. -
  2407. -     struct init arith_fncts[]
  2408. -       = {
  2409. -           "sin", sin,
  2410. -           "cos", cos,
  2411. -           "atan", atan,
  2412. -           "ln", log,
  2413. -           "exp", exp,
  2414. -           "sqrt", sqrt,
  2415. -           0, 0
  2416. -         };
  2417. -     
  2418. -     /* The symbol table: a chain of `struct symrec'.  */
  2419. -     symrec *sym_table = (symrec *)0;
  2420. -
  2421. -     init_table ()  /* puts arithmetic functions in table. */
  2422. -     {
  2423. -       int i;
  2424. -       symrec *ptr;
  2425. -       for (i = 0; arith_fncts[i].fname != 0; i++)
  2426. -         {
  2427. -           ptr = putsym (arith_fncts[i].fname, FNCT);
  2428. -           ptr->value.fnctptr = arith_fncts[i].fnct;
  2429. -         }
  2430. -     }
  2431. -
  2432. -   By simply editing the initialization list and adding the necessary
  2433. -include files, you can add additional functions to the calculator.
  2434. -
  2435. -   Two important functions allow look-up and installation of symbols in
  2436. -the symbol table.  The function `putsym' is passed a name and the type
  2437. -(`VAR' or `FNCT') of the object to be installed.  The object is linked
  2438. -to the front of the list, and a pointer to the object is returned.  The
  2439. -function `getsym' is passed the name of the symbol to look up.  If
  2440. -found, a pointer to that symbol is returned; otherwise zero is returned.
  2441. -
  2442. -     symrec *
  2443. -     putsym (sym_name,sym_type)
  2444. -          char *sym_name;
  2445. -          int sym_type;
  2446. -     {
  2447. -       symrec *ptr;
  2448. -       ptr = (symrec *) malloc (sizeof (symrec));
  2449. -       ptr->name = (char *) malloc (strlen (sym_name) + 1);
  2450. -       strcpy (ptr->name,sym_name);
  2451. -       ptr->type = sym_type;
  2452. -       ptr->value.var = 0; /* set value to 0 even if fctn.  */
  2453. -       ptr->next = (struct symrec *)sym_table;
  2454. -       sym_table = ptr;
  2455. -       return ptr;
  2456. -     }
  2457. -     
  2458. -     symrec *
  2459. -     getsym (sym_name)
  2460. -          char *sym_name;
  2461. -     {
  2462. -       symrec *ptr;
  2463. -       for (ptr = sym_table; ptr != (symrec *) 0;
  2464. -            ptr = (symrec *)ptr->next)
  2465. -         if (strcmp (ptr->name,sym_name) == 0)
  2466. -           return ptr;
  2467. -       return 0;
  2468. -     }
  2469. -
  2470. -   The function `yylex' must now recognize variables, numeric values,
  2471. -and the single-character arithmetic operators.  Strings of alphanumeric
  2472. -characters with a leading nondigit are recognized as either variables or
  2473. -functions depending on what the symbol table says about them.
  2474. -
  2475. -   The string is passed to `getsym' for look up in the symbol table.  If
  2476. -the name appears in the table, a pointer to its location and its type
  2477. -(`VAR' or `FNCT') is returned to `yyparse'.  If it is not already in
  2478. -the table, then it is installed as a `VAR' using `putsym'.  Again, a
  2479. -pointer and its type (which must be `VAR') is returned to `yyparse'.
  2480. -
  2481. -   No change is needed in the handling of numeric values and arithmetic
  2482. -operators in `yylex'.
  2483. -
  2484. -     #include <ctype.h>
  2485. -     yylex ()
  2486. -     {
  2487. -       int c;
  2488. -     
  2489. -       /* Ignore whitespace, get first nonwhite character.  */
  2490. -       while ((c = getchar ()) == ' ' || c == '\t');
  2491. -     
  2492. -       if (c == EOF)
  2493. -         return 0;
  2494. -
  2495. -     /* Char starts a number => parse the number.         */
  2496. -       if (c == '.' || isdigit (c))
  2497. -         {
  2498. -           ungetc (c, stdin);
  2499. -           scanf ("%lf", &yylval.val);
  2500. -           return NUM;
  2501. -         }
  2502. -
  2503. -     /* Char starts an identifier => read the name.       */
  2504. -       if (isalpha (c))
  2505. -         {
  2506. -           symrec *s;
  2507. -           static char *symbuf = 0;
  2508. -           static int length = 0;
  2509. -           int i;
  2510. -
  2511. -     /* Initially make the buffer long enough
  2512. -              for a 40-character symbol name.  */
  2513. -           if (length == 0)
  2514. -             length = 40, symbuf = (char *)malloc (length + 1);
  2515. -     
  2516. -           i = 0;
  2517. -           do
  2518. -
  2519. -     {
  2520. -               /* If buffer is full, make it bigger.        */
  2521. -               if (i == length)
  2522. -                 {
  2523. -                   length *= 2;
  2524. -                   symbuf = (char *)realloc (symbuf, length + 1);
  2525. -                 }
  2526. -               /* Add this character to the buffer.         */
  2527. -               symbuf[i++] = c;
  2528. -               /* Get another character.                    */
  2529. -               c = getchar ();
  2530. -             }
  2531. -
  2532. -     while (c != EOF && isalnum (c));
  2533. -     
  2534. -           ungetc (c, stdin);
  2535. -           symbuf[i] = '\0';
  2536. -
  2537. -     s = getsym (symbuf);
  2538. -           if (s == 0)
  2539. -             s = putsym (symbuf, VAR);
  2540. -           yylval.tptr = s;
  2541. -           return s->type;
  2542. -         }
  2543. -     
  2544. -       /* Any other character is a token by itself.        */
  2545. -       return c;
  2546. -     }
  2547. -
  2548. -   This program is both powerful and flexible. You may easily add new
  2549. -functions, and it is a simple job to modify this code to install
  2550. -predefined variables such as `pi' or `e' as well.
  2551. -
  2552. -
  2553. -File: bison.info,  Node: Exercises,  Prev: Multi-function Calc,  Up: Examples
  2554. -
  2555. -Exercises
  2556. -=========
  2557. -
  2558. -  1. Add some new functions from `math.h' to the initialization list.
  2559. -
  2560. -  2. Add another array that contains constants and their values.  Then
  2561. -     modify `init_table' to add these constants to the symbol table.
  2562. -     It will be easiest to give the constants type `VAR'.
  2563. -
  2564. -  3. Make the program report an error if the user refers to an
  2565. -     uninitialized variable in any way except to store a value in it.
  2566. -
  2567. -
  2568. -File: bison.info,  Node: Grammar File,  Next: Interface,  Prev: Examples,  Up: Top
  2569. -
  2570. -Bison Grammar Files
  2571. -*******************
  2572. -
  2573. -   Bison takes as input a context-free grammar specification and
  2574. -produces a C-language function that recognizes correct instances of the
  2575. -grammar.
  2576. -
  2577. -   The Bison grammar input file conventionally has a name ending in
  2578. -`.y'.
  2579. -
  2580. -* Menu:
  2581. -
  2582. -* Grammar Outline::   Overall layout of the grammar file.
  2583. -* Symbols::           Terminal and nonterminal symbols.
  2584. -* Rules::             How to write grammar rules.
  2585. -* Recursion::         Writing recursive rules.
  2586. -* Semantics::         Semantic values and actions.
  2587. -* Declarations::      All kinds of Bison declarations are described here.
  2588. -* Multiple Parsers::  Putting more than one Bison parser in one program.
  2589. -
  2590. -
  2591. -File: bison.info,  Node: Grammar Outline,  Next: Symbols,  Up: Grammar File
  2592. -
  2593. -Outline of a Bison Grammar
  2594. -==========================
  2595. -
  2596. -   A Bison grammar file has four main sections, shown here with the
  2597. -appropriate delimiters:
  2598. -
  2599. -     %{
  2600. -     C DECLARATIONS
  2601. -     %}
  2602. -     
  2603. -     BISON DECLARATIONS
  2604. -     
  2605. -     %%
  2606. -     GRAMMAR RULES
  2607. -     %%
  2608. -     
  2609. -     ADDITIONAL C CODE
  2610. -
  2611. -   Comments enclosed in `/* ... */' may appear in any of the sections.
  2612. -
  2613. -* Menu:
  2614. -
  2615. -* C Declarations::    Syntax and usage of the C declarations section.
  2616. -* Bison Declarations::  Syntax and usage of the Bison declarations section.
  2617. -* Grammar Rules::     Syntax and usage of the grammar rules section.
  2618. -* C Code::            Syntax and usage of the additional C code section.
  2619. -
  2620. -
  2621. -File: bison.info,  Node: C Declarations,  Next: Bison Declarations,  Up: Grammar Outline
  2622. -
  2623. -The C Declarations Section
  2624. ---------------------------
  2625. -
  2626. -   The C DECLARATIONS section contains macro definitions and
  2627. -declarations of functions and variables that are used in the actions in
  2628. -the grammar rules.  These are copied to the beginning of the parser
  2629. -file so that they precede the definition of `yyparse'.  You can use
  2630. -`#include' to get the declarations from a header file.  If you don't
  2631. -need any C declarations, you may omit the `%{' and `%}' delimiters that
  2632. -bracket this section.
  2633. -
  2634. -
  2635. -File: bison.info,  Node: Bison Declarations,  Next: Grammar Rules,  Prev: C Declarations,  Up: Grammar Outline
  2636. -
  2637. -The Bison Declarations Section
  2638. -------------------------------
  2639. -
  2640. -   The BISON DECLARATIONS section contains declarations that define
  2641. -terminal and nonterminal symbols, specify precedence, and so on.  In
  2642. -some simple grammars you may not need any declarations.  *Note Bison
  2643. -Declarations: Declarations.
  2644. -
  2645. -
  2646. -File: bison.info,  Node: Grammar Rules,  Next: C Code,  Prev: Bison Declarations,  Up: Grammar Outline
  2647. -
  2648. -The Grammar Rules Section
  2649. --------------------------
  2650. -
  2651. -   The "grammar rules" section contains one or more Bison grammar
  2652. -rules, and nothing else.  *Note Syntax of Grammar Rules: Rules.
  2653. -
  2654. -   There must always be at least one grammar rule, and the first `%%'
  2655. -(which precedes the grammar rules) may never be omitted even if it is
  2656. -the first thing in the file.
  2657. -
  2658. -
  2659. -File: bison.info,  Node: C Code,  Prev: Grammar Rules,  Up: Grammar Outline
  2660. -
  2661. -The Additional C Code Section
  2662. ------------------------------
  2663. -
  2664. -   The ADDITIONAL C CODE section is copied verbatim to the end of the
  2665. -parser file, just as the C DECLARATIONS section is copied to the
  2666. -beginning.  This is the most convenient place to put anything that you
  2667. -want to have in the parser file but which need not come before the
  2668. -definition of `yyparse'.  For example, the definitions of `yylex' and
  2669. -`yyerror' often go here.  *Note Parser C-Language Interface: Interface.
  2670. -
  2671. -   If the last section is empty, you may omit the `%%' that separates it
  2672. -from the grammar rules.
  2673. -
  2674. -   The Bison parser itself contains many static variables whose names
  2675. -start with `yy' and many macros whose names start with `YY'.  It is a
  2676. -good idea to avoid using any such names (except those documented in this
  2677. -manual) in the additional C code section of the grammar file.
  2678. -
  2679. -
  2680. -File: bison.info,  Node: Symbols,  Next: Rules,  Prev: Grammar Outline,  Up: Grammar File
  2681. -
  2682. -Symbols, Terminal and Nonterminal
  2683. -=================================
  2684. -
  2685. -   "Symbols" in Bison grammars represent the grammatical classifications
  2686. -of the language.
  2687. -
  2688. -   A "terminal symbol" (also known as a "token type") represents a
  2689. -class of syntactically equivalent tokens.  You use the symbol in grammar
  2690. -rules to mean that a token in that class is allowed.  The symbol is
  2691. -represented in the Bison parser by a numeric code, and the `yylex'
  2692. -function returns a token type code to indicate what kind of token has
  2693. -been read.  You don't need to know what the code value is; you can use
  2694. -the symbol to stand for it.
  2695. -
  2696. -   A "nonterminal symbol" stands for a class of syntactically equivalent
  2697. -groupings.  The symbol name is used in writing grammar rules.  By
  2698. -convention, it should be all lower case.
  2699. -
  2700. -   Symbol names can contain letters, digits (not at the beginning),
  2701. -underscores and periods.  Periods make sense only in nonterminals.
  2702. -
  2703. -   There are three ways of writing terminal symbols in the grammar:
  2704. -
  2705. -   * A "named token type" is written with an identifier, like an
  2706. -     identifier in C.  By convention, it should be all upper case.  Each
  2707. -     such name must be defined with a Bison declaration such as
  2708. -     `%token'.  *Note Token Type Names: Token Decl.
  2709. -
  2710. -   * A "character token type" (or "literal character token") is written
  2711. -     in the grammar using the same syntax used in C for character
  2712. -     constants; for example, `'+'' is a character token type.  A
  2713. -     character token type doesn't need to be declared unless you need to
  2714. -     specify its semantic value data type (*note Data Types of Semantic
  2715. -     Values: Value Type.), associativity, or precedence (*note Operator
  2716. -     Precedence: Precedence.).
  2717. -
  2718. -     By convention, a character token type is used only to represent a
  2719. -     token that consists of that particular character.  Thus, the token
  2720. -     type `'+'' is used to represent the character `+' as a token.
  2721. -     Nothing enforces this convention, but if you depart from it, your
  2722. -     program will confuse other readers.
  2723. -
  2724. -     All the usual escape sequences used in character literals in C can
  2725. -     be used in Bison as well, but you must not use the null character
  2726. -     as a character literal because its ASCII code, zero, is the code
  2727. -     `yylex' returns for end-of-input (*note Calling Convention for
  2728. -     `yylex': Calling Convention.).
  2729. -
  2730. -   * A "literal string token" is written like a C string constant; for
  2731. -     example, `"<="' is a literal string token.  A literal string token
  2732. -     doesn't need to be declared unless you need to specify its semantic
  2733. -     value data type (*note Value Type::.), associativity, precedence
  2734. -     (*note Precedence::.).
  2735. -
  2736. -     You can associate the literal string token with a symbolic name as
  2737. -     an alias, using the `%token' declaration (*note Token
  2738. -     Declarations: Token Decl.).  If you don't do that, the lexical
  2739. -     analyzer has to retrieve the token number for the literal string
  2740. -     token from the `yytname' table (*note Calling Convention::.).
  2741. -
  2742. -     *WARNING*: literal string tokens do not work in Yacc.
  2743. -
  2744. -     By convention, a literal string token is used only to represent a
  2745. -     token that consists of that particular string.  Thus, you should
  2746. -     use the token type `"<="' to represent the string `<=' as a token.
  2747. -     Bison does not enforces this convention, but if you depart from
  2748. -     it, people who read your program will be confused.
  2749. -
  2750. -     All the escape sequences used in string literals in C can be used
  2751. -     in Bison as well.  A literal string token must contain two or more
  2752. -     characters; for a token containing just one character, use a
  2753. -     character token (see above).
  2754. -
  2755. -   How you choose to write a terminal symbol has no effect on its
  2756. -grammatical meaning.  That depends only on where it appears in rules and
  2757. -on when the parser function returns that symbol.
  2758. -
  2759. -   The value returned by `yylex' is always one of the terminal symbols
  2760. -(or 0 for end-of-input).  Whichever way you write the token type in the
  2761. -grammar rules, you write it the same way in the definition of `yylex'.
  2762. -The numeric code for a character token type is simply the ASCII code for
  2763. -the character, so `yylex' can use the identical character constant to
  2764. -generate the requisite code.  Each named token type becomes a C macro in
  2765. -the parser file, so `yylex' can use the name to stand for the code.
  2766. -(This is why periods don't make sense in terminal symbols.) *Note
  2767. -Calling Convention for `yylex': Calling Convention.
  2768. -
  2769. -   If `yylex' is defined in a separate file, you need to arrange for the
  2770. -token-type macro definitions to be available there.  Use the `-d'
  2771. -option when you run Bison, so that it will write these macro definitions
  2772. -into a separate header file `NAME.tab.h' which you can include in the
  2773. -other source files that need it.  *Note Invoking Bison: Invocation.
  2774. -
  2775. -   The symbol `error' is a terminal symbol reserved for error recovery
  2776. -(*note Error Recovery::.); you shouldn't use it for any other purpose.
  2777. -In particular, `yylex' should never return this value.
  2778. -
  2779. -
  2780. -File: bison.info,  Node: Rules,  Next: Recursion,  Prev: Symbols,  Up: Grammar File
  2781. -
  2782. -Syntax of Grammar Rules
  2783. -=======================
  2784. -
  2785. -   A Bison grammar rule has the following general form:
  2786. -
  2787. -     RESULT: COMPONENTS...
  2788. -             ;
  2789. -
  2790. -where RESULT is the nonterminal symbol that this rule describes and
  2791. -COMPONENTS are various terminal and nonterminal symbols that are put
  2792. -together by this rule (*note Symbols::.).
  2793. -
  2794. -   For example,
  2795. -
  2796. -     exp:      exp '+' exp
  2797. -             ;
  2798. -
  2799. -says that two groupings of type `exp', with a `+' token in between, can
  2800. -be combined into a larger grouping of type `exp'.
  2801. -
  2802. -   Whitespace in rules is significant only to separate symbols.  You
  2803. -can add extra whitespace as you wish.
  2804. -
  2805. -   Scattered among the components can be ACTIONS that determine the
  2806. -semantics of the rule.  An action looks like this:
  2807. -
  2808. -     {C STATEMENTS}
  2809. -
  2810. -Usually there is only one action and it follows the components.  *Note
  2811. -Actions::.
  2812. -
  2813. -   Multiple rules for the same RESULT can be written separately or can
  2814. -be joined with the vertical-bar character `|' as follows:
  2815. -
  2816. -     RESULT:   RULE1-COMPONENTS...
  2817. -             | RULE2-COMPONENTS...
  2818. -             ...
  2819. -             ;
  2820. -
  2821. -They are still considered distinct rules even when joined in this way.
  2822. -
  2823. -   If COMPONENTS in a rule is empty, it means that RESULT can match the
  2824. -empty string.  For example, here is how to define a comma-separated
  2825. -sequence of zero or more `exp' groupings:
  2826. -
  2827. -     expseq:   /* empty */
  2828. -             | expseq1
  2829. -             ;
  2830. -     
  2831. -     expseq1:  exp
  2832. -             | expseq1 ',' exp
  2833. -             ;
  2834. -
  2835. -It is customary to write a comment `/* empty */' in each rule with no
  2836. -components.
  2837. -
  2838. -
  2839. -File: bison.info,  Node: Recursion,  Next: Semantics,  Prev: Rules,  Up: Grammar File
  2840. -
  2841. -Recursive Rules
  2842. -===============
  2843. -
  2844. -   A rule is called "recursive" when its RESULT nonterminal appears
  2845. -also on its right hand side.  Nearly all Bison grammars need to use
  2846. -recursion, because that is the only way to define a sequence of any
  2847. -number of somethings.  Consider this recursive definition of a
  2848. -comma-separated sequence of one or more expressions:
  2849. -
  2850. -     expseq1:  exp
  2851. -             | expseq1 ',' exp
  2852. -             ;
  2853. -
  2854. -Since the recursive use of `expseq1' is the leftmost symbol in the
  2855. -right hand side, we call this "left recursion".  By contrast, here the
  2856. -same construct is defined using "right recursion":
  2857. -
  2858. -     expseq1:  exp
  2859. -             | exp ',' expseq1
  2860. -             ;
  2861. -
  2862. -Any kind of sequence can be defined using either left recursion or
  2863. -right recursion, but you should always use left recursion, because it
  2864. -can parse a sequence of any number of elements with bounded stack
  2865. -space.  Right recursion uses up space on the Bison stack in proportion
  2866. -to the number of elements in the sequence, because all the elements
  2867. -must be shifted onto the stack before the rule can be applied even
  2868. -once.  *Note The Bison Parser Algorithm: Algorithm, for further
  2869. -explanation of this.
  2870. -
  2871. -   "Indirect" or "mutual" recursion occurs when the result of the rule
  2872. -does not appear directly on its right hand side, but does appear in
  2873. -rules for other nonterminals which do appear on its right hand side.
  2874. -
  2875. -   For example:
  2876. -
  2877. -     expr:     primary
  2878. -             | primary '+' primary
  2879. -             ;
  2880. -     
  2881. -     primary:  constant
  2882. -             | '(' expr ')'
  2883. -             ;
  2884. -
  2885. -defines two mutually-recursive nonterminals, since each refers to the
  2886. -other.
  2887. -
  2888. -
  2889. -File: bison.info,  Node: Semantics,  Next: Declarations,  Prev: Recursion,  Up: Grammar File
  2890. -
  2891. -Defining Language Semantics
  2892. -===========================
  2893. -
  2894. -   The grammar rules for a language determine only the syntax.  The
  2895. -semantics are determined by the semantic values associated with various
  2896. -tokens and groupings, and by the actions taken when various groupings
  2897. -are recognized.
  2898. -
  2899. -   For example, the calculator calculates properly because the value
  2900. -associated with each expression is the proper number; it adds properly
  2901. -because the action for the grouping `X + Y' is to add the numbers
  2902. -associated with X and Y.
  2903. -
  2904. -* Menu:
  2905. -
  2906. -* Value Type::        Specifying one data type for all semantic values.
  2907. -* Multiple Types::    Specifying several alternative data types.
  2908. -* Actions::           An action is the semantic definition of a grammar rule.
  2909. -* Action Types::      Specifying data types for actions to operate on.
  2910. -* Mid-Rule Actions::  Most actions go at the end of a rule.
  2911. -                      This says when, why and how to use the exceptional
  2912. -                        action in the middle of a rule.
  2913. -
  2914. -
  2915. -File: bison.info,  Node: Value Type,  Next: Multiple Types,  Up: Semantics
  2916. -
  2917. -Data Types of Semantic Values
  2918. ------------------------------
  2919. -
  2920. -   In a simple program it may be sufficient to use the same data type
  2921. -for the semantic values of all language constructs.  This was true in
  2922. -the RPN and infix calculator examples (*note Reverse Polish Notation
  2923. -Calculator: RPN Calc.).
  2924. -
  2925. -   Bison's default is to use type `int' for all semantic values.  To
  2926. -specify some other type, define `YYSTYPE' as a macro, like this:
  2927. -
  2928. -     #define YYSTYPE double
  2929. -
  2930. -This macro definition must go in the C declarations section of the
  2931. -grammar file (*note Outline of a Bison Grammar: Grammar Outline.).
  2932. -
  2933. -
  2934. -File: bison.info,  Node: Multiple Types,  Next: Actions,  Prev: Value Type,  Up: Semantics
  2935. -
  2936. -More Than One Value Type
  2937. -------------------------
  2938. -
  2939. -   In most programs, you will need different data types for different
  2940. -kinds of tokens and groupings.  For example, a numeric constant may
  2941. -need type `int' or `long', while a string constant needs type `char *',
  2942. -and an identifier might need a pointer to an entry in the symbol table.
  2943. -
  2944. -   To use more than one data type for semantic values in one parser,
  2945. -Bison requires you to do two things:
  2946. -
  2947. -   * Specify the entire collection of possible data types, with the
  2948. -     `%union' Bison declaration (*note The Collection of Value Types:
  2949. -     Union Decl.).
  2950. -
  2951. -   * Choose one of those types for each symbol (terminal or nonterminal)
  2952. -     for which semantic values are used.  This is done for tokens with
  2953. -     the `%token' Bison declaration (*note Token Type Names: Token
  2954. -     Decl.) and for groupings with the `%type' Bison declaration (*note
  2955. -     Nonterminal Symbols: Type Decl.).
  2956. -
  2957. -
  2958. -File: bison.info,  Node: Actions,  Next: Action Types,  Prev: Multiple Types,  Up: Semantics
  2959. -
  2960. -Actions
  2961. --------
  2962. -
  2963. -   An action accompanies a syntactic rule and contains C code to be
  2964. -executed each time an instance of that rule is recognized.  The task of
  2965. -most actions is to compute a semantic value for the grouping built by
  2966. -the rule from the semantic values associated with tokens or smaller
  2967. -groupings.
  2968. -
  2969. -   An action consists of C statements surrounded by braces, much like a
  2970. -compound statement in C.  It can be placed at any position in the rule;
  2971. -it is executed at that position.  Most rules have just one action at
  2972. -the end of the rule, following all the components.  Actions in the
  2973. -middle of a rule are tricky and used only for special purposes (*note
  2974. -Actions in Mid-Rule: Mid-Rule Actions.).
  2975. -
  2976. -   The C code in an action can refer to the semantic values of the
  2977. -components matched by the rule with the construct `$N', which stands for
  2978. -the value of the Nth component.  The semantic value for the grouping
  2979. -being constructed is `$$'.  (Bison translates both of these constructs
  2980. -into array element references when it copies the actions into the parser
  2981. -file.)
  2982. -
  2983. -   Here is a typical example:
  2984. -
  2985. -     exp:    ...
  2986. -             | exp '+' exp
  2987. -                 { $$ = $1 + $3; }
  2988. -
  2989. -This rule constructs an `exp' from two smaller `exp' groupings
  2990. -connected by a plus-sign token.  In the action, `$1' and `$3' refer to
  2991. -the semantic values of the two component `exp' groupings, which are the
  2992. -first and third symbols on the right hand side of the rule.  The sum is
  2993. -stored into `$$' so that it becomes the semantic value of the
  2994. -addition-expression just recognized by the rule.  If there were a
  2995. -useful semantic value associated with the `+' token, it could be
  2996. -referred to as `$2'.
  2997. -
  2998. -   If you don't specify an action for a rule, Bison supplies a default:
  2999. -`$$ = $1'.  Thus, the value of the first symbol in the rule becomes the
  3000. -value of the whole rule.  Of course, the default rule is valid only if
  3001. -the two data types match.  There is no meaningful default action for an
  3002. -empty rule; every empty rule must have an explicit action unless the
  3003. -rule's value does not matter.
  3004. -
  3005. -   `$N' with N zero or negative is allowed for reference to tokens and
  3006. -groupings on the stack *before* those that match the current rule.
  3007. -This is a very risky practice, and to use it reliably you must be
  3008. -certain of the context in which the rule is applied.  Here is a case in
  3009. -which you can use this reliably:
  3010. -
  3011. -     foo:      expr bar '+' expr  { ... }
  3012. -             | expr bar '-' expr  { ... }
  3013. -             ;
  3014. -     
  3015. -     bar:      /* empty */
  3016. -             { previous_expr = $0; }
  3017. -             ;
  3018. -
  3019. -   As long as `bar' is used only in the fashion shown here, `$0' always
  3020. -refers to the `expr' which precedes `bar' in the definition of `foo'.
  3021. -
  3022. -
  3023. -File: bison.info,  Node: Action Types,  Next: Mid-Rule Actions,  Prev: Actions,  Up: Semantics
  3024. -
  3025. -Data Types of Values in Actions
  3026. --------------------------------
  3027. -
  3028. -   If you have chosen a single data type for semantic values, the `$$'
  3029. -and `$N' constructs always have that data type.
  3030. -
  3031. -   If you have used `%union' to specify a variety of data types, then
  3032. -you must declare a choice among these types for each terminal or
  3033. -nonterminal symbol that can have a semantic value.  Then each time you
  3034. -use `$$' or `$N', its data type is determined by which symbol it refers
  3035. -to in the rule.  In this example,
  3036. -
  3037. -     exp:    ...
  3038. -             | exp '+' exp
  3039. -                 { $$ = $1 + $3; }
  3040. -
  3041. -`$1' and `$3' refer to instances of `exp', so they all have the data
  3042. -type declared for the nonterminal symbol `exp'.  If `$2' were used, it
  3043. -would have the data type declared for the terminal symbol `'+'',
  3044. -whatever that might be.
  3045. -
  3046. -   Alternatively, you can specify the data type when you refer to the
  3047. -value, by inserting `<TYPE>' after the `$' at the beginning of the
  3048. -reference.  For example, if you have defined types as shown here:
  3049. -
  3050. -     %union {
  3051. -       int itype;
  3052. -       double dtype;
  3053. -     }
  3054. -
  3055. -then you can write `$<itype>1' to refer to the first subunit of the
  3056. -rule as an integer, or `$<dtype>1' to refer to it as a double.
  3057. -
  3058. diff -rup --new-file baseline/fsf/bison/bison.info-3 amiga/fsf/bison/bison.info-3
  3059. --- baseline/fsf/bison/bison.info-3    Sat Feb 17 09:46:07 1996
  3060. +++ amiga/fsf/bison/bison.info-3    Wed Dec 31 17:00:00 1969
  3061. @@ -1,1301 +0,0 @@
  3062. -This is Info file bison.info, produced by Makeinfo-1.64 from the input
  3063. -file ./bison.texinfo.
  3064. -
  3065. -   This file documents the Bison parser generator.
  3066. -
  3067. -   Copyright (C) 1988, 89, 90, 91, 92, 93, 1995 Free Software
  3068. -Foundation, Inc.
  3069. -
  3070. -   Permission is granted to make and distribute verbatim copies of this
  3071. -manual provided the copyright notice and this permission notice are
  3072. -preserved on all copies.
  3073. -
  3074. -   Permission is granted to copy and distribute modified versions of
  3075. -this manual under the conditions for verbatim copying, provided also
  3076. -that the sections entitled "GNU General Public License" and "Conditions
  3077. -for Using Bison" are included exactly as in the original, and provided
  3078. -that the entire resulting derived work is distributed under the terms
  3079. -of a permission notice identical to this one.
  3080. -
  3081. -   Permission is granted to copy and distribute translations of this
  3082. -manual into another language, under the above conditions for modified
  3083. -versions, except that the sections entitled "GNU General Public
  3084. -License", "Conditions for Using Bison" and this permission notice may be
  3085. -included in translations approved by the Free Software Foundation
  3086. -instead of in the original English.
  3087. -
  3088. -
  3089. -File: bison.info,  Node: Mid-Rule Actions,  Prev: Action Types,  Up: Semantics
  3090. -
  3091. -Actions in Mid-Rule
  3092. --------------------
  3093. -
  3094. -   Occasionally it is useful to put an action in the middle of a rule.
  3095. -These actions are written just like usual end-of-rule actions, but they
  3096. -are executed before the parser even recognizes the following components.
  3097. -
  3098. -   A mid-rule action may refer to the components preceding it using
  3099. -`$N', but it may not refer to subsequent components because it is run
  3100. -before they are parsed.
  3101. -
  3102. -   The mid-rule action itself counts as one of the components of the
  3103. -rule.  This makes a difference when there is another action later in
  3104. -the same rule (and usually there is another at the end): you have to
  3105. -count the actions along with the symbols when working out which number
  3106. -N to use in `$N'.
  3107. -
  3108. -   The mid-rule action can also have a semantic value.  The action can
  3109. -set its value with an assignment to `$$', and actions later in the rule
  3110. -can refer to the value using `$N'.  Since there is no symbol to name
  3111. -the action, there is no way to declare a data type for the value in
  3112. -advance, so you must use the `$<...>' construct to specify a data type
  3113. -each time you refer to this value.
  3114. -
  3115. -   There is no way to set the value of the entire rule with a mid-rule
  3116. -action, because assignments to `$$' do not have that effect.  The only
  3117. -way to set the value for the entire rule is with an ordinary action at
  3118. -the end of the rule.
  3119. -
  3120. -   Here is an example from a hypothetical compiler, handling a `let'
  3121. -statement that looks like `let (VARIABLE) STATEMENT' and serves to
  3122. -create a variable named VARIABLE temporarily for the duration of
  3123. -STATEMENT.  To parse this construct, we must put VARIABLE into the
  3124. -symbol table while STATEMENT is parsed, then remove it afterward.  Here
  3125. -is how it is done:
  3126. -
  3127. -     stmt:   LET '(' var ')'
  3128. -                     { $<context>$ = push_context ();
  3129. -                       declare_variable ($3); }
  3130. -             stmt    { $$ = $6;
  3131. -                       pop_context ($<context>5); }
  3132. -
  3133. -As soon as `let (VARIABLE)' has been recognized, the first action is
  3134. -run.  It saves a copy of the current semantic context (the list of
  3135. -accessible variables) as its semantic value, using alternative
  3136. -`context' in the data-type union.  Then it calls `declare_variable' to
  3137. -add the new variable to that list.  Once the first action is finished,
  3138. -the embedded statement `stmt' can be parsed.  Note that the mid-rule
  3139. -action is component number 5, so the `stmt' is component number 6.
  3140. -
  3141. -   After the embedded statement is parsed, its semantic value becomes
  3142. -the value of the entire `let'-statement.  Then the semantic value from
  3143. -the earlier action is used to restore the prior list of variables.  This
  3144. -removes the temporary `let'-variable from the list so that it won't
  3145. -appear to exist while the rest of the program is parsed.
  3146. -
  3147. -   Taking action before a rule is completely recognized often leads to
  3148. -conflicts since the parser must commit to a parse in order to execute
  3149. -the action.  For example, the following two rules, without mid-rule
  3150. -actions, can coexist in a working parser because the parser can shift
  3151. -the open-brace token and look at what follows before deciding whether
  3152. -there is a declaration or not:
  3153. -
  3154. -     compound: '{' declarations statements '}'
  3155. -             | '{' statements '}'
  3156. -             ;
  3157. -
  3158. -But when we add a mid-rule action as follows, the rules become
  3159. -nonfunctional:
  3160. -
  3161. -     compound: { prepare_for_local_variables (); }
  3162. -               '{' declarations statements '}'
  3163. -             | '{' statements '}'
  3164. -             ;
  3165. -
  3166. -Now the parser is forced to decide whether to run the mid-rule action
  3167. -when it has read no farther than the open-brace.  In other words, it
  3168. -must commit to using one rule or the other, without sufficient
  3169. -information to do it correctly.  (The open-brace token is what is called
  3170. -the "look-ahead" token at this time, since the parser is still deciding
  3171. -what to do about it.  *Note Look-Ahead Tokens: Look-Ahead.)
  3172. -
  3173. -   You might think that you could correct the problem by putting
  3174. -identical actions into the two rules, like this:
  3175. -
  3176. -     compound: { prepare_for_local_variables (); }
  3177. -               '{' declarations statements '}'
  3178. -             | { prepare_for_local_variables (); }
  3179. -               '{' statements '}'
  3180. -             ;
  3181. -
  3182. -But this does not help, because Bison does not realize that the two
  3183. -actions are identical.  (Bison never tries to understand the C code in
  3184. -an action.)
  3185. -
  3186. -   If the grammar is such that a declaration can be distinguished from a
  3187. -statement by the first token (which is true in C), then one solution
  3188. -which does work is to put the action after the open-brace, like this:
  3189. -
  3190. -     compound: '{' { prepare_for_local_variables (); }
  3191. -               declarations statements '}'
  3192. -             | '{' statements '}'
  3193. -             ;
  3194. -
  3195. -Now the first token of the following declaration or statement, which
  3196. -would in any case tell Bison which rule to use, can still do so.
  3197. -
  3198. -   Another solution is to bury the action inside a nonterminal symbol
  3199. -which serves as a subroutine:
  3200. -
  3201. -     subroutine: /* empty */
  3202. -               { prepare_for_local_variables (); }
  3203. -             ;
  3204. -     
  3205. -     compound: subroutine
  3206. -               '{' declarations statements '}'
  3207. -             | subroutine
  3208. -               '{' statements '}'
  3209. -             ;
  3210. -
  3211. -Now Bison can execute the action in the rule for `subroutine' without
  3212. -deciding which rule for `compound' it will eventually use.  Note that
  3213. -the action is now at the end of its rule.  Any mid-rule action can be
  3214. -converted to an end-of-rule action in this way, and this is what Bison
  3215. -actually does to implement mid-rule actions.
  3216. -
  3217. -
  3218. -File: bison.info,  Node: Declarations,  Next: Multiple Parsers,  Prev: Semantics,  Up: Grammar File
  3219. -
  3220. -Bison Declarations
  3221. -==================
  3222. -
  3223. -   The "Bison declarations" section of a Bison grammar defines the
  3224. -symbols used in formulating the grammar and the data types of semantic
  3225. -values.  *Note Symbols::.
  3226. -
  3227. -   All token type names (but not single-character literal tokens such as
  3228. -`'+'' and `'*'') must be declared.  Nonterminal symbols must be
  3229. -declared if you need to specify which data type to use for the semantic
  3230. -value (*note More Than One Value Type: Multiple Types.).
  3231. -
  3232. -   The first rule in the file also specifies the start symbol, by
  3233. -default.  If you want some other symbol to be the start symbol, you
  3234. -must declare it explicitly (*note Languages and Context-Free Grammars:
  3235. -Language and Grammar.).
  3236. -
  3237. -* Menu:
  3238. -
  3239. -* Token Decl::        Declaring terminal symbols.
  3240. -* Precedence Decl::   Declaring terminals with precedence and associativity.
  3241. -* Union Decl::        Declaring the set of all semantic value types.
  3242. -* Type Decl::         Declaring the choice of type for a nonterminal symbol.
  3243. -* Expect Decl::       Suppressing warnings about shift/reduce conflicts.
  3244. -* Start Decl::        Specifying the start symbol.
  3245. -* Pure Decl::         Requesting a reentrant parser.
  3246. -* Decl Summary::      Table of all Bison declarations.
  3247. -
  3248. -
  3249. -File: bison.info,  Node: Token Decl,  Next: Precedence Decl,  Up: Declarations
  3250. -
  3251. -Token Type Names
  3252. -----------------
  3253. -
  3254. -   The basic way to declare a token type name (terminal symbol) is as
  3255. -follows:
  3256. -
  3257. -     %token NAME
  3258. -
  3259. -   Bison will convert this into a `#define' directive in the parser, so
  3260. -that the function `yylex' (if it is in this file) can use the name NAME
  3261. -to stand for this token type's code.
  3262. -
  3263. -   Alternatively, you can use `%left', `%right', or `%nonassoc' instead
  3264. -of `%token', if you wish to specify precedence.  *Note Operator
  3265. -Precedence: Precedence Decl.
  3266. -
  3267. -   You can explicitly specify the numeric code for a token type by
  3268. -appending an integer value in the field immediately following the token
  3269. -name:
  3270. -
  3271. -     %token NUM 300
  3272. -
  3273. -It is generally best, however, to let Bison choose the numeric codes for
  3274. -all token types.  Bison will automatically select codes that don't
  3275. -conflict with each other or with ASCII characters.
  3276. -
  3277. -   In the event that the stack type is a union, you must augment the
  3278. -`%token' or other token declaration to include the data type
  3279. -alternative delimited by angle-brackets (*note More Than One Value
  3280. -Type: Multiple Types.).
  3281. -
  3282. -   For example:
  3283. -
  3284. -     %union {              /* define stack type */
  3285. -       double val;
  3286. -       symrec *tptr;
  3287. -     }
  3288. -     %token <val> NUM      /* define token NUM and its type */
  3289. -
  3290. -   You can associate a literal string token with a token type name by
  3291. -writing the literal string at the end of a `%token' declaration which
  3292. -declares the name.  For example:
  3293. -
  3294. -     %token arrow "=>"
  3295. -
  3296. -For example, a grammar for the C language might specify these names with
  3297. -equivalent literal string tokens:
  3298. -
  3299. -     %token  <operator>  OR      "||"
  3300. -     %token  <operator>  LE 134  "<="
  3301. -     %left  OR  "<="
  3302. -
  3303. -Once you equate the literal string and the token name, you can use them
  3304. -interchangeably in further declarations or the grammar rules.  The
  3305. -`yylex' function can use the token name or the literal string to obtain
  3306. -the token type code number (*note Calling Convention::.).
  3307. -
  3308. -
  3309. -File: bison.info,  Node: Precedence Decl,  Next: Union Decl,  Prev: Token Decl,  Up: Declarations
  3310. -
  3311. -Operator Precedence
  3312. --------------------
  3313. -
  3314. -   Use the `%left', `%right' or `%nonassoc' declaration to declare a
  3315. -token and specify its precedence and associativity, all at once.  These
  3316. -are called "precedence declarations".  *Note Operator Precedence:
  3317. -Precedence, for general information on operator precedence.
  3318. -
  3319. -   The syntax of a precedence declaration is the same as that of
  3320. -`%token': either
  3321. -
  3322. -     %left SYMBOLS...
  3323. -
  3324. -or
  3325. -
  3326. -     %left <TYPE> SYMBOLS...
  3327. -
  3328. -   And indeed any of these declarations serves the purposes of `%token'.
  3329. -But in addition, they specify the associativity and relative precedence
  3330. -for all the SYMBOLS:
  3331. -
  3332. -   * The associativity of an operator OP determines how repeated uses
  3333. -     of the operator nest: whether `X OP Y OP Z' is parsed by grouping
  3334. -     X with Y first or by grouping Y with Z first.  `%left' specifies
  3335. -     left-associativity (grouping X with Y first) and `%right'
  3336. -     specifies right-associativity (grouping Y with Z first).
  3337. -     `%nonassoc' specifies no associativity, which means that `X OP Y
  3338. -     OP Z' is considered a syntax error.
  3339. -
  3340. -   * The precedence of an operator determines how it nests with other
  3341. -     operators.  All the tokens declared in a single precedence
  3342. -     declaration have equal precedence and nest together according to
  3343. -     their associativity.  When two tokens declared in different
  3344. -     precedence declarations associate, the one declared later has the
  3345. -     higher precedence and is grouped first.
  3346. -
  3347. -
  3348. -File: bison.info,  Node: Union Decl,  Next: Type Decl,  Prev: Precedence Decl,  Up: Declarations
  3349. -
  3350. -The Collection of Value Types
  3351. ------------------------------
  3352. -
  3353. -   The `%union' declaration specifies the entire collection of possible
  3354. -data types for semantic values.  The keyword `%union' is followed by a
  3355. -pair of braces containing the same thing that goes inside a `union' in
  3356. -C.
  3357. -
  3358. -   For example:
  3359. -
  3360. -     %union {
  3361. -       double val;
  3362. -       symrec *tptr;
  3363. -     }
  3364. -
  3365. -This says that the two alternative types are `double' and `symrec *'.
  3366. -They are given names `val' and `tptr'; these names are used in the
  3367. -`%token' and `%type' declarations to pick one of the types for a
  3368. -terminal or nonterminal symbol (*note Nonterminal Symbols: Type Decl.).
  3369. -
  3370. -   Note that, unlike making a `union' declaration in C, you do not write
  3371. -a semicolon after the closing brace.
  3372. -
  3373. -
  3374. -File: bison.info,  Node: Type Decl,  Next: Expect Decl,  Prev: Union Decl,  Up: Declarations
  3375. -
  3376. -Nonterminal Symbols
  3377. --------------------
  3378. -
  3379. -When you use `%union' to specify multiple value types, you must declare
  3380. -the value type of each nonterminal symbol for which values are used.
  3381. -This is done with a `%type' declaration, like this:
  3382. -
  3383. -     %type <TYPE> NONTERMINAL...
  3384. -
  3385. -Here NONTERMINAL is the name of a nonterminal symbol, and TYPE is the
  3386. -name given in the `%union' to the alternative that you want (*note The
  3387. -Collection of Value Types: Union Decl.).  You can give any number of
  3388. -nonterminal symbols in the same `%type' declaration, if they have the
  3389. -same value type.  Use spaces to separate the symbol names.
  3390. -
  3391. -   You can also declare the value type of a terminal symbol.  To do
  3392. -this, use the same `<TYPE>' construction in a declaration for the
  3393. -terminal symbol.  All kinds of token declarations allow `<TYPE>'.
  3394. -
  3395. -
  3396. -File: bison.info,  Node: Expect Decl,  Next: Start Decl,  Prev: Type Decl,  Up: Declarations
  3397. -
  3398. -Suppressing Conflict Warnings
  3399. ------------------------------
  3400. -
  3401. -   Bison normally warns if there are any conflicts in the grammar
  3402. -(*note Shift/Reduce Conflicts: Shift/Reduce.), but most real grammars
  3403. -have harmless shift/reduce conflicts which are resolved in a
  3404. -predictable way and would be difficult to eliminate.  It is desirable
  3405. -to suppress the warning about these conflicts unless the number of
  3406. -conflicts changes.  You can do this with the `%expect' declaration.
  3407. -
  3408. -   The declaration looks like this:
  3409. -
  3410. -     %expect N
  3411. -
  3412. -   Here N is a decimal integer.  The declaration says there should be no
  3413. -warning if there are N shift/reduce conflicts and no reduce/reduce
  3414. -conflicts.  The usual warning is given if there are either more or fewer
  3415. -conflicts, or if there are any reduce/reduce conflicts.
  3416. -
  3417. -   In general, using `%expect' involves these steps:
  3418. -
  3419. -   * Compile your grammar without `%expect'.  Use the `-v' option to
  3420. -     get a verbose list of where the conflicts occur.  Bison will also
  3421. -     print the number of conflicts.
  3422. -
  3423. -   * Check each of the conflicts to make sure that Bison's default
  3424. -     resolution is what you really want.  If not, rewrite the grammar
  3425. -     and go back to the beginning.
  3426. -
  3427. -   * Add an `%expect' declaration, copying the number N from the number
  3428. -     which Bison printed.
  3429. -
  3430. -   Now Bison will stop annoying you about the conflicts you have
  3431. -checked, but it will warn you again if changes in the grammar result in
  3432. -additional conflicts.
  3433. -
  3434. -
  3435. -File: bison.info,  Node: Start Decl,  Next: Pure Decl,  Prev: Expect Decl,  Up: Declarations
  3436. -
  3437. -The Start-Symbol
  3438. -----------------
  3439. -
  3440. -   Bison assumes by default that the start symbol for the grammar is
  3441. -the first nonterminal specified in the grammar specification section.
  3442. -The programmer may override this restriction with the `%start'
  3443. -declaration as follows:
  3444. -
  3445. -     %start SYMBOL
  3446. -
  3447. -
  3448. -File: bison.info,  Node: Pure Decl,  Next: Decl Summary,  Prev: Start Decl,  Up: Declarations
  3449. -
  3450. -A Pure (Reentrant) Parser
  3451. --------------------------
  3452. -
  3453. -   A "reentrant" program is one which does not alter in the course of
  3454. -execution; in other words, it consists entirely of "pure" (read-only)
  3455. -code.  Reentrancy is important whenever asynchronous execution is
  3456. -possible; for example, a nonreentrant program may not be safe to call
  3457. -from a signal handler.  In systems with multiple threads of control, a
  3458. -nonreentrant program must be called only within interlocks.
  3459. -
  3460. -   The Bison parser is not normally a reentrant program, because it uses
  3461. -statically allocated variables for communication with `yylex'.  These
  3462. -variables include `yylval' and `yylloc'.
  3463. -
  3464. -   The Bison declaration `%pure_parser' says that you want the parser
  3465. -to be reentrant.  It looks like this:
  3466. -
  3467. -     %pure_parser
  3468. -
  3469. -   The effect is that the two communication variables become local
  3470. -variables in `yyparse', and a different calling convention is used for
  3471. -the lexical analyzer function `yylex'.  *Note Calling Conventions for
  3472. -Pure Parsers: Pure Calling, for the details of this.  The variable
  3473. -`yynerrs' also becomes local in `yyparse' (*note The Error Reporting
  3474. -Function `yyerror': Error Reporting.).  The convention for calling
  3475. -`yyparse' itself is unchanged.
  3476. -
  3477. -
  3478. -File: bison.info,  Node: Decl Summary,  Prev: Pure Decl,  Up: Declarations
  3479. -
  3480. -Bison Declaration Summary
  3481. --------------------------
  3482. -
  3483. -   Here is a summary of all Bison declarations:
  3484. -
  3485. -`%union'
  3486. -     Declare the collection of data types that semantic values may have
  3487. -     (*note The Collection of Value Types: Union Decl.).
  3488. -
  3489. -`%token'
  3490. -     Declare a terminal symbol (token type name) with no precedence or
  3491. -     associativity specified (*note Token Type Names: Token Decl.).
  3492. -
  3493. -`%right'
  3494. -     Declare a terminal symbol (token type name) that is
  3495. -     right-associative (*note Operator Precedence: Precedence Decl.).
  3496. -
  3497. -`%left'
  3498. -     Declare a terminal symbol (token type name) that is
  3499. -     left-associative (*note Operator Precedence: Precedence Decl.).
  3500. -
  3501. -`%nonassoc'
  3502. -     Declare a terminal symbol (token type name) that is nonassociative
  3503. -     (using it in a way that would be associative is a syntax error)
  3504. -     (*note Operator Precedence: Precedence Decl.).
  3505. -
  3506. -`%type'
  3507. -     Declare the type of semantic values for a nonterminal symbol
  3508. -     (*note Nonterminal Symbols: Type Decl.).
  3509. -
  3510. -`%start'
  3511. -     Specify the grammar's start symbol (*note The Start-Symbol: Start
  3512. -     Decl.).
  3513. -
  3514. -`%expect'
  3515. -     Declare the expected number of shift-reduce conflicts (*note
  3516. -     Suppressing Conflict Warnings: Expect Decl.).
  3517. -
  3518. -`%pure_parser'
  3519. -     Request a pure (reentrant) parser program (*note A Pure
  3520. -     (Reentrant) Parser: Pure Decl.).
  3521. -
  3522. -`%no_lines'
  3523. -     Don't generate any `#line' preprocessor commands in the parser
  3524. -     file.  Ordinarily Bison writes these commands in the parser file
  3525. -     so that the C compiler and debuggers will associate errors and
  3526. -     object code with your source file (the grammar file).  This
  3527. -     directive causes them to associate errors with the parser file,
  3528. -     treating it an independent source file in its own right.
  3529. -
  3530. -`%raw'
  3531. -     The output file `NAME.h' normally defines the tokens with
  3532. -     Yacc-compatible token numbers.  If this option is specified, the
  3533. -     internal Bison numbers are used instead.  (Yacc-compatible numbers
  3534. -     start at 257 except for single character tokens; Bison assigns
  3535. -     token numbers sequentially for all tokens starting at 3.)
  3536. -
  3537. -`%token_table'
  3538. -     Generate an array of token names in the parser file.  The name of
  3539. -     the array is `yytname'; `yytname[I]' is the name of the token
  3540. -     whose internal Bison token code number is I.  The first three
  3541. -     elements of `yytname' are always `"$"', `"error"', and
  3542. -     `"$illegal"'; after these come the symbols defined in the grammar
  3543. -     file.
  3544. -
  3545. -     For single-character literal tokens and literal string tokens, the
  3546. -     name in the table includes the single-quote or double-quote
  3547. -     characters: for example, `"'+'"' is a single-character literal and
  3548. -     `"\"<=\""' is a literal string token.  All the characters of the
  3549. -     literal string token appear verbatim in the string found in the
  3550. -     table; even double-quote characters are not escaped.  For example,
  3551. -     if the token consists of three characters `*"*', its string in
  3552. -     `yytname' contains `"*"*"'.  (In C, that would be written as
  3553. -     `"\"*\"*\""').
  3554. -
  3555. -     When you specify `%token_table', Bison also generates macro
  3556. -     definitions for macros `YYNTOKENS', `YYNNTS', and `YYNRULES', and
  3557. -     `YYNSTATES':
  3558. -
  3559. -    `YYNTOKENS'
  3560. -          The highest token number, plus one.
  3561. -
  3562. -    `YYNNTS'
  3563. -          The number of non-terminal symbols.
  3564. -
  3565. -    `YYNRULES'
  3566. -          The number of grammar rules,
  3567. -
  3568. -    `YYNSTATES'
  3569. -          The number of parser states (*note Parser States::.).
  3570. -
  3571. -
  3572. -File: bison.info,  Node: Multiple Parsers,  Prev: Declarations,  Up: Grammar File
  3573. -
  3574. -Multiple Parsers in the Same Program
  3575. -====================================
  3576. -
  3577. -   Most programs that use Bison parse only one language and therefore
  3578. -contain only one Bison parser.  But what if you want to parse more than
  3579. -one language with the same program?  Then you need to avoid a name
  3580. -conflict between different definitions of `yyparse', `yylval', and so
  3581. -on.
  3582. -
  3583. -   The easy way to do this is to use the option `-p PREFIX' (*note
  3584. -Invoking Bison: Invocation.).  This renames the interface functions and
  3585. -variables of the Bison parser to start with PREFIX instead of `yy'.
  3586. -You can use this to give each parser distinct names that do not
  3587. -conflict.
  3588. -
  3589. -   The precise list of symbols renamed is `yyparse', `yylex',
  3590. -`yyerror', `yynerrs', `yylval', `yychar' and `yydebug'.  For example,
  3591. -if you use `-p c', the names become `cparse', `clex', and so on.
  3592. -
  3593. -   *All the other variables and macros associated with Bison are not
  3594. -renamed.* These others are not global; there is no conflict if the same
  3595. -name is used in different parsers.  For example, `YYSTYPE' is not
  3596. -renamed, but defining this in different ways in different parsers causes
  3597. -no trouble (*note Data Types of Semantic Values: Value Type.).
  3598. -
  3599. -   The `-p' option works by adding macro definitions to the beginning
  3600. -of the parser source file, defining `yyparse' as `PREFIXparse', and so
  3601. -on.  This effectively substitutes one name for the other in the entire
  3602. -parser file.
  3603. -
  3604. -
  3605. -File: bison.info,  Node: Interface,  Next: Algorithm,  Prev: Grammar File,  Up: Top
  3606. -
  3607. -Parser C-Language Interface
  3608. -***************************
  3609. -
  3610. -   The Bison parser is actually a C function named `yyparse'.  Here we
  3611. -describe the interface conventions of `yyparse' and the other functions
  3612. -that it needs to use.
  3613. -
  3614. -   Keep in mind that the parser uses many C identifiers starting with
  3615. -`yy' and `YY' for internal purposes.  If you use such an identifier
  3616. -(aside from those in this manual) in an action or in additional C code
  3617. -in the grammar file, you are likely to run into trouble.
  3618. -
  3619. -* Menu:
  3620. -
  3621. -* Parser Function::   How to call `yyparse' and what it returns.
  3622. -* Lexical::           You must supply a function `yylex'
  3623. -                        which reads tokens.
  3624. -* Error Reporting::   You must supply a function `yyerror'.
  3625. -* Action Features::   Special features for use in actions.
  3626. -
  3627. -
  3628. -File: bison.info,  Node: Parser Function,  Next: Lexical,  Up: Interface
  3629. -
  3630. -The Parser Function `yyparse'
  3631. -=============================
  3632. -
  3633. -   You call the function `yyparse' to cause parsing to occur.  This
  3634. -function reads tokens, executes actions, and ultimately returns when it
  3635. -encounters end-of-input or an unrecoverable syntax error.  You can also
  3636. -write an action which directs `yyparse' to return immediately without
  3637. -reading further.
  3638. -
  3639. -   The value returned by `yyparse' is 0 if parsing was successful
  3640. -(return is due to end-of-input).
  3641. -
  3642. -   The value is 1 if parsing failed (return is due to a syntax error).
  3643. -
  3644. -   In an action, you can cause immediate return from `yyparse' by using
  3645. -these macros:
  3646. -
  3647. -`YYACCEPT'
  3648. -     Return immediately with value 0 (to report success).
  3649. -
  3650. -`YYABORT'
  3651. -     Return immediately with value 1 (to report failure).
  3652. -
  3653. -
  3654. -File: bison.info,  Node: Lexical,  Next: Error Reporting,  Prev: Parser Function,  Up: Interface
  3655. -
  3656. -The Lexical Analyzer Function `yylex'
  3657. -=====================================
  3658. -
  3659. -   The "lexical analyzer" function, `yylex', recognizes tokens from the
  3660. -input stream and returns them to the parser.  Bison does not create
  3661. -this function automatically; you must write it so that `yyparse' can
  3662. -call it.  The function is sometimes referred to as a lexical scanner.
  3663. -
  3664. -   In simple programs, `yylex' is often defined at the end of the Bison
  3665. -grammar file.  If `yylex' is defined in a separate source file, you
  3666. -need to arrange for the token-type macro definitions to be available
  3667. -there.  To do this, use the `-d' option when you run Bison, so that it
  3668. -will write these macro definitions into a separate header file
  3669. -`NAME.tab.h' which you can include in the other source files that need
  3670. -it.  *Note Invoking Bison: Invocation.
  3671. -
  3672. -* Menu:
  3673. -
  3674. -* Calling Convention::  How `yyparse' calls `yylex'.
  3675. -* Token Values::      How `yylex' must return the semantic value
  3676. -                        of the token it has read.
  3677. -* Token Positions::   How `yylex' must return the text position
  3678. -                        (line number, etc.) of the token, if the
  3679. -                        actions want that.
  3680. -* Pure Calling::      How the calling convention differs
  3681. -                        in a pure parser (*note A Pure (Reentrant) Parser: Pure Decl.).
  3682. -
  3683. -
  3684. -File: bison.info,  Node: Calling Convention,  Next: Token Values,  Up: Lexical
  3685. -
  3686. -Calling Convention for `yylex'
  3687. -------------------------------
  3688. -
  3689. -   The value that `yylex' returns must be the numeric code for the type
  3690. -of token it has just found, or 0 for end-of-input.
  3691. -
  3692. -   When a token is referred to in the grammar rules by a name, that name
  3693. -in the parser file becomes a C macro whose definition is the proper
  3694. -numeric code for that token type.  So `yylex' can use the name to
  3695. -indicate that type.  *Note Symbols::.
  3696. -
  3697. -   When a token is referred to in the grammar rules by a character
  3698. -literal, the numeric code for that character is also the code for the
  3699. -token type.  So `yylex' can simply return that character code.  The
  3700. -null character must not be used this way, because its code is zero and
  3701. -that is what signifies end-of-input.
  3702. -
  3703. -   Here is an example showing these things:
  3704. -
  3705. -     yylex ()
  3706. -     {
  3707. -       ...
  3708. -       if (c == EOF)     /* Detect end of file. */
  3709. -         return 0;
  3710. -       ...
  3711. -       if (c == '+' || c == '-')
  3712. -         return c;      /* Assume token type for `+' is '+'. */
  3713. -       ...
  3714. -       return INT;      /* Return the type of the token. */
  3715. -       ...
  3716. -     }
  3717. -
  3718. -This interface has been designed so that the output from the `lex'
  3719. -utility can be used without change as the definition of `yylex'.
  3720. -
  3721. -   If the grammar uses literal string tokens, there are two ways that
  3722. -`yylex' can determine the token type codes for them:
  3723. -
  3724. -   * If the grammar defines symbolic token names as aliases for the
  3725. -     literal string tokens, `yylex' can use these symbolic names like
  3726. -     all others.  In this case, the use of the literal string tokens in
  3727. -     the grammar file has no effect on `yylex'.
  3728. -
  3729. -   * `yylex' can find the multi-character token in the `yytname' table.
  3730. -     The index of the token in the table is the token type's code.
  3731. -     The name of a multi-character token is recorded in `yytname' with a
  3732. -     double-quote, the token's characters, and another double-quote.
  3733. -     The token's characters are not escaped in any way; they appear
  3734. -     verbatim in the contents of the string in the table.
  3735. -
  3736. -     Here's code for looking up a token in `yytname', assuming that the
  3737. -     characters of the token are stored in `token_buffer'.
  3738. -
  3739. -          for (i = 0; i < YYNTOKENS; i++)
  3740. -            {
  3741. -              if (yytname[i] != 0
  3742. -                  && yytname[i][0] == '"'
  3743. -                  && strncmp (yytname[i] + 1, token_buffer, strlen (token_buffer))
  3744. -                  && yytname[i][strlen (token_buffer) + 1] == '"'
  3745. -                  && yytname[i][strlen (token_buffer) + 2] == 0)
  3746. -                break;
  3747. -            }
  3748. -
  3749. -     The `yytname' table is generated only if you use the
  3750. -     `%token_table' declaration.  *Note Decl Summary::.
  3751. -
  3752. -
  3753. -File: bison.info,  Node: Token Values,  Next: Token Positions,  Prev: Calling Convention,  Up: Lexical
  3754. -
  3755. -Semantic Values of Tokens
  3756. --------------------------
  3757. -
  3758. -   In an ordinary (nonreentrant) parser, the semantic value of the
  3759. -token must be stored into the global variable `yylval'.  When you are
  3760. -using just one data type for semantic values, `yylval' has that type.
  3761. -Thus, if the type is `int' (the default), you might write this in
  3762. -`yylex':
  3763. -
  3764. -       ...
  3765. -       yylval = value;  /* Put value onto Bison stack. */
  3766. -       return INT;      /* Return the type of the token. */
  3767. -       ...
  3768. -
  3769. -   When you are using multiple data types, `yylval''s type is a union
  3770. -made from the `%union' declaration (*note The Collection of Value
  3771. -Types: Union Decl.).  So when you store a token's value, you must use
  3772. -the proper member of the union.  If the `%union' declaration looks like
  3773. -this:
  3774. -
  3775. -     %union {
  3776. -       int intval;
  3777. -       double val;
  3778. -       symrec *tptr;
  3779. -     }
  3780. -
  3781. -then the code in `yylex' might look like this:
  3782. -
  3783. -       ...
  3784. -       yylval.intval = value; /* Put value onto Bison stack. */
  3785. -       return INT;          /* Return the type of the token. */
  3786. -       ...
  3787. -
  3788. -
  3789. -File: bison.info,  Node: Token Positions,  Next: Pure Calling,  Prev: Token Values,  Up: Lexical
  3790. -
  3791. -Textual Positions of Tokens
  3792. ----------------------------
  3793. -
  3794. -   If you are using the `@N'-feature (*note Special Features for Use in
  3795. -Actions: Action Features.) in actions to keep track of the textual
  3796. -locations of tokens and groupings, then you must provide this
  3797. -information in `yylex'.  The function `yyparse' expects to find the
  3798. -textual location of a token just parsed in the global variable
  3799. -`yylloc'.  So `yylex' must store the proper data in that variable.  The
  3800. -value of `yylloc' is a structure and you need only initialize the
  3801. -members that are going to be used by the actions.  The four members are
  3802. -called `first_line', `first_column', `last_line' and `last_column'.
  3803. -Note that the use of this feature makes the parser noticeably slower.
  3804. -
  3805. -   The data type of `yylloc' has the name `YYLTYPE'.
  3806. -
  3807. -
  3808. -File: bison.info,  Node: Pure Calling,  Prev: Token Positions,  Up: Lexical
  3809. -
  3810. -Calling Conventions for Pure Parsers
  3811. -------------------------------------
  3812. -
  3813. -   When you use the Bison declaration `%pure_parser' to request a pure,
  3814. -reentrant parser, the global communication variables `yylval' and
  3815. -`yylloc' cannot be used.  (*Note A Pure (Reentrant) Parser: Pure Decl.)
  3816. -In such parsers the two global variables are replaced by pointers
  3817. -passed as arguments to `yylex'.  You must declare them as shown here,
  3818. -and pass the information back by storing it through those pointers.
  3819. -
  3820. -     yylex (lvalp, llocp)
  3821. -          YYSTYPE *lvalp;
  3822. -          YYLTYPE *llocp;
  3823. -     {
  3824. -       ...
  3825. -       *lvalp = value;  /* Put value onto Bison stack.  */
  3826. -       return INT;      /* Return the type of the token.  */
  3827. -       ...
  3828. -     }
  3829. -
  3830. -   If the grammar file does not use the `@' constructs to refer to
  3831. -textual positions, then the type `YYLTYPE' will not be defined.  In
  3832. -this case, omit the second argument; `yylex' will be called with only
  3833. -one argument.
  3834. -
  3835. -   If you use a reentrant parser, you can optionally pass additional
  3836. -parameter information to it in a reentrant way.  To do so, define the
  3837. -macro `YYPARSE_PARAM' as a variable name.  This modifies the `yyparse'
  3838. -function to accept one argument, of type `void *', with that name.
  3839. -
  3840. -   When you call `yyparse', pass the address of an object, casting the
  3841. -address to `void *'.  The grammar actions can refer to the contents of
  3842. -the object by casting the pointer value back to its proper type and
  3843. -then dereferencing it.  Here's an example.  Write this in the parser:
  3844. -
  3845. -     %{
  3846. -     struct parser_control
  3847. -     {
  3848. -       int nastiness;
  3849. -       int randomness;
  3850. -     };
  3851. -     
  3852. -     #define YYPARSE_PARAM parm
  3853. -     %}
  3854. -
  3855. -Then call the parser like this:
  3856. -
  3857. -     struct parser_control
  3858. -     {
  3859. -       int nastiness;
  3860. -       int randomness;
  3861. -     };
  3862. -     
  3863. -     ...
  3864. -     
  3865. -     {
  3866. -       struct parser_control foo;
  3867. -       ...  /* Store proper data in `foo'.  */
  3868. -       value = yyparse ((void *) &foo);
  3869. -       ...
  3870. -     }
  3871. -
  3872. -In the grammar actions, use expressions like this to refer to the data:
  3873. -
  3874. -     ((struct parser_control *) parm)->randomness
  3875. -
  3876. -   If you wish to pass the additional parameter data to `yylex', define
  3877. -the macro `YYLEX_PARAM' just like `YYPARSE_PARAM', as shown here:
  3878. -
  3879. -     %{
  3880. -     struct parser_control
  3881. -     {
  3882. -       int nastiness;
  3883. -       int randomness;
  3884. -     };
  3885. -     
  3886. -     #define YYPARSE_PARAM parm
  3887. -     #define YYLEX_PARAM parm
  3888. -     %}
  3889. -
  3890. -   You should then define `yylex' to accept one additional
  3891. -argument--the value of `parm'.  (This makes either two or three
  3892. -arguments in total, depending on whether an argument of type `YYLTYPE'
  3893. -is passed.)  You can declare the argument as a pointer to the proper
  3894. -object type, or you can declare it as `void *' and access the contents
  3895. -as shown above.
  3896. -
  3897. -   You can use `%pure_parser' to request a reentrant parser without
  3898. -also using `YYPARSE_PARAM'.  Then you should call `yyparse' with no
  3899. -arguments, as usual.
  3900. -
  3901. -
  3902. -File: bison.info,  Node: Error Reporting,  Next: Action Features,  Prev: Lexical,  Up: Interface
  3903. -
  3904. -The Error Reporting Function `yyerror'
  3905. -======================================
  3906. -
  3907. -   The Bison parser detects a "parse error" or "syntax error" whenever
  3908. -it reads a token which cannot satisfy any syntax rule.  A action in the
  3909. -grammar can also explicitly proclaim an error, using the macro
  3910. -`YYERROR' (*note Special Features for Use in Actions: Action Features.).
  3911. -
  3912. -   The Bison parser expects to report the error by calling an error
  3913. -reporting function named `yyerror', which you must supply.  It is
  3914. -called by `yyparse' whenever a syntax error is found, and it receives
  3915. -one argument.  For a parse error, the string is normally
  3916. -`"parse error"'.
  3917. -
  3918. -   If you define the macro `YYERROR_VERBOSE' in the Bison declarations
  3919. -section (*note The Bison Declarations Section: Bison Declarations.),
  3920. -then Bison provides a more verbose and specific error message string
  3921. -instead of just plain `"parse error"'.  It doesn't matter what
  3922. -definition you use for `YYERROR_VERBOSE', just whether you define it.
  3923. -
  3924. -   The parser can detect one other kind of error: stack overflow.  This
  3925. -happens when the input contains constructions that are very deeply
  3926. -nested.  It isn't likely you will encounter this, since the Bison
  3927. -parser extends its stack automatically up to a very large limit.  But
  3928. -if overflow happens, `yyparse' calls `yyerror' in the usual fashion,
  3929. -except that the argument string is `"parser stack overflow"'.
  3930. -
  3931. -   The following definition suffices in simple programs:
  3932. -
  3933. -     yyerror (s)
  3934. -          char *s;
  3935. -     {
  3936. -       fprintf (stderr, "%s\n", s);
  3937. -     }
  3938. -
  3939. -   After `yyerror' returns to `yyparse', the latter will attempt error
  3940. -recovery if you have written suitable error recovery grammar rules
  3941. -(*note Error Recovery::.).  If recovery is impossible, `yyparse' will
  3942. -immediately return 1.
  3943. -
  3944. -   The variable `yynerrs' contains the number of syntax errors
  3945. -encountered so far.  Normally this variable is global; but if you
  3946. -request a pure parser (*note A Pure (Reentrant) Parser: Pure Decl.)
  3947. -then it is a local variable which only the actions can access.
  3948. -
  3949. -
  3950. -File: bison.info,  Node: Action Features,  Prev: Error Reporting,  Up: Interface
  3951. -
  3952. -Special Features for Use in Actions
  3953. -===================================
  3954. -
  3955. -   Here is a table of Bison constructs, variables and macros that are
  3956. -useful in actions.
  3957. -
  3958. -`$$'
  3959. -     Acts like a variable that contains the semantic value for the
  3960. -     grouping made by the current rule.  *Note Actions::.
  3961. -
  3962. -`$N'
  3963. -     Acts like a variable that contains the semantic value for the Nth
  3964. -     component of the current rule.  *Note Actions::.
  3965. -
  3966. -`$<TYPEALT>$'
  3967. -     Like `$$' but specifies alternative TYPEALT in the union specified
  3968. -     by the `%union' declaration.  *Note Data Types of Values in
  3969. -     Actions: Action Types.
  3970. -
  3971. -`$<TYPEALT>N'
  3972. -     Like `$N' but specifies alternative TYPEALT in the union specified
  3973. -     by the `%union' declaration.  *Note Data Types of Values in
  3974. -     Actions: Action Types.
  3975. -
  3976. -`YYABORT;'
  3977. -     Return immediately from `yyparse', indicating failure.  *Note The
  3978. -     Parser Function `yyparse': Parser Function.
  3979. -
  3980. -`YYACCEPT;'
  3981. -     Return immediately from `yyparse', indicating success.  *Note The
  3982. -     Parser Function `yyparse': Parser Function.
  3983. -
  3984. -`YYBACKUP (TOKEN, VALUE);'
  3985. -     Unshift a token.  This macro is allowed only for rules that reduce
  3986. -     a single value, and only when there is no look-ahead token.  It
  3987. -     installs a look-ahead token with token type TOKEN and semantic
  3988. -     value VALUE; then it discards the value that was going to be
  3989. -     reduced by this rule.
  3990. -
  3991. -     If the macro is used when it is not valid, such as when there is a
  3992. -     look-ahead token already, then it reports a syntax error with a
  3993. -     message `cannot back up' and performs ordinary error recovery.
  3994. -
  3995. -     In either case, the rest of the action is not executed.
  3996. -
  3997. -`YYEMPTY'
  3998. -     Value stored in `yychar' when there is no look-ahead token.
  3999. -
  4000. -`YYERROR;'
  4001. -     Cause an immediate syntax error.  This statement initiates error
  4002. -     recovery just as if the parser itself had detected an error;
  4003. -     however, it does not call `yyerror', and does not print any
  4004. -     message.  If you want to print an error message, call `yyerror'
  4005. -     explicitly before the `YYERROR;' statement.  *Note Error
  4006. -     Recovery::.
  4007. -
  4008. -`YYRECOVERING'
  4009. -     This macro stands for an expression that has the value 1 when the
  4010. -     parser is recovering from a syntax error, and 0 the rest of the
  4011. -     time.  *Note Error Recovery::.
  4012. -
  4013. -`yychar'
  4014. -     Variable containing the current look-ahead token.  (In a pure
  4015. -     parser, this is actually a local variable within `yyparse'.)  When
  4016. -     there is no look-ahead token, the value `YYEMPTY' is stored in the
  4017. -     variable.  *Note Look-Ahead Tokens: Look-Ahead.
  4018. -
  4019. -`yyclearin;'
  4020. -     Discard the current look-ahead token.  This is useful primarily in
  4021. -     error rules.  *Note Error Recovery::.
  4022. -
  4023. -`yyerrok;'
  4024. -     Resume generating error messages immediately for subsequent syntax
  4025. -     errors.  This is useful primarily in error rules.  *Note Error
  4026. -     Recovery::.
  4027. -
  4028. -`@N'
  4029. -     Acts like a structure variable containing information on the line
  4030. -     numbers and column numbers of the Nth component of the current
  4031. -     rule.  The structure has four members, like this:
  4032. -
  4033. -          struct {
  4034. -            int first_line, last_line;
  4035. -            int first_column, last_column;
  4036. -          };
  4037. -
  4038. -     Thus, to get the starting line number of the third component, use
  4039. -     `@3.first_line'.
  4040. -
  4041. -     In order for the members of this structure to contain valid
  4042. -     information, you must make `yylex' supply this information about
  4043. -     each token.  If you need only certain members, then `yylex' need
  4044. -     only fill in those members.
  4045. -
  4046. -     The use of this feature makes the parser noticeably slower.
  4047. -
  4048. -
  4049. -File: bison.info,  Node: Algorithm,  Next: Error Recovery,  Prev: Interface,  Up: Top
  4050. -
  4051. -The Bison Parser Algorithm
  4052. -**************************
  4053. -
  4054. -   As Bison reads tokens, it pushes them onto a stack along with their
  4055. -semantic values.  The stack is called the "parser stack".  Pushing a
  4056. -token is traditionally called "shifting".
  4057. -
  4058. -   For example, suppose the infix calculator has read `1 + 5 *', with a
  4059. -`3' to come.  The stack will have four elements, one for each token
  4060. -that was shifted.
  4061. -
  4062. -   But the stack does not always have an element for each token read.
  4063. -When the last N tokens and groupings shifted match the components of a
  4064. -grammar rule, they can be combined according to that rule.  This is
  4065. -called "reduction".  Those tokens and groupings are replaced on the
  4066. -stack by a single grouping whose symbol is the result (left hand side)
  4067. -of that rule.  Running the rule's action is part of the process of
  4068. -reduction, because this is what computes the semantic value of the
  4069. -resulting grouping.
  4070. -
  4071. -   For example, if the infix calculator's parser stack contains this:
  4072. -
  4073. -     1 + 5 * 3
  4074. -
  4075. -and the next input token is a newline character, then the last three
  4076. -elements can be reduced to 15 via the rule:
  4077. -
  4078. -     expr: expr '*' expr;
  4079. -
  4080. -Then the stack contains just these three elements:
  4081. -
  4082. -     1 + 15
  4083. -
  4084. -At this point, another reduction can be made, resulting in the single
  4085. -value 16.  Then the newline token can be shifted.
  4086. -
  4087. -   The parser tries, by shifts and reductions, to reduce the entire
  4088. -input down to a single grouping whose symbol is the grammar's
  4089. -start-symbol (*note Languages and Context-Free Grammars: Language and
  4090. -Grammar.).
  4091. -
  4092. -   This kind of parser is known in the literature as a bottom-up parser.
  4093. -
  4094. -* Menu:
  4095. -
  4096. -* Look-Ahead::        Parser looks one token ahead when deciding what to do.
  4097. -* Shift/Reduce::      Conflicts: when either shifting or reduction is valid.
  4098. -* Precedence::        Operator precedence works by resolving conflicts.
  4099. -* Contextual Precedence::  When an operator's precedence depends on context.
  4100. -* Parser States::     The parser is a finite-state-machine with stack.
  4101. -* Reduce/Reduce::     When two rules are applicable in the same situation.
  4102. -* Mystery Conflicts::  Reduce/reduce conflicts that look unjustified.
  4103. -* Stack Overflow::    What happens when stack gets full.  How to avoid it.
  4104. -
  4105. -
  4106. -File: bison.info,  Node: Look-Ahead,  Next: Shift/Reduce,  Up: Algorithm
  4107. -
  4108. -Look-Ahead Tokens
  4109. -=================
  4110. -
  4111. -   The Bison parser does *not* always reduce immediately as soon as the
  4112. -last N tokens and groupings match a rule.  This is because such a
  4113. -simple strategy is inadequate to handle most languages.  Instead, when a
  4114. -reduction is possible, the parser sometimes "looks ahead" at the next
  4115. -token in order to decide what to do.
  4116. -
  4117. -   When a token is read, it is not immediately shifted; first it
  4118. -becomes the "look-ahead token", which is not on the stack.  Now the
  4119. -parser can perform one or more reductions of tokens and groupings on
  4120. -the stack, while the look-ahead token remains off to the side.  When no
  4121. -more reductions should take place, the look-ahead token is shifted onto
  4122. -the stack.  This does not mean that all possible reductions have been
  4123. -done; depending on the token type of the look-ahead token, some rules
  4124. -may choose to delay their application.
  4125. -
  4126. -   Here is a simple case where look-ahead is needed.  These three rules
  4127. -define expressions which contain binary addition operators and postfix
  4128. -unary factorial operators (`!'), and allow parentheses for grouping.
  4129. -
  4130. -     expr:     term '+' expr
  4131. -             | term
  4132. -             ;
  4133. -     
  4134. -     term:     '(' expr ')'
  4135. -             | term '!'
  4136. -             | NUMBER
  4137. -             ;
  4138. -
  4139. -   Suppose that the tokens `1 + 2' have been read and shifted; what
  4140. -should be done?  If the following token is `)', then the first three
  4141. -tokens must be reduced to form an `expr'.  This is the only valid
  4142. -course, because shifting the `)' would produce a sequence of symbols
  4143. -`term ')'', and no rule allows this.
  4144. -
  4145. -   If the following token is `!', then it must be shifted immediately so
  4146. -that `2 !' can be reduced to make a `term'.  If instead the parser were
  4147. -to reduce before shifting, `1 + 2' would become an `expr'.  It would
  4148. -then be impossible to shift the `!' because doing so would produce on
  4149. -the stack the sequence of symbols `expr '!''.  No rule allows that
  4150. -sequence.
  4151. -
  4152. -   The current look-ahead token is stored in the variable `yychar'.
  4153. -*Note Special Features for Use in Actions: Action Features.
  4154. -
  4155. -
  4156. -File: bison.info,  Node: Shift/Reduce,  Next: Precedence,  Prev: Look-Ahead,  Up: Algorithm
  4157. -
  4158. -Shift/Reduce Conflicts
  4159. -======================
  4160. -
  4161. -   Suppose we are parsing a language which has if-then and if-then-else
  4162. -statements, with a pair of rules like this:
  4163. -
  4164. -     if_stmt:
  4165. -               IF expr THEN stmt
  4166. -             | IF expr THEN stmt ELSE stmt
  4167. -             ;
  4168. -
  4169. -Here we assume that `IF', `THEN' and `ELSE' are terminal symbols for
  4170. -specific keyword tokens.
  4171. -
  4172. -   When the `ELSE' token is read and becomes the look-ahead token, the
  4173. -contents of the stack (assuming the input is valid) are just right for
  4174. -reduction by the first rule.  But it is also legitimate to shift the
  4175. -`ELSE', because that would lead to eventual reduction by the second
  4176. -rule.
  4177. -
  4178. -   This situation, where either a shift or a reduction would be valid,
  4179. -is called a "shift/reduce conflict".  Bison is designed to resolve
  4180. -these conflicts by choosing to shift, unless otherwise directed by
  4181. -operator precedence declarations.  To see the reason for this, let's
  4182. -contrast it with the other alternative.
  4183. -
  4184. -   Since the parser prefers to shift the `ELSE', the result is to attach
  4185. -the else-clause to the innermost if-statement, making these two inputs
  4186. -equivalent:
  4187. -
  4188. -     if x then if y then win (); else lose;
  4189. -     
  4190. -     if x then do; if y then win (); else lose; end;
  4191. -
  4192. -   But if the parser chose to reduce when possible rather than shift,
  4193. -the result would be to attach the else-clause to the outermost
  4194. -if-statement, making these two inputs equivalent:
  4195. -
  4196. -     if x then if y then win (); else lose;
  4197. -     
  4198. -     if x then do; if y then win (); end; else lose;
  4199. -
  4200. -   The conflict exists because the grammar as written is ambiguous:
  4201. -either parsing of the simple nested if-statement is legitimate.  The
  4202. -established convention is that these ambiguities are resolved by
  4203. -attaching the else-clause to the innermost if-statement; this is what
  4204. -Bison accomplishes by choosing to shift rather than reduce.  (It would
  4205. -ideally be cleaner to write an unambiguous grammar, but that is very
  4206. -hard to do in this case.) This particular ambiguity was first
  4207. -encountered in the specifications of Algol 60 and is called the
  4208. -"dangling `else'" ambiguity.
  4209. -
  4210. -   To avoid warnings from Bison about predictable, legitimate
  4211. -shift/reduce conflicts, use the `%expect N' declaration.  There will be
  4212. -no warning as long as the number of shift/reduce conflicts is exactly N.
  4213. -*Note Suppressing Conflict Warnings: Expect Decl.
  4214. -
  4215. -   The definition of `if_stmt' above is solely to blame for the
  4216. -conflict, but the conflict does not actually appear without additional
  4217. -rules.  Here is a complete Bison input file that actually manifests the
  4218. -conflict:
  4219. -
  4220. -     %token IF THEN ELSE variable
  4221. -     %%
  4222. -     stmt:     expr
  4223. -             | if_stmt
  4224. -             ;
  4225. -     
  4226. -     if_stmt:
  4227. -               IF expr THEN stmt
  4228. -             | IF expr THEN stmt ELSE stmt
  4229. -             ;
  4230. -     
  4231. -     expr:     variable
  4232. -             ;
  4233. -
  4234. -
  4235. -File: bison.info,  Node: Precedence,  Next: Contextual Precedence,  Prev: Shift/Reduce,  Up: Algorithm
  4236. -
  4237. -Operator Precedence
  4238. -===================
  4239. -
  4240. -   Another situation where shift/reduce conflicts appear is in
  4241. -arithmetic expressions.  Here shifting is not always the preferred
  4242. -resolution; the Bison declarations for operator precedence allow you to
  4243. -specify when to shift and when to reduce.
  4244. -
  4245. -* Menu:
  4246. -
  4247. -* Why Precedence::    An example showing why precedence is needed.
  4248. -* Using Precedence::  How to specify precedence in Bison grammars.
  4249. -* Precedence Examples::  How these features are used in the previous example.
  4250. -* How Precedence::    How they work.
  4251. -
  4252. -
  4253. -File: bison.info,  Node: Why Precedence,  Next: Using Precedence,  Up: Precedence
  4254. -
  4255. -When Precedence is Needed
  4256. --------------------------
  4257. -
  4258. -   Consider the following ambiguous grammar fragment (ambiguous because
  4259. -the input `1 - 2 * 3' can be parsed in two different ways):
  4260. -
  4261. -     expr:     expr '-' expr
  4262. -             | expr '*' expr
  4263. -             | expr '<' expr
  4264. -             | '(' expr ')'
  4265. -             ...
  4266. -             ;
  4267. -
  4268. -Suppose the parser has seen the tokens `1', `-' and `2'; should it
  4269. -reduce them via the rule for the addition operator?  It depends on the
  4270. -next token.  Of course, if the next token is `)', we must reduce;
  4271. -shifting is invalid because no single rule can reduce the token
  4272. -sequence `- 2 )' or anything starting with that.  But if the next token
  4273. -is `*' or `<', we have a choice: either shifting or reduction would
  4274. -allow the parse to complete, but with different results.
  4275. -
  4276. -   To decide which one Bison should do, we must consider the results.
  4277. -If the next operator token OP is shifted, then it must be reduced first
  4278. -in order to permit another opportunity to reduce the sum.  The result
  4279. -is (in effect) `1 - (2 OP 3)'.  On the other hand, if the subtraction
  4280. -is reduced before shifting OP, the result is `(1 - 2) OP 3'.  Clearly,
  4281. -then, the choice of shift or reduce should depend on the relative
  4282. -precedence of the operators `-' and OP: `*' should be shifted first,
  4283. -but not `<'.
  4284. -
  4285. -   What about input such as `1 - 2 - 5'; should this be `(1 - 2) - 5'
  4286. -or should it be `1 - (2 - 5)'?  For most operators we prefer the
  4287. -former, which is called "left association".  The latter alternative,
  4288. -"right association", is desirable for assignment operators.  The choice
  4289. -of left or right association is a matter of whether the parser chooses
  4290. -to shift or reduce when the stack contains `1 - 2' and the look-ahead
  4291. -token is `-': shifting makes right-associativity.
  4292. -
  4293. -
  4294. -File: bison.info,  Node: Using Precedence,  Next: Precedence Examples,  Prev: Why Precedence,  Up: Precedence
  4295. -
  4296. -Specifying Operator Precedence
  4297. -------------------------------
  4298. -
  4299. -   Bison allows you to specify these choices with the operator
  4300. -precedence declarations `%left' and `%right'.  Each such declaration
  4301. -contains a list of tokens, which are operators whose precedence and
  4302. -associativity is being declared.  The `%left' declaration makes all
  4303. -those operators left-associative and the `%right' declaration makes
  4304. -them right-associative.  A third alternative is `%nonassoc', which
  4305. -declares that it is a syntax error to find the same operator twice "in a
  4306. -row".
  4307. -
  4308. -   The relative precedence of different operators is controlled by the
  4309. -order in which they are declared.  The first `%left' or `%right'
  4310. -declaration in the file declares the operators whose precedence is
  4311. -lowest, the next such declaration declares the operators whose
  4312. -precedence is a little higher, and so on.
  4313. -
  4314. -
  4315. -File: bison.info,  Node: Precedence Examples,  Next: How Precedence,  Prev: Using Precedence,  Up: Precedence
  4316. -
  4317. -Precedence Examples
  4318. --------------------
  4319. -
  4320. -   In our example, we would want the following declarations:
  4321. -
  4322. -     %left '<'
  4323. -     %left '-'
  4324. -     %left '*'
  4325. -
  4326. -   In a more complete example, which supports other operators as well,
  4327. -we would declare them in groups of equal precedence.  For example,
  4328. -`'+'' is declared with `'-'':
  4329. -
  4330. -     %left '<' '>' '=' NE LE GE
  4331. -     %left '+' '-'
  4332. -     %left '*' '/'
  4333. -
  4334. -(Here `NE' and so on stand for the operators for "not equal" and so on.
  4335. -We assume that these tokens are more than one character long and
  4336. -therefore are represented by names, not character literals.)
  4337. -
  4338. -
  4339. -File: bison.info,  Node: How Precedence,  Prev: Precedence Examples,  Up: Precedence
  4340. -
  4341. -How Precedence Works
  4342. ---------------------
  4343. -
  4344. -   The first effect of the precedence declarations is to assign
  4345. -precedence levels to the terminal symbols declared.  The second effect
  4346. -is to assign precedence levels to certain rules: each rule gets its
  4347. -precedence from the last terminal symbol mentioned in the components.
  4348. -(You can also specify explicitly the precedence of a rule.  *Note
  4349. -Context-Dependent Precedence: Contextual Precedence.)
  4350. -
  4351. -   Finally, the resolution of conflicts works by comparing the
  4352. -precedence of the rule being considered with that of the look-ahead
  4353. -token.  If the token's precedence is higher, the choice is to shift.
  4354. -If the rule's precedence is higher, the choice is to reduce.  If they
  4355. -have equal precedence, the choice is made based on the associativity of
  4356. -that precedence level.  The verbose output file made by `-v' (*note
  4357. -Invoking Bison: Invocation.) says how each conflict was resolved.
  4358. -
  4359. -   Not all rules and not all tokens have precedence.  If either the
  4360. -rule or the look-ahead token has no precedence, then the default is to
  4361. -shift.
  4362. -
  4363. diff -rup --new-file baseline/fsf/bison/bison.info-4 amiga/fsf/bison/bison.info-4
  4364. --- baseline/fsf/bison/bison.info-4    Sat Feb 17 09:46:08 1996
  4365. +++ amiga/fsf/bison/bison.info-4    Wed Dec 31 17:00:00 1969
  4366. @@ -1,1276 +0,0 @@
  4367. -This is Info file bison.info, produced by Makeinfo-1.64 from the input
  4368. -file ./bison.texinfo.
  4369. -
  4370. -   This file documents the Bison parser generator.
  4371. -
  4372. -   Copyright (C) 1988, 89, 90, 91, 92, 93, 1995 Free Software
  4373. -Foundation, Inc.
  4374. -
  4375. -   Permission is granted to make and distribute verbatim copies of this
  4376. -manual provided the copyright notice and this permission notice are
  4377. -preserved on all copies.
  4378. -
  4379. -   Permission is granted to copy and distribute modified versions of
  4380. -this manual under the conditions for verbatim copying, provided also
  4381. -that the sections entitled "GNU General Public License" and "Conditions
  4382. -for Using Bison" are included exactly as in the original, and provided
  4383. -that the entire resulting derived work is distributed under the terms
  4384. -of a permission notice identical to this one.
  4385. -
  4386. -   Permission is granted to copy and distribute translations of this
  4387. -manual into another language, under the above conditions for modified
  4388. -versions, except that the sections entitled "GNU General Public
  4389. -License", "Conditions for Using Bison" and this permission notice may be
  4390. -included in translations approved by the Free Software Foundation
  4391. -instead of in the original English.
  4392. -
  4393. -
  4394. -File: bison.info,  Node: Contextual Precedence,  Next: Parser States,  Prev: Precedence,  Up: Algorithm
  4395. -
  4396. -Context-Dependent Precedence
  4397. -============================
  4398. -
  4399. -   Often the precedence of an operator depends on the context.  This
  4400. -sounds outlandish at first, but it is really very common.  For example,
  4401. -a minus sign typically has a very high precedence as a unary operator,
  4402. -and a somewhat lower precedence (lower than multiplication) as a binary
  4403. -operator.
  4404. -
  4405. -   The Bison precedence declarations, `%left', `%right' and
  4406. -`%nonassoc', can only be used once for a given token; so a token has
  4407. -only one precedence declared in this way.  For context-dependent
  4408. -precedence, you need to use an additional mechanism: the `%prec'
  4409. -modifier for rules.
  4410. -
  4411. -   The `%prec' modifier declares the precedence of a particular rule by
  4412. -specifying a terminal symbol whose precedence should be used for that
  4413. -rule.  It's not necessary for that symbol to appear otherwise in the
  4414. -rule.  The modifier's syntax is:
  4415. -
  4416. -     %prec TERMINAL-SYMBOL
  4417. -
  4418. -and it is written after the components of the rule.  Its effect is to
  4419. -assign the rule the precedence of TERMINAL-SYMBOL, overriding the
  4420. -precedence that would be deduced for it in the ordinary way.  The
  4421. -altered rule precedence then affects how conflicts involving that rule
  4422. -are resolved (*note Operator Precedence: Precedence.).
  4423. -
  4424. -   Here is how `%prec' solves the problem of unary minus.  First,
  4425. -declare a precedence for a fictitious terminal symbol named `UMINUS'.
  4426. -There are no tokens of this type, but the symbol serves to stand for its
  4427. -precedence:
  4428. -
  4429. -     ...
  4430. -     %left '+' '-'
  4431. -     %left '*'
  4432. -     %left UMINUS
  4433. -
  4434. -   Now the precedence of `UMINUS' can be used in specific rules:
  4435. -
  4436. -     exp:    ...
  4437. -             | exp '-' exp
  4438. -             ...
  4439. -             | '-' exp %prec UMINUS
  4440. -
  4441. -
  4442. -File: bison.info,  Node: Parser States,  Next: Reduce/Reduce,  Prev: Contextual Precedence,  Up: Algorithm
  4443. -
  4444. -Parser States
  4445. -=============
  4446. -
  4447. -   The function `yyparse' is implemented using a finite-state machine.
  4448. -The values pushed on the parser stack are not simply token type codes;
  4449. -they represent the entire sequence of terminal and nonterminal symbols
  4450. -at or near the top of the stack.  The current state collects all the
  4451. -information about previous input which is relevant to deciding what to
  4452. -do next.
  4453. -
  4454. -   Each time a look-ahead token is read, the current parser state
  4455. -together with the type of look-ahead token are looked up in a table.
  4456. -This table entry can say, "Shift the look-ahead token."  In this case,
  4457. -it also specifies the new parser state, which is pushed onto the top of
  4458. -the parser stack.  Or it can say, "Reduce using rule number N." This
  4459. -means that a certain number of tokens or groupings are taken off the
  4460. -top of the stack, and replaced by one grouping.  In other words, that
  4461. -number of states are popped from the stack, and one new state is pushed.
  4462. -
  4463. -   There is one other alternative: the table can say that the
  4464. -look-ahead token is erroneous in the current state.  This causes error
  4465. -processing to begin (*note Error Recovery::.).
  4466. -
  4467. -
  4468. -File: bison.info,  Node: Reduce/Reduce,  Next: Mystery Conflicts,  Prev: Parser States,  Up: Algorithm
  4469. -
  4470. -Reduce/Reduce Conflicts
  4471. -=======================
  4472. -
  4473. -   A reduce/reduce conflict occurs if there are two or more rules that
  4474. -apply to the same sequence of input.  This usually indicates a serious
  4475. -error in the grammar.
  4476. -
  4477. -   For example, here is an erroneous attempt to define a sequence of
  4478. -zero or more `word' groupings.
  4479. -
  4480. -     sequence: /* empty */
  4481. -                     { printf ("empty sequence\n"); }
  4482. -             | maybeword
  4483. -             | sequence word
  4484. -                     { printf ("added word %s\n", $2); }
  4485. -             ;
  4486. -     
  4487. -     maybeword: /* empty */
  4488. -                     { printf ("empty maybeword\n"); }
  4489. -             | word
  4490. -                     { printf ("single word %s\n", $1); }
  4491. -             ;
  4492. -
  4493. -The error is an ambiguity: there is more than one way to parse a single
  4494. -`word' into a `sequence'.  It could be reduced to a `maybeword' and
  4495. -then into a `sequence' via the second rule.  Alternatively,
  4496. -nothing-at-all could be reduced into a `sequence' via the first rule,
  4497. -and this could be combined with the `word' using the third rule for
  4498. -`sequence'.
  4499. -
  4500. -   There is also more than one way to reduce nothing-at-all into a
  4501. -`sequence'.  This can be done directly via the first rule, or
  4502. -indirectly via `maybeword' and then the second rule.
  4503. -
  4504. -   You might think that this is a distinction without a difference,
  4505. -because it does not change whether any particular input is valid or
  4506. -not.  But it does affect which actions are run.  One parsing order runs
  4507. -the second rule's action; the other runs the first rule's action and
  4508. -the third rule's action.  In this example, the output of the program
  4509. -changes.
  4510. -
  4511. -   Bison resolves a reduce/reduce conflict by choosing to use the rule
  4512. -that appears first in the grammar, but it is very risky to rely on
  4513. -this.  Every reduce/reduce conflict must be studied and usually
  4514. -eliminated.  Here is the proper way to define `sequence':
  4515. -
  4516. -     sequence: /* empty */
  4517. -                     { printf ("empty sequence\n"); }
  4518. -             | sequence word
  4519. -                     { printf ("added word %s\n", $2); }
  4520. -             ;
  4521. -
  4522. -   Here is another common error that yields a reduce/reduce conflict:
  4523. -
  4524. -     sequence: /* empty */
  4525. -             | sequence words
  4526. -             | sequence redirects
  4527. -             ;
  4528. -     
  4529. -     words:    /* empty */
  4530. -             | words word
  4531. -             ;
  4532. -     
  4533. -     redirects:/* empty */
  4534. -             | redirects redirect
  4535. -             ;
  4536. -
  4537. -The intention here is to define a sequence which can contain either
  4538. -`word' or `redirect' groupings.  The individual definitions of
  4539. -`sequence', `words' and `redirects' are error-free, but the three
  4540. -together make a subtle ambiguity: even an empty input can be parsed in
  4541. -infinitely many ways!
  4542. -
  4543. -   Consider: nothing-at-all could be a `words'.  Or it could be two
  4544. -`words' in a row, or three, or any number.  It could equally well be a
  4545. -`redirects', or two, or any number.  Or it could be a `words' followed
  4546. -by three `redirects' and another `words'.  And so on.
  4547. -
  4548. -   Here are two ways to correct these rules.  First, to make it a
  4549. -single level of sequence:
  4550. -
  4551. -     sequence: /* empty */
  4552. -             | sequence word
  4553. -             | sequence redirect
  4554. -             ;
  4555. -
  4556. -   Second, to prevent either a `words' or a `redirects' from being
  4557. -empty:
  4558. -
  4559. -     sequence: /* empty */
  4560. -             | sequence words
  4561. -             | sequence redirects
  4562. -             ;
  4563. -     
  4564. -     words:    word
  4565. -             | words word
  4566. -             ;
  4567. -     
  4568. -     redirects:redirect
  4569. -             | redirects redirect
  4570. -             ;
  4571. -
  4572. -
  4573. -File: bison.info,  Node: Mystery Conflicts,  Next: Stack Overflow,  Prev: Reduce/Reduce,  Up: Algorithm
  4574. -
  4575. -Mysterious Reduce/Reduce Conflicts
  4576. -==================================
  4577. -
  4578. -   Sometimes reduce/reduce conflicts can occur that don't look
  4579. -warranted.  Here is an example:
  4580. -
  4581. -     %token ID
  4582. -     
  4583. -     %%
  4584. -     def:    param_spec return_spec ','
  4585. -             ;
  4586. -     param_spec:
  4587. -                  type
  4588. -             |    name_list ':' type
  4589. -             ;
  4590. -     return_spec:
  4591. -                  type
  4592. -             |    name ':' type
  4593. -             ;
  4594. -     type:        ID
  4595. -             ;
  4596. -     name:        ID
  4597. -             ;
  4598. -     name_list:
  4599. -                  name
  4600. -             |    name ',' name_list
  4601. -             ;
  4602. -
  4603. -   It would seem that this grammar can be parsed with only a single
  4604. -token of look-ahead: when a `param_spec' is being read, an `ID' is a
  4605. -`name' if a comma or colon follows, or a `type' if another `ID'
  4606. -follows.  In other words, this grammar is LR(1).
  4607. -
  4608. -   However, Bison, like most parser generators, cannot actually handle
  4609. -all LR(1) grammars.  In this grammar, two contexts, that after an `ID'
  4610. -at the beginning of a `param_spec' and likewise at the beginning of a
  4611. -`return_spec', are similar enough that Bison assumes they are the same.
  4612. -They appear similar because the same set of rules would be active--the
  4613. -rule for reducing to a `name' and that for reducing to a `type'.  Bison
  4614. -is unable to determine at that stage of processing that the rules would
  4615. -require different look-ahead tokens in the two contexts, so it makes a
  4616. -single parser state for them both.  Combining the two contexts causes a
  4617. -conflict later.  In parser terminology, this occurrence means that the
  4618. -grammar is not LALR(1).
  4619. -
  4620. -   In general, it is better to fix deficiencies than to document them.
  4621. -But this particular deficiency is intrinsically hard to fix; parser
  4622. -generators that can handle LR(1) grammars are hard to write and tend to
  4623. -produce parsers that are very large.  In practice, Bison is more useful
  4624. -as it is now.
  4625. -
  4626. -   When the problem arises, you can often fix it by identifying the two
  4627. -parser states that are being confused, and adding something to make them
  4628. -look distinct.  In the above example, adding one rule to `return_spec'
  4629. -as follows makes the problem go away:
  4630. -
  4631. -     %token BOGUS
  4632. -     ...
  4633. -     %%
  4634. -     ...
  4635. -     return_spec:
  4636. -                  type
  4637. -             |    name ':' type
  4638. -             /* This rule is never used.  */
  4639. -             |    ID BOGUS
  4640. -             ;
  4641. -
  4642. -   This corrects the problem because it introduces the possibility of an
  4643. -additional active rule in the context after the `ID' at the beginning of
  4644. -`return_spec'.  This rule is not active in the corresponding context in
  4645. -a `param_spec', so the two contexts receive distinct parser states.  As
  4646. -long as the token `BOGUS' is never generated by `yylex', the added rule
  4647. -cannot alter the way actual input is parsed.
  4648. -
  4649. -   In this particular example, there is another way to solve the
  4650. -problem: rewrite the rule for `return_spec' to use `ID' directly
  4651. -instead of via `name'.  This also causes the two confusing contexts to
  4652. -have different sets of active rules, because the one for `return_spec'
  4653. -activates the altered rule for `return_spec' rather than the one for
  4654. -`name'.
  4655. -
  4656. -     param_spec:
  4657. -                  type
  4658. -             |    name_list ':' type
  4659. -             ;
  4660. -     return_spec:
  4661. -                  type
  4662. -             |    ID ':' type
  4663. -             ;
  4664. -
  4665. -
  4666. -File: bison.info,  Node: Stack Overflow,  Prev: Mystery Conflicts,  Up: Algorithm
  4667. -
  4668. -Stack Overflow, and How to Avoid It
  4669. -===================================
  4670. -
  4671. -   The Bison parser stack can overflow if too many tokens are shifted
  4672. -and not reduced.  When this happens, the parser function `yyparse'
  4673. -returns a nonzero value, pausing only to call `yyerror' to report the
  4674. -overflow.
  4675. -
  4676. -   By defining the macro `YYMAXDEPTH', you can control how deep the
  4677. -parser stack can become before a stack overflow occurs.  Define the
  4678. -macro with a value that is an integer.  This value is the maximum number
  4679. -of tokens that can be shifted (and not reduced) before overflow.  It
  4680. -must be a constant expression whose value is known at compile time.
  4681. -
  4682. -   The stack space allowed is not necessarily allocated.  If you
  4683. -specify a large value for `YYMAXDEPTH', the parser actually allocates a
  4684. -small stack at first, and then makes it bigger by stages as needed.
  4685. -This increasing allocation happens automatically and silently.
  4686. -Therefore, you do not need to make `YYMAXDEPTH' painfully small merely
  4687. -to save space for ordinary inputs that do not need much stack.
  4688. -
  4689. -   The default value of `YYMAXDEPTH', if you do not define it, is 10000.
  4690. -
  4691. -   You can control how much stack is allocated initially by defining the
  4692. -macro `YYINITDEPTH'.  This value too must be a compile-time constant
  4693. -integer.  The default is 200.
  4694. -
  4695. -
  4696. -File: bison.info,  Node: Error Recovery,  Next: Context Dependency,  Prev: Algorithm,  Up: Top
  4697. -
  4698. -Error Recovery
  4699. -**************
  4700. -
  4701. -   It is not usually acceptable to have a program terminate on a parse
  4702. -error.  For example, a compiler should recover sufficiently to parse the
  4703. -rest of the input file and check it for errors; a calculator should
  4704. -accept another expression.
  4705. -
  4706. -   In a simple interactive command parser where each input is one line,
  4707. -it may be sufficient to allow `yyparse' to return 1 on error and have
  4708. -the caller ignore the rest of the input line when that happens (and
  4709. -then call `yyparse' again).  But this is inadequate for a compiler,
  4710. -because it forgets all the syntactic context leading up to the error.
  4711. -A syntax error deep within a function in the compiler input should not
  4712. -cause the compiler to treat the following line like the beginning of a
  4713. -source file.
  4714. -
  4715. -   You can define how to recover from a syntax error by writing rules to
  4716. -recognize the special token `error'.  This is a terminal symbol that is
  4717. -always defined (you need not declare it) and reserved for error
  4718. -handling.  The Bison parser generates an `error' token whenever a
  4719. -syntax error happens; if you have provided a rule to recognize this
  4720. -token in the current context, the parse can continue.
  4721. -
  4722. -   For example:
  4723. -
  4724. -     stmnts:  /* empty string */
  4725. -             | stmnts '\n'
  4726. -             | stmnts exp '\n'
  4727. -             | stmnts error '\n'
  4728. -
  4729. -   The fourth rule in this example says that an error followed by a
  4730. -newline makes a valid addition to any `stmnts'.
  4731. -
  4732. -   What happens if a syntax error occurs in the middle of an `exp'?  The
  4733. -error recovery rule, interpreted strictly, applies to the precise
  4734. -sequence of a `stmnts', an `error' and a newline.  If an error occurs in
  4735. -the middle of an `exp', there will probably be some additional tokens
  4736. -and subexpressions on the stack after the last `stmnts', and there will
  4737. -be tokens to read before the next newline.  So the rule is not
  4738. -applicable in the ordinary way.
  4739. -
  4740. -   But Bison can force the situation to fit the rule, by discarding
  4741. -part of the semantic context and part of the input.  First it discards
  4742. -states and objects from the stack until it gets back to a state in
  4743. -which the `error' token is acceptable.  (This means that the
  4744. -subexpressions already parsed are discarded, back to the last complete
  4745. -`stmnts'.)  At this point the `error' token can be shifted.  Then, if
  4746. -the old look-ahead token is not acceptable to be shifted next, the
  4747. -parser reads tokens and discards them until it finds a token which is
  4748. -acceptable.  In this example, Bison reads and discards input until the
  4749. -next newline so that the fourth rule can apply.
  4750. -
  4751. -   The choice of error rules in the grammar is a choice of strategies
  4752. -for error recovery.  A simple and useful strategy is simply to skip the
  4753. -rest of the current input line or current statement if an error is
  4754. -detected:
  4755. -
  4756. -     stmnt: error ';'  /* on error, skip until ';' is read */
  4757. -
  4758. -   It is also useful to recover to the matching close-delimiter of an
  4759. -opening-delimiter that has already been parsed.  Otherwise the
  4760. -close-delimiter will probably appear to be unmatched, and generate
  4761. -another, spurious error message:
  4762. -
  4763. -     primary:  '(' expr ')'
  4764. -             | '(' error ')'
  4765. -             ...
  4766. -             ;
  4767. -
  4768. -   Error recovery strategies are necessarily guesses.  When they guess
  4769. -wrong, one syntax error often leads to another.  In the above example,
  4770. -the error recovery rule guesses that an error is due to bad input
  4771. -within one `stmnt'.  Suppose that instead a spurious semicolon is
  4772. -inserted in the middle of a valid `stmnt'.  After the error recovery
  4773. -rule recovers from the first error, another syntax error will be found
  4774. -straightaway, since the text following the spurious semicolon is also
  4775. -an invalid `stmnt'.
  4776. -
  4777. -   To prevent an outpouring of error messages, the parser will output
  4778. -no error message for another syntax error that happens shortly after
  4779. -the first; only after three consecutive input tokens have been
  4780. -successfully shifted will error messages resume.
  4781. -
  4782. -   Note that rules which accept the `error' token may have actions, just
  4783. -as any other rules can.
  4784. -
  4785. -   You can make error messages resume immediately by using the macro
  4786. -`yyerrok' in an action.  If you do this in the error rule's action, no
  4787. -error messages will be suppressed.  This macro requires no arguments;
  4788. -`yyerrok;' is a valid C statement.
  4789. -
  4790. -   The previous look-ahead token is reanalyzed immediately after an
  4791. -error.  If this is unacceptable, then the macro `yyclearin' may be used
  4792. -to clear this token.  Write the statement `yyclearin;' in the error
  4793. -rule's action.
  4794. -
  4795. -   For example, suppose that on a parse error, an error handling
  4796. -routine is called that advances the input stream to some point where
  4797. -parsing should once again commence.  The next symbol returned by the
  4798. -lexical scanner is probably correct.  The previous look-ahead token
  4799. -ought to be discarded with `yyclearin;'.
  4800. -
  4801. -   The macro `YYRECOVERING' stands for an expression that has the value
  4802. -1 when the parser is recovering from a syntax error, and 0 the rest of
  4803. -the time.  A value of 1 indicates that error messages are currently
  4804. -suppressed for new syntax errors.
  4805. -
  4806. -
  4807. -File: bison.info,  Node: Context Dependency,  Next: Debugging,  Prev: Error Recovery,  Up: Top
  4808. -
  4809. -Handling Context Dependencies
  4810. -*****************************
  4811. -
  4812. -   The Bison paradigm is to parse tokens first, then group them into
  4813. -larger syntactic units.  In many languages, the meaning of a token is
  4814. -affected by its context.  Although this violates the Bison paradigm,
  4815. -certain techniques (known as "kludges") may enable you to write Bison
  4816. -parsers for such languages.
  4817. -
  4818. -* Menu:
  4819. -
  4820. -* Semantic Tokens::   Token parsing can depend on the semantic context.
  4821. -* Lexical Tie-ins::   Token parsing can depend on the syntactic context.
  4822. -* Tie-in Recovery::   Lexical tie-ins have implications for how
  4823. -                        error recovery rules must be written.
  4824. -
  4825. -   (Actually, "kludge" means any technique that gets its job done but is
  4826. -neither clean nor robust.)
  4827. -
  4828. -
  4829. -File: bison.info,  Node: Semantic Tokens,  Next: Lexical Tie-ins,  Up: Context Dependency
  4830. -
  4831. -Semantic Info in Token Types
  4832. -============================
  4833. -
  4834. -   The C language has a context dependency: the way an identifier is
  4835. -used depends on what its current meaning is.  For example, consider
  4836. -this:
  4837. -
  4838. -     foo (x);
  4839. -
  4840. -   This looks like a function call statement, but if `foo' is a typedef
  4841. -name, then this is actually a declaration of `x'.  How can a Bison
  4842. -parser for C decide how to parse this input?
  4843. -
  4844. -   The method used in GNU C is to have two different token types,
  4845. -`IDENTIFIER' and `TYPENAME'.  When `yylex' finds an identifier, it
  4846. -looks up the current declaration of the identifier in order to decide
  4847. -which token type to return: `TYPENAME' if the identifier is declared as
  4848. -a typedef, `IDENTIFIER' otherwise.
  4849. -
  4850. -   The grammar rules can then express the context dependency by the
  4851. -choice of token type to recognize.  `IDENTIFIER' is accepted as an
  4852. -expression, but `TYPENAME' is not.  `TYPENAME' can start a declaration,
  4853. -but `IDENTIFIER' cannot.  In contexts where the meaning of the
  4854. -identifier is *not* significant, such as in declarations that can
  4855. -shadow a typedef name, either `TYPENAME' or `IDENTIFIER' is
  4856. -accepted--there is one rule for each of the two token types.
  4857. -
  4858. -   This technique is simple to use if the decision of which kinds of
  4859. -identifiers to allow is made at a place close to where the identifier is
  4860. -parsed.  But in C this is not always so: C allows a declaration to
  4861. -redeclare a typedef name provided an explicit type has been specified
  4862. -earlier:
  4863. -
  4864. -     typedef int foo, bar, lose;
  4865. -     static foo (bar);        /* redeclare `bar' as static variable */
  4866. -     static int foo (lose);   /* redeclare `foo' as function */
  4867. -
  4868. -   Unfortunately, the name being declared is separated from the
  4869. -declaration construct itself by a complicated syntactic structure--the
  4870. -"declarator".
  4871. -
  4872. -   As a result, the part of Bison parser for C needs to be duplicated,
  4873. -with all the nonterminal names changed: once for parsing a declaration
  4874. -in which a typedef name can be redefined, and once for parsing a
  4875. -declaration in which that can't be done.  Here is a part of the
  4876. -duplication, with actions omitted for brevity:
  4877. -
  4878. -     initdcl:
  4879. -               declarator maybeasm '='
  4880. -               init
  4881. -             | declarator maybeasm
  4882. -             ;
  4883. -     
  4884. -     notype_initdcl:
  4885. -               notype_declarator maybeasm '='
  4886. -               init
  4887. -             | notype_declarator maybeasm
  4888. -             ;
  4889. -
  4890. -Here `initdcl' can redeclare a typedef name, but `notype_initdcl'
  4891. -cannot.  The distinction between `declarator' and `notype_declarator'
  4892. -is the same sort of thing.
  4893. -
  4894. -   There is some similarity between this technique and a lexical tie-in
  4895. -(described next), in that information which alters the lexical analysis
  4896. -is changed during parsing by other parts of the program.  The
  4897. -difference is here the information is global, and is used for other
  4898. -purposes in the program.  A true lexical tie-in has a special-purpose
  4899. -flag controlled by the syntactic context.
  4900. -
  4901. -
  4902. -File: bison.info,  Node: Lexical Tie-ins,  Next: Tie-in Recovery,  Prev: Semantic Tokens,  Up: Context Dependency
  4903. -
  4904. -Lexical Tie-ins
  4905. -===============
  4906. -
  4907. -   One way to handle context-dependency is the "lexical tie-in": a flag
  4908. -which is set by Bison actions, whose purpose is to alter the way tokens
  4909. -are parsed.
  4910. -
  4911. -   For example, suppose we have a language vaguely like C, but with a
  4912. -special construct `hex (HEX-EXPR)'.  After the keyword `hex' comes an
  4913. -expression in parentheses in which all integers are hexadecimal.  In
  4914. -particular, the token `a1b' must be treated as an integer rather than
  4915. -as an identifier if it appears in that context.  Here is how you can do
  4916. -it:
  4917. -
  4918. -     %{
  4919. -     int hexflag;
  4920. -     %}
  4921. -     %%
  4922. -     ...
  4923. -     expr:   IDENTIFIER
  4924. -             | constant
  4925. -             | HEX '('
  4926. -                     { hexflag = 1; }
  4927. -               expr ')'
  4928. -                     { hexflag = 0;
  4929. -                        $$ = $4; }
  4930. -             | expr '+' expr
  4931. -                     { $$ = make_sum ($1, $3); }
  4932. -             ...
  4933. -             ;
  4934. -     
  4935. -     constant:
  4936. -               INTEGER
  4937. -             | STRING
  4938. -             ;
  4939. -
  4940. -Here we assume that `yylex' looks at the value of `hexflag'; when it is
  4941. -nonzero, all integers are parsed in hexadecimal, and tokens starting
  4942. -with letters are parsed as integers if possible.
  4943. -
  4944. -   The declaration of `hexflag' shown in the C declarations section of
  4945. -the parser file is needed to make it accessible to the actions (*note
  4946. -The C Declarations Section: C Declarations.).  You must also write the
  4947. -code in `yylex' to obey the flag.
  4948. -
  4949. -
  4950. -File: bison.info,  Node: Tie-in Recovery,  Prev: Lexical Tie-ins,  Up: Context Dependency
  4951. -
  4952. -Lexical Tie-ins and Error Recovery
  4953. -==================================
  4954. -
  4955. -   Lexical tie-ins make strict demands on any error recovery rules you
  4956. -have.  *Note Error Recovery::.
  4957. -
  4958. -   The reason for this is that the purpose of an error recovery rule is
  4959. -to abort the parsing of one construct and resume in some larger
  4960. -construct.  For example, in C-like languages, a typical error recovery
  4961. -rule is to skip tokens until the next semicolon, and then start a new
  4962. -statement, like this:
  4963. -
  4964. -     stmt:   expr ';'
  4965. -             | IF '(' expr ')' stmt { ... }
  4966. -             ...
  4967. -             error ';'
  4968. -                     { hexflag = 0; }
  4969. -             ;
  4970. -
  4971. -   If there is a syntax error in the middle of a `hex (EXPR)'
  4972. -construct, this error rule will apply, and then the action for the
  4973. -completed `hex (EXPR)' will never run.  So `hexflag' would remain set
  4974. -for the entire rest of the input, or until the next `hex' keyword,
  4975. -causing identifiers to be misinterpreted as integers.
  4976. -
  4977. -   To avoid this problem the error recovery rule itself clears
  4978. -`hexflag'.
  4979. -
  4980. -   There may also be an error recovery rule that works within
  4981. -expressions.  For example, there could be a rule which applies within
  4982. -parentheses and skips to the close-parenthesis:
  4983. -
  4984. -     expr:   ...
  4985. -             | '(' expr ')'
  4986. -                     { $$ = $2; }
  4987. -             | '(' error ')'
  4988. -             ...
  4989. -
  4990. -   If this rule acts within the `hex' construct, it is not going to
  4991. -abort that construct (since it applies to an inner level of parentheses
  4992. -within the construct).  Therefore, it should not clear the flag: the
  4993. -rest of the `hex' construct should be parsed with the flag still in
  4994. -effect.
  4995. -
  4996. -   What if there is an error recovery rule which might abort out of the
  4997. -`hex' construct or might not, depending on circumstances?  There is no
  4998. -way you can write the action to determine whether a `hex' construct is
  4999. -being aborted or not.  So if you are using a lexical tie-in, you had
  5000. -better make sure your error recovery rules are not of this kind.  Each
  5001. -rule must be such that you can be sure that it always will, or always
  5002. -won't, have to clear the flag.
  5003. -
  5004. -
  5005. -File: bison.info,  Node: Debugging,  Next: Invocation,  Prev: Context Dependency,  Up: Top
  5006. -
  5007. -Debugging Your Parser
  5008. -*********************
  5009. -
  5010. -   If a Bison grammar compiles properly but doesn't do what you want
  5011. -when it runs, the `yydebug' parser-trace feature can help you figure
  5012. -out why.
  5013. -
  5014. -   To enable compilation of trace facilities, you must define the macro
  5015. -`YYDEBUG' when you compile the parser.  You could use `-DYYDEBUG=1' as
  5016. -a compiler option or you could put `#define YYDEBUG 1' in the C
  5017. -declarations section of the grammar file (*note The C Declarations
  5018. -Section: C Declarations.).  Alternatively, use the `-t' option when you
  5019. -run Bison (*note Invoking Bison: Invocation.).  We always define
  5020. -`YYDEBUG' so that debugging is always possible.
  5021. -
  5022. -   The trace facility uses `stderr', so you must add
  5023. -`#include <stdio.h>' to the C declarations section unless it is already
  5024. -there.
  5025. -
  5026. -   Once you have compiled the program with trace facilities, the way to
  5027. -request a trace is to store a nonzero value in the variable `yydebug'.
  5028. -You can do this by making the C code do it (in `main', perhaps), or you
  5029. -can alter the value with a C debugger.
  5030. -
  5031. -   Each step taken by the parser when `yydebug' is nonzero produces a
  5032. -line or two of trace information, written on `stderr'.  The trace
  5033. -messages tell you these things:
  5034. -
  5035. -   * Each time the parser calls `yylex', what kind of token was read.
  5036. -
  5037. -   * Each time a token is shifted, the depth and complete contents of
  5038. -     the state stack (*note Parser States::.).
  5039. -
  5040. -   * Each time a rule is reduced, which rule it is, and the complete
  5041. -     contents of the state stack afterward.
  5042. -
  5043. -   To make sense of this information, it helps to refer to the listing
  5044. -file produced by the Bison `-v' option (*note Invoking Bison:
  5045. -Invocation.).  This file shows the meaning of each state in terms of
  5046. -positions in various rules, and also what each state will do with each
  5047. -possible input token.  As you read the successive trace messages, you
  5048. -can see that the parser is functioning according to its specification
  5049. -in the listing file.  Eventually you will arrive at the place where
  5050. -something undesirable happens, and you will see which parts of the
  5051. -grammar are to blame.
  5052. -
  5053. -   The parser file is a C program and you can use C debuggers on it,
  5054. -but it's not easy to interpret what it is doing.  The parser function
  5055. -is a finite-state machine interpreter, and aside from the actions it
  5056. -executes the same code over and over.  Only the values of variables
  5057. -show where in the grammar it is working.
  5058. -
  5059. -   The debugging information normally gives the token type of each token
  5060. -read, but not its semantic value.  You can optionally define a macro
  5061. -named `YYPRINT' to provide a way to print the value.  If you define
  5062. -`YYPRINT', it should take three arguments.  The parser will pass a
  5063. -standard I/O stream, the numeric code for the token type, and the token
  5064. -value (from `yylval').
  5065. -
  5066. -   Here is an example of `YYPRINT' suitable for the multi-function
  5067. -calculator (*note Declarations for `mfcalc': Mfcalc Decl.):
  5068. -
  5069. -     #define YYPRINT(file, type, value)   yyprint (file, type, value)
  5070. -     
  5071. -     static void
  5072. -     yyprint (file, type, value)
  5073. -          FILE *file;
  5074. -          int type;
  5075. -          YYSTYPE value;
  5076. -     {
  5077. -       if (type == VAR)
  5078. -         fprintf (file, " %s", value.tptr->name);
  5079. -       else if (type == NUM)
  5080. -         fprintf (file, " %d", value.val);
  5081. -     }
  5082. -
  5083. -
  5084. -File: bison.info,  Node: Invocation,  Next: Table of Symbols,  Prev: Debugging,  Up: Top
  5085. -
  5086. -Invoking Bison
  5087. -**************
  5088. -
  5089. -   The usual way to invoke Bison is as follows:
  5090. -
  5091. -     bison INFILE
  5092. -
  5093. -   Here INFILE is the grammar file name, which usually ends in `.y'.
  5094. -The parser file's name is made by replacing the `.y' with `.tab.c'.
  5095. -Thus, the `bison foo.y' filename yields `foo.tab.c', and the `bison
  5096. -hack/foo.y' filename yields `hack/foo.tab.c'.
  5097. -
  5098. -* Menu:
  5099. -
  5100. -* Bison Options::     All the options described in detail,
  5101. -            in alphabetical order by short options.
  5102. -* Option Cross Key::  Alphabetical list of long options.
  5103. -* VMS Invocation::    Bison command syntax on VMS.
  5104. -
  5105. -
  5106. -File: bison.info,  Node: Bison Options,  Next: Option Cross Key,  Up: Invocation
  5107. -
  5108. -Bison Options
  5109. -=============
  5110. -
  5111. -   Bison supports both traditional single-letter options and mnemonic
  5112. -long option names.  Long option names are indicated with `--' instead of
  5113. -`-'.  Abbreviations for option names are allowed as long as they are
  5114. -unique.  When a long option takes an argument, like `--file-prefix',
  5115. -connect the option name and the argument with `='.
  5116. -
  5117. -   Here is a list of options that can be used with Bison, alphabetized
  5118. -by short option.  It is followed by a cross key alphabetized by long
  5119. -option.
  5120. -
  5121. -`-b FILE-PREFIX'
  5122. -`--file-prefix=PREFIX'
  5123. -     Specify a prefix to use for all Bison output file names.  The
  5124. -     names are chosen as if the input file were named `PREFIX.c'.
  5125. -
  5126. -`-d'
  5127. -`--defines'
  5128. -     Write an extra output file containing macro definitions for the
  5129. -     token type names defined in the grammar and the semantic value type
  5130. -     `YYSTYPE', as well as a few `extern' variable declarations.
  5131. -
  5132. -     If the parser output file is named `NAME.c' then this file is
  5133. -     named `NAME.h'.
  5134. -
  5135. -     This output file is essential if you wish to put the definition of
  5136. -     `yylex' in a separate source file, because `yylex' needs to be
  5137. -     able to refer to token type codes and the variable `yylval'.
  5138. -     *Note Semantic Values of Tokens: Token Values.
  5139. -
  5140. -`-l'
  5141. -`--no-lines'
  5142. -     Don't put any `#line' preprocessor commands in the parser file.
  5143. -     Ordinarily Bison puts them in the parser file so that the C
  5144. -     compiler and debuggers will associate errors with your source
  5145. -     file, the grammar file.  This option causes them to associate
  5146. -     errors with the parser file, treating it as an independent source
  5147. -     file in its own right.
  5148. -
  5149. -`-n'
  5150. -`--no-parser'
  5151. -     Do not include any C code in the parser file; generate tables
  5152. -     only.  The parser file contains just `#define' directives and
  5153. -     static variable declarations.
  5154. -
  5155. -     This option also tells Bison to write the C code for the grammar
  5156. -     actions into a file named `FILENAME.act', in the form of a
  5157. -     brace-surrounded body fit for a `switch' statement.
  5158. -
  5159. -`-o OUTFILE'
  5160. -`--output-file=OUTFILE'
  5161. -     Specify the name OUTFILE for the parser file.
  5162. -
  5163. -     The other output files' names are constructed from OUTFILE as
  5164. -     described under the `-v' and `-d' options.
  5165. -
  5166. -`-p PREFIX'
  5167. -`--name-prefix=PREFIX'
  5168. -     Rename the external symbols used in the parser so that they start
  5169. -     with PREFIX instead of `yy'.  The precise list of symbols renamed
  5170. -     is `yyparse', `yylex', `yyerror', `yynerrs', `yylval', `yychar'
  5171. -     and `yydebug'.
  5172. -
  5173. -     For example, if you use `-p c', the names become `cparse', `clex',
  5174. -     and so on.
  5175. -
  5176. -     *Note Multiple Parsers in the Same Program: Multiple Parsers.
  5177. -
  5178. -`-r'
  5179. -`--raw'
  5180. -     Pretend that `%raw' was specified.  *Note Decl Summary::.
  5181. -
  5182. -`-t'
  5183. -`--debug'
  5184. -     Output a definition of the macro `YYDEBUG' into the parser file,
  5185. -     so that the debugging facilities are compiled.  *Note Debugging
  5186. -     Your Parser: Debugging.
  5187. -
  5188. -`-v'
  5189. -`--verbose'
  5190. -     Write an extra output file containing verbose descriptions of the
  5191. -     parser states and what is done for each type of look-ahead token in
  5192. -     that state.
  5193. -
  5194. -     This file also describes all the conflicts, both those resolved by
  5195. -     operator precedence and the unresolved ones.
  5196. -
  5197. -     The file's name is made by removing `.tab.c' or `.c' from the
  5198. -     parser output file name, and adding `.output' instead.
  5199. -
  5200. -     Therefore, if the input file is `foo.y', then the parser file is
  5201. -     called `foo.tab.c' by default.  As a consequence, the verbose
  5202. -     output file is called `foo.output'.
  5203. -
  5204. -`-V'
  5205. -`--version'
  5206. -     Print the version number of Bison and exit.
  5207. -
  5208. -`-h'
  5209. -`--help'
  5210. -     Print a summary of the command-line options to Bison and exit.
  5211. -
  5212. -`-y'
  5213. -`--yacc'
  5214. -`--fixed-output-files'
  5215. -     Equivalent to `-o y.tab.c'; the parser output file is called
  5216. -     `y.tab.c', and the other outputs are called `y.output' and
  5217. -     `y.tab.h'.  The purpose of this option is to imitate Yacc's output
  5218. -     file name conventions.  Thus, the following shell script can
  5219. -     substitute for Yacc:
  5220. -
  5221. -          bison -y $*
  5222. -
  5223. -
  5224. -File: bison.info,  Node: Option Cross Key,  Next: VMS Invocation,  Prev: Bison Options,  Up: Invocation
  5225. -
  5226. -Option Cross Key
  5227. -================
  5228. -
  5229. -   Here is a list of options, alphabetized by long option, to help you
  5230. -find the corresponding short option.
  5231. -
  5232. -     --debug                               -t
  5233. -     --defines                             -d
  5234. -     --file-prefix=PREFIX                  -b FILE-PREFIX
  5235. -     --fixed-output-files --yacc           -y
  5236. -     --help                                -h
  5237. -     --name-prefix=PREFIX                  -p NAME-PREFIX
  5238. -     --no-lines                            -l
  5239. -     --no-parser                           -n
  5240. -     --output-file=OUTFILE                 -o OUTFILE
  5241. -     --raw                                 -r
  5242. -     --token-table                         -k
  5243. -     --verbose                             -v
  5244. -     --version                             -V
  5245. -
  5246. -
  5247. -File: bison.info,  Node: VMS Invocation,  Prev: Option Cross Key,  Up: Invocation
  5248. -
  5249. -Invoking Bison under VMS
  5250. -========================
  5251. -
  5252. -   The command line syntax for Bison on VMS is a variant of the usual
  5253. -Bison command syntax--adapted to fit VMS conventions.
  5254. -
  5255. -   To find the VMS equivalent for any Bison option, start with the long
  5256. -option, and substitute a `/' for the leading `--', and substitute a `_'
  5257. -for each `-' in the name of the long option.  For example, the
  5258. -following invocation under VMS:
  5259. -
  5260. -     bison /debug/name_prefix=bar foo.y
  5261. -
  5262. -is equivalent to the following command under POSIX.
  5263. -
  5264. -     bison --debug --name-prefix=bar foo.y
  5265. -
  5266. -   The VMS file system does not permit filenames such as `foo.tab.c'.
  5267. -In the above example, the output file would instead be named
  5268. -`foo_tab.c'.
  5269. -
  5270. -
  5271. -File: bison.info,  Node: Table of Symbols,  Next: Glossary,  Prev: Invocation,  Up: Top
  5272. -
  5273. -Bison Symbols
  5274. -*************
  5275. -
  5276. -`error'
  5277. -     A token name reserved for error recovery.  This token may be used
  5278. -     in grammar rules so as to allow the Bison parser to recognize an
  5279. -     error in the grammar without halting the process.  In effect, a
  5280. -     sentence containing an error may be recognized as valid.  On a
  5281. -     parse error, the token `error' becomes the current look-ahead
  5282. -     token.  Actions corresponding to `error' are then executed, and
  5283. -     the look-ahead token is reset to the token that originally caused
  5284. -     the violation.  *Note Error Recovery::.
  5285. -
  5286. -`YYABORT'
  5287. -     Macro to pretend that an unrecoverable syntax error has occurred,
  5288. -     by making `yyparse' return 1 immediately.  The error reporting
  5289. -     function `yyerror' is not called.  *Note The Parser Function
  5290. -     `yyparse': Parser Function.
  5291. -
  5292. -`YYACCEPT'
  5293. -     Macro to pretend that a complete utterance of the language has been
  5294. -     read, by making `yyparse' return 0 immediately.  *Note The Parser
  5295. -     Function `yyparse': Parser Function.
  5296. -
  5297. -`YYBACKUP'
  5298. -     Macro to discard a value from the parser stack and fake a
  5299. -     look-ahead token.  *Note Special Features for Use in Actions:
  5300. -     Action Features.
  5301. -
  5302. -`YYERROR'
  5303. -     Macro to pretend that a syntax error has just been detected: call
  5304. -     `yyerror' and then perform normal error recovery if possible
  5305. -     (*note Error Recovery::.), or (if recovery is impossible) make
  5306. -     `yyparse' return 1.  *Note Error Recovery::.
  5307. -
  5308. -`YYERROR_VERBOSE'
  5309. -     Macro that you define with `#define' in the Bison declarations
  5310. -     section to request verbose, specific error message strings when
  5311. -     `yyerror' is called.
  5312. -
  5313. -`YYINITDEPTH'
  5314. -     Macro for specifying the initial size of the parser stack.  *Note
  5315. -     Stack Overflow::.
  5316. -
  5317. -`YYLEX_PARAM'
  5318. -     Macro for specifying an extra argument (or list of extra
  5319. -     arguments) for `yyparse' to pass to `yylex'.  *Note Calling
  5320. -     Conventions for Pure Parsers: Pure Calling.
  5321. -
  5322. -`YYLTYPE'
  5323. -     Macro for the data type of `yylloc'; a structure with four
  5324. -     members.  *Note Textual Positions of Tokens: Token Positions.
  5325. -
  5326. -`yyltype'
  5327. -     Default value for YYLTYPE.
  5328. -
  5329. -`YYMAXDEPTH'
  5330. -     Macro for specifying the maximum size of the parser stack.  *Note
  5331. -     Stack Overflow::.
  5332. -
  5333. -`YYPARSE_PARAM'
  5334. -     Macro for specifying the name of a parameter that `yyparse' should
  5335. -     accept.  *Note Calling Conventions for Pure Parsers: Pure Calling.
  5336. -
  5337. -`YYRECOVERING'
  5338. -     Macro whose value indicates whether the parser is recovering from a
  5339. -     syntax error.  *Note Special Features for Use in Actions: Action
  5340. -     Features.
  5341. -
  5342. -`YYSTYPE'
  5343. -     Macro for the data type of semantic values; `int' by default.
  5344. -     *Note Data Types of Semantic Values: Value Type.
  5345. -
  5346. -`yychar'
  5347. -     External integer variable that contains the integer value of the
  5348. -     current look-ahead token.  (In a pure parser, it is a local
  5349. -     variable within `yyparse'.)  Error-recovery rule actions may
  5350. -     examine this variable.  *Note Special Features for Use in Actions:
  5351. -     Action Features.
  5352. -
  5353. -`yyclearin'
  5354. -     Macro used in error-recovery rule actions.  It clears the previous
  5355. -     look-ahead token.  *Note Error Recovery::.
  5356. -
  5357. -`yydebug'
  5358. -     External integer variable set to zero by default.  If `yydebug' is
  5359. -     given a nonzero value, the parser will output information on input
  5360. -     symbols and parser action.  *Note Debugging Your Parser: Debugging.
  5361. -
  5362. -`yyerrok'
  5363. -     Macro to cause parser to recover immediately to its normal mode
  5364. -     after a parse error.  *Note Error Recovery::.
  5365. -
  5366. -`yyerror'
  5367. -     User-supplied function to be called by `yyparse' on error.  The
  5368. -     function receives one argument, a pointer to a character string
  5369. -     containing an error message.  *Note The Error Reporting Function
  5370. -     `yyerror': Error Reporting.
  5371. -
  5372. -`yylex'
  5373. -     User-supplied lexical analyzer function, called with no arguments
  5374. -     to get the next token.  *Note The Lexical Analyzer Function
  5375. -     `yylex': Lexical.
  5376. -
  5377. -`yylval'
  5378. -     External variable in which `yylex' should place the semantic value
  5379. -     associated with a token.  (In a pure parser, it is a local
  5380. -     variable within `yyparse', and its address is passed to `yylex'.)
  5381. -     *Note Semantic Values of Tokens: Token Values.
  5382. -
  5383. -`yylloc'
  5384. -     External variable in which `yylex' should place the line and
  5385. -     column numbers associated with a token.  (In a pure parser, it is a
  5386. -     local variable within `yyparse', and its address is passed to
  5387. -     `yylex'.)  You can ignore this variable if you don't use the `@'
  5388. -     feature in the grammar actions.  *Note Textual Positions of
  5389. -     Tokens: Token Positions.
  5390. -
  5391. -`yynerrs'
  5392. -     Global variable which Bison increments each time there is a parse
  5393. -     error.  (In a pure parser, it is a local variable within
  5394. -     `yyparse'.)  *Note The Error Reporting Function `yyerror': Error
  5395. -     Reporting.
  5396. -
  5397. -`yyparse'
  5398. -     The parser function produced by Bison; call this function to start
  5399. -     parsing.  *Note The Parser Function `yyparse': Parser Function.
  5400. -
  5401. -`%left'
  5402. -     Bison declaration to assign left associativity to token(s).  *Note
  5403. -     Operator Precedence: Precedence Decl.
  5404. -
  5405. -`%no_lines'
  5406. -     Bison declaration to avoid generating `#line' directives in the
  5407. -     parser file.  *Note Decl Summary::.
  5408. -
  5409. -`%nonassoc'
  5410. -     Bison declaration to assign nonassociativity to token(s).  *Note
  5411. -     Operator Precedence: Precedence Decl.
  5412. -
  5413. -`%prec'
  5414. -     Bison declaration to assign a precedence to a specific rule.
  5415. -     *Note Context-Dependent Precedence: Contextual Precedence.
  5416. -
  5417. -`%pure_parser'
  5418. -     Bison declaration to request a pure (reentrant) parser.  *Note A
  5419. -     Pure (Reentrant) Parser: Pure Decl.
  5420. -
  5421. -`%raw'
  5422. -     Bison declaration to use Bison internal token code numbers in token
  5423. -     tables instead of the usual Yacc-compatible token code numbers.
  5424. -     *Note Decl Summary::.
  5425. -
  5426. -`%right'
  5427. -     Bison declaration to assign right associativity to token(s).
  5428. -     *Note Operator Precedence: Precedence Decl.
  5429. -
  5430. -`%start'
  5431. -     Bison declaration to specify the start symbol.  *Note The
  5432. -     Start-Symbol: Start Decl.
  5433. -
  5434. -`%token'
  5435. -     Bison declaration to declare token(s) without specifying
  5436. -     precedence.  *Note Token Type Names: Token Decl.
  5437. -
  5438. -`%token_table'
  5439. -     Bison declaration to include a token name table in the parser file.
  5440. -     *Note Decl Summary::.
  5441. -
  5442. -`%type'
  5443. -     Bison declaration to declare nonterminals.  *Note Nonterminal
  5444. -     Symbols: Type Decl.
  5445. -
  5446. -`%union'
  5447. -     Bison declaration to specify several possible data types for
  5448. -     semantic values.  *Note The Collection of Value Types: Union Decl.
  5449. -
  5450. -   These are the punctuation and delimiters used in Bison input:
  5451. -
  5452. -`%%'
  5453. -     Delimiter used to separate the grammar rule section from the Bison
  5454. -     declarations section or the additional C code section.  *Note The
  5455. -     Overall Layout of a Bison Grammar: Grammar Layout.
  5456. -
  5457. -`%{ %}'
  5458. -     All code listed between `%{' and `%}' is copied directly to the
  5459. -     output file uninterpreted.  Such code forms the "C declarations"
  5460. -     section of the input file.  *Note Outline of a Bison Grammar:
  5461. -     Grammar Outline.
  5462. -
  5463. -`/*...*/'
  5464. -     Comment delimiters, as in C.
  5465. -
  5466. -`:'
  5467. -     Separates a rule's result from its components.  *Note Syntax of
  5468. -     Grammar Rules: Rules.
  5469. -
  5470. -`;'
  5471. -     Terminates a rule.  *Note Syntax of Grammar Rules: Rules.
  5472. -
  5473. -`|'
  5474. -     Separates alternate rules for the same result nonterminal.  *Note
  5475. -     Syntax of Grammar Rules: Rules.
  5476. -
  5477. -
  5478. -File: bison.info,  Node: Glossary,  Next: Index,  Prev: Table of Symbols,  Up: Top
  5479. -
  5480. -Glossary
  5481. -********
  5482. -
  5483. -Backus-Naur Form (BNF)
  5484. -     Formal method of specifying context-free grammars.  BNF was first
  5485. -     used in the `ALGOL-60' report, 1963.  *Note Languages and
  5486. -     Context-Free Grammars: Language and Grammar.
  5487. -
  5488. -Context-free grammars
  5489. -     Grammars specified as rules that can be applied regardless of
  5490. -     context.  Thus, if there is a rule which says that an integer can
  5491. -     be used as an expression, integers are allowed *anywhere* an
  5492. -     expression is permitted.  *Note Languages and Context-Free
  5493. -     Grammars: Language and Grammar.
  5494. -
  5495. -Dynamic allocation
  5496. -     Allocation of memory that occurs during execution, rather than at
  5497. -     compile time or on entry to a function.
  5498. -
  5499. -Empty string
  5500. -     Analogous to the empty set in set theory, the empty string is a
  5501. -     character string of length zero.
  5502. -
  5503. -Finite-state stack machine
  5504. -     A "machine" that has discrete states in which it is said to exist
  5505. -     at each instant in time.  As input to the machine is processed, the
  5506. -     machine moves from state to state as specified by the logic of the
  5507. -     machine.  In the case of the parser, the input is the language
  5508. -     being parsed, and the states correspond to various stages in the
  5509. -     grammar rules.  *Note The Bison Parser Algorithm: Algorithm.
  5510. -
  5511. -Grouping
  5512. -     A language construct that is (in general) grammatically divisible;
  5513. -     for example, `expression' or `declaration' in C.  *Note Languages
  5514. -     and Context-Free Grammars: Language and Grammar.
  5515. -
  5516. -Infix operator
  5517. -     An arithmetic operator that is placed between the operands on
  5518. -     which it performs some operation.
  5519. -
  5520. -Input stream
  5521. -     A continuous flow of data between devices or programs.
  5522. -
  5523. -Language construct
  5524. -     One of the typical usage schemas of the language.  For example,
  5525. -     one of the constructs of the C language is the `if' statement.
  5526. -     *Note Languages and Context-Free Grammars: Language and Grammar.
  5527. -
  5528. -Left associativity
  5529. -     Operators having left associativity are analyzed from left to
  5530. -     right: `a+b+c' first computes `a+b' and then combines with `c'.
  5531. -     *Note Operator Precedence: Precedence.
  5532. -
  5533. -Left recursion
  5534. -     A rule whose result symbol is also its first component symbol; for
  5535. -     example, `expseq1 : expseq1 ',' exp;'.  *Note Recursive Rules:
  5536. -     Recursion.
  5537. -
  5538. -Left-to-right parsing
  5539. -     Parsing a sentence of a language by analyzing it token by token
  5540. -     from left to right.  *Note The Bison Parser Algorithm: Algorithm.
  5541. -
  5542. -Lexical analyzer (scanner)
  5543. -     A function that reads an input stream and returns tokens one by
  5544. -     one.  *Note The Lexical Analyzer Function `yylex': Lexical.
  5545. -
  5546. -Lexical tie-in
  5547. -     A flag, set by actions in the grammar rules, which alters the way
  5548. -     tokens are parsed.  *Note Lexical Tie-ins::.
  5549. -
  5550. -Literal string token
  5551. -     A token which constists of two or more fixed characters.  *Note
  5552. -     Symbols::.
  5553. -
  5554. -Look-ahead token
  5555. -     A token already read but not yet shifted.  *Note Look-Ahead
  5556. -     Tokens: Look-Ahead.
  5557. -
  5558. -LALR(1)
  5559. -     The class of context-free grammars that Bison (like most other
  5560. -     parser generators) can handle; a subset of LR(1).  *Note
  5561. -     Mysterious Reduce/Reduce Conflicts: Mystery Conflicts.
  5562. -
  5563. -LR(1)
  5564. -     The class of context-free grammars in which at most one token of
  5565. -     look-ahead is needed to disambiguate the parsing of any piece of
  5566. -     input.
  5567. -
  5568. -Nonterminal symbol
  5569. -     A grammar symbol standing for a grammatical construct that can be
  5570. -     expressed through rules in terms of smaller constructs; in other
  5571. -     words, a construct that is not a token.  *Note Symbols::.
  5572. -
  5573. -Parse error
  5574. -     An error encountered during parsing of an input stream due to
  5575. -     invalid syntax.  *Note Error Recovery::.
  5576. -
  5577. -Parser
  5578. -     A function that recognizes valid sentences of a language by
  5579. -     analyzing the syntax structure of a set of tokens passed to it
  5580. -     from a lexical analyzer.
  5581. -
  5582. -Postfix operator
  5583. -     An arithmetic operator that is placed after the operands upon
  5584. -     which it performs some operation.
  5585. -
  5586. -Reduction
  5587. -     Replacing a string of nonterminals and/or terminals with a single
  5588. -     nonterminal, according to a grammar rule.  *Note The Bison Parser
  5589. -     Algorithm: Algorithm.
  5590. -
  5591. -Reentrant
  5592. -     A reentrant subprogram is a subprogram which can be in invoked any
  5593. -     number of times in parallel, without interference between the
  5594. -     various invocations.  *Note A Pure (Reentrant) Parser: Pure Decl.
  5595. -
  5596. -Reverse polish notation
  5597. -     A language in which all operators are postfix operators.
  5598. -
  5599. -Right recursion
  5600. -     A rule whose result symbol is also its last component symbol; for
  5601. -     example, `expseq1: exp ',' expseq1;'.  *Note Recursive Rules:
  5602. -     Recursion.
  5603. -
  5604. -Semantics
  5605. -     In computer languages, the semantics are specified by the actions
  5606. -     taken for each instance of the language, i.e., the meaning of each
  5607. -     statement.  *Note Defining Language Semantics: Semantics.
  5608. -
  5609. -Shift
  5610. -     A parser is said to shift when it makes the choice of analyzing
  5611. -     further input from the stream rather than reducing immediately some
  5612. -     already-recognized rule.  *Note The Bison Parser Algorithm:
  5613. -     Algorithm.
  5614. -
  5615. -Single-character literal
  5616. -     A single character that is recognized and interpreted as is.
  5617. -     *Note From Formal Rules to Bison Input: Grammar in Bison.
  5618. -
  5619. -Start symbol
  5620. -     The nonterminal symbol that stands for a complete valid utterance
  5621. -     in the language being parsed.  The start symbol is usually listed
  5622. -     as the first nonterminal symbol in a language specification.
  5623. -     *Note The Start-Symbol: Start Decl.
  5624. -
  5625. -Symbol table
  5626. -     A data structure where symbol names and associated data are stored
  5627. -     during parsing to allow for recognition and use of existing
  5628. -     information in repeated uses of a symbol.  *Note Multi-function
  5629. -     Calc::.
  5630. -
  5631. -Token
  5632. -     A basic, grammatically indivisible unit of a language.  The symbol
  5633. -     that describes a token in the grammar is a terminal symbol.  The
  5634. -     input of the Bison parser is a stream of tokens which comes from
  5635. -     the lexical analyzer.  *Note Symbols::.
  5636. -
  5637. -Terminal symbol
  5638. -     A grammar symbol that has no rules in the grammar and therefore is
  5639. -     grammatically indivisible.  The piece of text it represents is a
  5640. -     token.  *Note Languages and Context-Free Grammars: Language and
  5641. -     Grammar.
  5642. -
  5643. diff -rup --new-file baseline/fsf/bison/bison.info-5 amiga/fsf/bison/bison.info-5
  5644. --- baseline/fsf/bison/bison.info-5    Sat Feb 17 09:46:08 1996
  5645. +++ amiga/fsf/bison/bison.info-5    Wed Dec 31 17:00:00 1969
  5646. @@ -1,234 +0,0 @@
  5647. -This is Info file bison.info, produced by Makeinfo-1.64 from the input
  5648. -file ./bison.texinfo.
  5649. -
  5650. -   This file documents the Bison parser generator.
  5651. -
  5652. -   Copyright (C) 1988, 89, 90, 91, 92, 93, 1995 Free Software
  5653. -Foundation, Inc.
  5654. -
  5655. -   Permission is granted to make and distribute verbatim copies of this
  5656. -manual provided the copyright notice and this permission notice are
  5657. -preserved on all copies.
  5658. -
  5659. -   Permission is granted to copy and distribute modified versions of
  5660. -this manual under the conditions for verbatim copying, provided also
  5661. -that the sections entitled "GNU General Public License" and "Conditions
  5662. -for Using Bison" are included exactly as in the original, and provided
  5663. -that the entire resulting derived work is distributed under the terms
  5664. -of a permission notice identical to this one.
  5665. -
  5666. -   Permission is granted to copy and distribute translations of this
  5667. -manual into another language, under the above conditions for modified
  5668. -versions, except that the sections entitled "GNU General Public
  5669. -License", "Conditions for Using Bison" and this permission notice may be
  5670. -included in translations approved by the Free Software Foundation
  5671. -instead of in the original English.
  5672. -
  5673. -
  5674. -File: bison.info,  Node: Index,  Prev: Glossary,  Up: Top
  5675. -
  5676. -Index
  5677. -*****
  5678. -
  5679. -* Menu:
  5680. -
  5681. -* $$:                                   Actions.
  5682. -* $N:                                   Actions.
  5683. -* %expect:                              Expect Decl.
  5684. -* %left:                                Using Precedence.
  5685. -* %nonassoc:                            Using Precedence.
  5686. -* %prec:                                Contextual Precedence.
  5687. -* %pure_parser:                         Pure Decl.
  5688. -* %right:                               Using Precedence.
  5689. -* %start:                               Start Decl.
  5690. -* %token:                               Token Decl.
  5691. -* %type:                                Type Decl.
  5692. -* %union:                               Union Decl.
  5693. -* @N:                                   Action Features.
  5694. -* calc:                                 Infix Calc.
  5695. -* else, dangling:                       Shift/Reduce.
  5696. -* mfcalc:                               Multi-function Calc.
  5697. -* rpcalc:                               RPN Calc.
  5698. -* action:                               Actions.
  5699. -* action data types:                    Action Types.
  5700. -* action features summary:              Action Features.
  5701. -* actions in mid-rule:                  Mid-Rule Actions.
  5702. -* actions, semantic:                    Semantic Actions.
  5703. -* additional C code section:            C Code.
  5704. -* algorithm of parser:                  Algorithm.
  5705. -* associativity:                        Why Precedence.
  5706. -* Backus-Naur form:                     Language and Grammar.
  5707. -* Bison declaration summary:            Decl Summary.
  5708. -* Bison declarations:                   Declarations.
  5709. -* Bison declarations (introduction):    Bison Declarations.
  5710. -* Bison grammar:                        Grammar in Bison.
  5711. -* Bison invocation:                     Invocation.
  5712. -* Bison parser:                         Bison Parser.
  5713. -* Bison parser algorithm:               Algorithm.
  5714. -* Bison symbols, table of:              Table of Symbols.
  5715. -* Bison utility:                        Bison Parser.
  5716. -* BNF:                                  Language and Grammar.
  5717. -* C code, section for additional:       C Code.
  5718. -* C declarations section:               C Declarations.
  5719. -* C-language interface:                 Interface.
  5720. -* calculator, infix notation:           Infix Calc.
  5721. -* calculator, multi-function:           Multi-function Calc.
  5722. -* calculator, simple:                   RPN Calc.
  5723. -* character token:                      Symbols.
  5724. -* compiling the parser:                 Rpcalc Compile.
  5725. -* conflicts:                            Shift/Reduce.
  5726. -* conflicts, reduce/reduce:             Reduce/Reduce.
  5727. -* conflicts, suppressing warnings of:   Expect Decl.
  5728. -* context-dependent precedence:         Contextual Precedence.
  5729. -* context-free grammar:                 Language and Grammar.
  5730. -* controlling function:                 Rpcalc Main.
  5731. -* dangling else:                        Shift/Reduce.
  5732. -* data types in actions:                Action Types.
  5733. -* data types of semantic values:        Value Type.
  5734. -* debugging:                            Debugging.
  5735. -* declaration summary:                  Decl Summary.
  5736. -* declarations, Bison:                  Declarations.
  5737. -* declarations, Bison (introduction):   Bison Declarations.
  5738. -* declarations, C:                      C Declarations.
  5739. -* declaring literal string tokens:      Token Decl.
  5740. -* declaring operator precedence:        Precedence Decl.
  5741. -* declaring the start symbol:           Start Decl.
  5742. -* declaring token type names:           Token Decl.
  5743. -* declaring value types:                Union Decl.
  5744. -* declaring value types, nonterminals:  Type Decl.
  5745. -* default action:                       Actions.
  5746. -* default data type:                    Value Type.
  5747. -* default stack limit:                  Stack Overflow.
  5748. -* default start symbol:                 Start Decl.
  5749. -* defining language semantics:          Semantics.
  5750. -* error:                                Error Recovery.
  5751. -* error recovery:                       Error Recovery.
  5752. -* error recovery, simple:               Simple Error Recovery.
  5753. -* error reporting function:             Error Reporting.
  5754. -* error reporting routine:              Rpcalc Error.
  5755. -* examples, simple:                     Examples.
  5756. -* exercises:                            Exercises.
  5757. -* file format:                          Grammar Layout.
  5758. -* finite-state machine:                 Parser States.
  5759. -* formal grammar:                       Grammar in Bison.
  5760. -* format of grammar file:               Grammar Layout.
  5761. -* glossary:                             Glossary.
  5762. -* grammar file:                         Grammar Layout.
  5763. -* grammar rule syntax:                  Rules.
  5764. -* grammar rules section:                Grammar Rules.
  5765. -* grammar, Bison:                       Grammar in Bison.
  5766. -* grammar, context-free:                Language and Grammar.
  5767. -* grouping, syntactic:                  Language and Grammar.
  5768. -* infix notation calculator:            Infix Calc.
  5769. -* interface:                            Interface.
  5770. -* introduction:                         Introduction.
  5771. -* invoking Bison:                       Invocation.
  5772. -* invoking Bison under VMS:             VMS Invocation.
  5773. -* LALR(1):                              Mystery Conflicts.
  5774. -* language semantics, defining:         Semantics.
  5775. -* layout of Bison grammar:              Grammar Layout.
  5776. -* left recursion:                       Recursion.
  5777. -* lexical analyzer:                     Lexical.
  5778. -* lexical analyzer, purpose:            Bison Parser.
  5779. -* lexical analyzer, writing:            Rpcalc Lexer.
  5780. -* lexical tie-in:                       Lexical Tie-ins.
  5781. -* literal string token:                 Symbols.
  5782. -* literal token:                        Symbols.
  5783. -* look-ahead token:                     Look-Ahead.
  5784. -* LR(1):                                Mystery Conflicts.
  5785. -* main function in simple example:      Rpcalc Main.
  5786. -* mid-rule actions:                     Mid-Rule Actions.
  5787. -* multi-character literal:              Symbols.
  5788. -* multi-function calculator:            Multi-function Calc.
  5789. -* mutual recursion:                     Recursion.
  5790. -* nonterminal symbol:                   Symbols.
  5791. -* operator precedence:                  Precedence.
  5792. -* operator precedence, declaring:       Precedence Decl.
  5793. -* options for invoking Bison:           Invocation.
  5794. -* overflow of parser stack:             Stack Overflow.
  5795. -* parse error:                          Error Reporting.
  5796. -* parser:                               Bison Parser.
  5797. -* parser stack:                         Algorithm.
  5798. -* parser stack overflow:                Stack Overflow.
  5799. -* parser state:                         Parser States.
  5800. -* polish notation calculator:           RPN Calc.
  5801. -* precedence declarations:              Precedence Decl.
  5802. -* precedence of operators:              Precedence.
  5803. -* precedence, context-dependent:        Contextual Precedence.
  5804. -* precedence, unary operator:           Contextual Precedence.
  5805. -* preventing warnings about conflicts:  Expect Decl.
  5806. -* pure parser:                          Pure Decl.
  5807. -* recovery from errors:                 Error Recovery.
  5808. -* recursive rule:                       Recursion.
  5809. -* reduce/reduce conflict:               Reduce/Reduce.
  5810. -* reduction:                            Algorithm.
  5811. -* reentrant parser:                     Pure Decl.
  5812. -* reverse polish notation:              RPN Calc.
  5813. -* right recursion:                      Recursion.
  5814. -* rule syntax:                          Rules.
  5815. -* rules section for grammar:            Grammar Rules.
  5816. -* running Bison (introduction):         Rpcalc Gen.
  5817. -* semantic actions:                     Semantic Actions.
  5818. -* semantic value:                       Semantic Values.
  5819. -* semantic value type:                  Value Type.
  5820. -* shift/reduce conflicts:               Shift/Reduce.
  5821. -* shifting:                             Algorithm.
  5822. -* simple examples:                      Examples.
  5823. -* single-character literal:             Symbols.
  5824. -* stack overflow:                       Stack Overflow.
  5825. -* stack, parser:                        Algorithm.
  5826. -* stages in using Bison:                Stages.
  5827. -* start symbol:                         Language and Grammar.
  5828. -* start symbol, declaring:              Start Decl.
  5829. -* state (of parser):                    Parser States.
  5830. -* string token:                         Symbols.
  5831. -* summary, action features:             Action Features.
  5832. -* summary, Bison declaration:           Decl Summary.
  5833. -* suppressing conflict warnings:        Expect Decl.
  5834. -* symbol:                               Symbols.
  5835. -* symbol table example:                 Mfcalc Symtab.
  5836. -* symbols (abstract):                   Language and Grammar.
  5837. -* symbols in Bison, table of:           Table of Symbols.
  5838. -* syntactic grouping:                   Language and Grammar.
  5839. -* syntax error:                         Error Reporting.
  5840. -* syntax of grammar rules:              Rules.
  5841. -* terminal symbol:                      Symbols.
  5842. -* token:                                Language and Grammar.
  5843. -* token type:                           Symbols.
  5844. -* token type names, declaring:          Token Decl.
  5845. -* tracing the parser:                   Debugging.
  5846. -* unary operator precedence:            Contextual Precedence.
  5847. -* using Bison:                          Stages.
  5848. -* value type, semantic:                 Value Type.
  5849. -* value types, declaring:               Union Decl.
  5850. -* value types, nonterminals, declaring: Type Decl.
  5851. -* value, semantic:                      Semantic Values.
  5852. -* VMS:                                  VMS Invocation.
  5853. -* warnings, preventing:                 Expect Decl.
  5854. -* writing a lexical analyzer:           Rpcalc Lexer.
  5855. -* YYABORT:                              Parser Function.
  5856. -* YYACCEPT:                             Parser Function.
  5857. -* YYBACKUP:                             Action Features.
  5858. -* yychar:                               Look-Ahead.
  5859. -* yyclearin:                            Error Recovery.
  5860. -* YYDEBUG:                              Debugging.
  5861. -* YYEMPTY:                              Action Features.
  5862. -* yyerrok:                              Error Recovery.
  5863. -* YYERROR:                              Action Features.
  5864. -* yyerror:                              Error Reporting.
  5865. -* YYERROR_VERBOSE:                      Error Reporting.
  5866. -* YYINITDEPTH:                          Stack Overflow.
  5867. -* yylex:                                Lexical.
  5868. -* YYLEX_PARAM:                          Pure Calling.
  5869. -* yylloc:                               Token Positions.
  5870. -* YYLTYPE:                              Token Positions.
  5871. -* yylval:                               Token Values.
  5872. -* YYMAXDEPTH:                           Stack Overflow.
  5873. -* yynerrs:                              Error Reporting.
  5874. -* yyparse:                              Parser Function.
  5875. -* YYPARSE_PARAM:                        Pure Calling.
  5876. -* YYPRINT:                              Debugging.
  5877. -* YYRECOVERING:                         Error Recovery.
  5878. -* |:                                    Rules.
  5879. -
  5880. -
  5881. diff -rup --new-file baseline/fsf/bison/configure amiga/fsf/bison/configure
  5882. --- baseline/fsf/bison/configure    Thu Dec 28 13:08:14 1995
  5883. +++ amiga/fsf/bison/configure    Mon Sep 30 22:37:48 1996
  5884. @@ -1,8 +1,8 @@
  5885.  #! /bin/sh
  5886.  
  5887.  # Guess values for system-dependent variables and create Makefiles.
  5888. -# Generated automatically using autoconf version 2.7 
  5889. -# Copyright (C) 1992, 1993, 1994 Free Software Foundation, Inc.
  5890. +# Generated automatically using autoconf version 2.10 
  5891. +# Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.
  5892.  #
  5893.  # This configure script is free software; the Free Software Foundation
  5894.  # gives unlimited permission to copy, distribute and modify it.
  5895. @@ -44,6 +44,9 @@ libdir='${exec_prefix}/lib'
  5896.  includedir='${prefix}/include'
  5897.  oldincludedir='/usr/include'
  5898.  infodir='${prefix}/info'
  5899. +guidedir='${prefix}/guide'
  5900. +psdir='${prefix}/ps'
  5901. +dvidir='${prefix}/dvi'
  5902.  mandir='${prefix}/man'
  5903.  
  5904.  # Initialize some other variables.
  5905. @@ -158,6 +161,9 @@ Directory and file names:
  5906.    --includedir=DIR        C header files in DIR [PREFIX/include]
  5907.    --oldincludedir=DIR     C header files for non-gcc in DIR [/usr/include]
  5908.    --infodir=DIR           info documentation in DIR [PREFIX/info]
  5909. +  --guidedir=DIR          Amigaguide documentation in DIR [PREFIX/guide]
  5910. +  --psdir=DIR             postscript documentation in DIR [PREFIX/ps]
  5911. +  --dvidir=DIR            TeX dvi documentation in DIR [PREFIX/dvi]
  5912.    --mandir=DIR            man documentation in DIR [PREFIX/man]
  5913.    --srcdir=DIR            find the sources in DIR [configure dir or ..]
  5914.    --program-prefix=PREFIX prepend PREFIX to installed program names
  5915. @@ -200,6 +206,18 @@ EOF
  5916.    -infodir=* | --infodir=* | --infodi=* | --infod=* | --info=* | --inf=*)
  5917.      infodir="$ac_optarg" ;;
  5918.  
  5919. + -guidedir | --guidedir | --guidedi | --guided | --guide | --gui)
  5920. +   ac_prev=guidedir ;;
  5921. + -guidedir=* | --guidedir=* | --guidedi=* | --guided=* | --guide=* |--gui=*)+    guidedir="$ac_optarg" ;;
  5922. +
  5923. + -psdir | --psdir | --psdi | --psd | --ps)
  5924. +   ac_prev=psdir ;;
  5925. + -psdir=* | --psdir=* | --psdi=* | --psd=* | --ps=*)+    psdir="$ac_optarg" ;;
  5926. +
  5927. + -dvidir | --dvidir | --dvidi | --dvid | --dvi | --dv)
  5928. +   ac_prev=dvidir ;;
  5929. + -dvidir=* | --dvidir=* | --dvidi=* | --dvid=* | --dvi=* |--dv=*)+    dvidir="$ac_optarg" ;;
  5930. +
  5931.    -libdir | --libdir | --libdi | --libd)
  5932.      ac_prev=libdir ;;
  5933.    -libdir=* | --libdir=* | --libdi=* | --libd=*)
  5934. @@ -330,7 +348,7 @@ EOF
  5935.      verbose=yes ;;
  5936.  
  5937.    -version | --version | --versio | --versi | --vers)
  5938. -    echo "configure generated by autoconf version 2.7"
  5939. +    echo "configure generated by autoconf version 2.10"
  5940.      exit 0 ;;
  5941.  
  5942.    -with-* | --with-*)
  5943. @@ -495,12 +513,9 @@ fi
  5944.  
  5945.  ac_ext=c
  5946.  # CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options.
  5947. -ac_cpp='echo $CPP $CPPFLAGS 1>&5;
  5948. -$CPP $CPPFLAGS'
  5949. -ac_compile='echo ${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5;
  5950. -${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5 2>&5'
  5951. -ac_link='echo ${CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5;
  5952. -${CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5 2>&5'
  5953. +ac_cpp='$CPP $CPPFLAGS'
  5954. +ac_compile='${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5'
  5955. +ac_link='${CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5'
  5956.  
  5957.  if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
  5958.    # Stardent Vistra SVR4 grep lacks -e, says ghazi@caip.rutgers.edu.
  5959. @@ -534,7 +549,6 @@ else
  5960.      fi
  5961.    done
  5962.    IFS="$ac_save_ifs"
  5963. -  test -z "$ac_cv_prog_CC" && ac_cv_prog_CC="cc"
  5964.  fi
  5965.  fi
  5966.  CC="$ac_cv_prog_CC"
  5967. @@ -544,6 +558,55 @@ else
  5968.    echo "$ac_t""no" 1>&6
  5969.  fi
  5970.  
  5971. +if test -z "$CC"; then
  5972. +  # Extract the first word of "cc", so it can be a program name with args.
  5973. +set dummy cc; ac_word=$2
  5974. +echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
  5975. +if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then
  5976. +  echo $ac_n "(cached) $ac_c" 1>&6
  5977. +else
  5978. +  if test -n "$CC"; then
  5979. +  ac_cv_prog_CC="$CC" # Let the user override the test.
  5980. +else
  5981. +  IFS="${IFS=     }"; ac_save_ifs="$IFS"; IFS="${IFS}:"
  5982. +  ac_prog_rejected=no
  5983. +  for ac_dir in $PATH; do
  5984. +    test -z "$ac_dir" && ac_dir=.
  5985. +    if test -f $ac_dir/$ac_word; then
  5986. +      if test "$ac_dir/$ac_word" = "/usr/ucb/cc"; then
  5987. +        ac_prog_rejected=yes
  5988. +    continue
  5989. +      fi
  5990. +      ac_cv_prog_CC="cc"
  5991. +      break
  5992. +    fi
  5993. +  done
  5994. +  IFS="$ac_save_ifs"
  5995. +if test $ac_prog_rejected = yes; then
  5996. +  # We found a bogon in the path, so make sure we never use it.
  5997. +  set dummy $ac_cv_prog_CC
  5998. +  shift
  5999. +  if test $# -gt 0; then
  6000. +    # We chose a different compiler from the bogus one.
  6001. +    # However, it has the same basename, so the bogon will be chosen
  6002. +    # first if we set CC to just the basename; use the full file name.
  6003. +    shift
  6004. +    set dummy "$ac_dir/$ac_word" "$@"
  6005. +    shift
  6006. +    ac_cv_prog_CC="$@"
  6007. +  fi
  6008. +fi
  6009. +fi
  6010. +fi
  6011. +CC="$ac_cv_prog_CC"
  6012. +if test -n "$CC"; then
  6013. +  echo "$ac_t""$CC" 1>&6
  6014. +else
  6015. +  echo "$ac_t""no" 1>&6
  6016. +fi
  6017. +
  6018. +  test -z "$CC" && { echo "configure: error: no acceptable cc found in \$PATH" 1>&2; exit 1; }
  6019. +fi
  6020.  
  6021.  echo $ac_n "checking whether we are using GNU C""... $ac_c" 1>&6
  6022.  if eval "test \"`echo '$''{'ac_cv_prog_gcc'+set}'`\" = set"; then
  6023. @@ -554,7 +617,7 @@ else
  6024.    yes;
  6025.  #endif
  6026.  EOF
  6027. -if ${CC-cc} -E conftest.c 2>&5 | egrep yes >/dev/null 2>&1; then
  6028. +if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:621: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
  6029.    ac_cv_prog_gcc=yes
  6030.  else
  6031.    ac_cv_prog_gcc=no
  6032. @@ -581,9 +644,9 @@ fi
  6033.  
  6034.  echo "$ac_t""$ac_cv_prog_gcc_g" 1>&6
  6035.      if test $ac_cv_prog_gcc_g = yes; then
  6036. -      CFLAGS="-g -O"
  6037. +      CFLAGS="-g -O2"
  6038.      else
  6039. -      CFLAGS="-O"
  6040. +      CFLAGS="-O2"
  6041.      fi
  6042.    fi
  6043.  else
  6044. @@ -617,6 +680,7 @@ ac_configure=$ac_aux_dir/configure # Thi
  6045.  # SunOS /usr/etc/install
  6046.  # IRIX /sbin/install
  6047.  # AIX /bin/install
  6048. +# AmigaOS /c/install
  6049.  # AFS /usr/afsws/bin/install, which mishandles nonexistent args
  6050.  # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
  6051.  # ./install, which can be erroneously created by make from ./install.sh.
  6052. @@ -629,7 +693,7 @@ else
  6053.    for ac_dir in $PATH; do
  6054.      # Account for people who put trailing slashes in PATH elements.
  6055.      case "$ac_dir/" in
  6056. -    /|./|.//|/etc/*|/usr/sbin/*|/usr/etc/*|/sbin/*|/usr/afsws/bin/*|/usr/ucb/*) ;;
  6057. +    /|./|.//|/etc/*|/c/*|/usr/sbin/*|/usr/etc/*|/sbin/*|/usr/afsws/bin/*|/usr/ucb/*) ;;
  6058.      *)
  6059.        # OSF1 and SCO ODT 3.0 have their own names for install.
  6060.        for ac_prog in ginstall installbsd scoinst install; do
  6061. @@ -685,12 +749,13 @@ else
  6062.    # On the NeXT, cc -E runs the code through the compiler's parser,
  6063.    # not just through cpp.
  6064.    cat > conftest.$ac_ext <<EOF
  6065. -#line 689 "configure"
  6066. +#line 753 "configure"
  6067.  #include "confdefs.h"
  6068.  #include <assert.h>
  6069.  Syntax Error
  6070.  EOF
  6071. -eval "$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6072. +ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6073. +{ (eval echo configure:759: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  6074.  ac_err=`grep -v '^ *+' conftest.out`
  6075.  if test -z "$ac_err"; then
  6076.    :
  6077. @@ -699,12 +764,13 @@ else
  6078.    rm -rf conftest*
  6079.    CPP="${CC-cc} -E -traditional-cpp"
  6080.    cat > conftest.$ac_ext <<EOF
  6081. -#line 703 "configure"
  6082. +#line 768 "configure"
  6083.  #include "confdefs.h"
  6084.  #include <assert.h>
  6085.  Syntax Error
  6086.  EOF
  6087. -eval "$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6088. +ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6089. +{ (eval echo configure:774: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  6090.  ac_err=`grep -v '^ *+' conftest.out`
  6091.  if test -z "$ac_err"; then
  6092.    :
  6093. @@ -730,11 +796,12 @@ if eval "test \"`echo '$''{'ac_cv_header
  6094.    echo $ac_n "(cached) $ac_c" 1>&6
  6095.  else
  6096.    cat > conftest.$ac_ext <<EOF
  6097. -#line 734 "configure"
  6098. +#line 800 "configure"
  6099.  #include "confdefs.h"
  6100.  #include <minix/config.h>
  6101.  EOF
  6102. -eval "$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6103. +ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6104. +{ (eval echo configure:805: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  6105.  ac_err=`grep -v '^ *+' conftest.out`
  6106.  if test -z "$ac_err"; then
  6107.    rm -rf conftest*
  6108. @@ -799,11 +866,11 @@ else
  6109.    ac_cv_c_cross=yes
  6110.  else
  6111.  cat > conftest.$ac_ext <<EOF
  6112. -#line 803 "configure"
  6113. +#line 870 "configure"
  6114.  #include "confdefs.h"
  6115.  main(){return(0);}
  6116.  EOF
  6117. -eval $ac_link
  6118. +{ (eval echo configure:874: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
  6119.  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  6120.    ac_cv_c_cross=no
  6121.  else
  6122. @@ -821,14 +888,15 @@ if eval "test \"`echo '$''{'ac_cv_header
  6123.    echo $ac_n "(cached) $ac_c" 1>&6
  6124.  else
  6125.    cat > conftest.$ac_ext <<EOF
  6126. -#line 825 "configure"
  6127. +#line 892 "configure"
  6128.  #include "confdefs.h"
  6129.  #include <stdlib.h>
  6130.  #include <stdarg.h>
  6131.  #include <string.h>
  6132.  #include <float.h>
  6133.  EOF
  6134. -eval "$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6135. +ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6136. +{ (eval echo configure:900: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  6137.  ac_err=`grep -v '^ *+' conftest.out`
  6138.  if test -z "$ac_err"; then
  6139.    rm -rf conftest*
  6140. @@ -843,7 +911,7 @@ rm -f conftest*
  6141.  if test $ac_cv_header_stdc = yes; then
  6142.    # SunOS 4.x string.h does not declare mem*, contrary to ANSI.
  6143.  cat > conftest.$ac_ext <<EOF
  6144. -#line 847 "configure"
  6145. +#line 915 "configure"
  6146.  #include "confdefs.h"
  6147.  #include <string.h>
  6148.  EOF
  6149. @@ -861,7 +929,7 @@ fi
  6150.  if test $ac_cv_header_stdc = yes; then
  6151.    # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI.
  6152.  cat > conftest.$ac_ext <<EOF
  6153. -#line 865 "configure"
  6154. +#line 933 "configure"
  6155.  #include "confdefs.h"
  6156.  #include <stdlib.h>
  6157.  EOF
  6158. @@ -882,7 +950,7 @@ if test "$cross_compiling" = yes; then
  6159.    :
  6160.  else
  6161.  cat > conftest.$ac_ext <<EOF
  6162. -#line 886 "configure"
  6163. +#line 954 "configure"
  6164.  #include "confdefs.h"
  6165.  #include <ctype.h>
  6166.  #define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
  6167. @@ -893,7 +961,7 @@ if (XOR (islower (i), ISLOWER (i)) || to
  6168.  exit (0); }
  6169.  
  6170.  EOF
  6171. -eval $ac_link
  6172. +{ (eval echo configure:965: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
  6173.  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  6174.    :
  6175.  else
  6176. @@ -920,11 +988,12 @@ if eval "test \"`echo '$''{'ac_cv_header
  6177.    echo $ac_n "(cached) $ac_c" 1>&6
  6178.  else
  6179.    cat > conftest.$ac_ext <<EOF
  6180. -#line 924 "configure"
  6181. +#line 992 "configure"
  6182.  #include "confdefs.h"
  6183.  #include <$ac_hdr>
  6184.  EOF
  6185. -eval "$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6186. +ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
  6187. +{ (eval echo configure:997: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
  6188.  ac_err=`grep -v '^ *+' conftest.out`
  6189.  if test -z "$ac_err"; then
  6190.    rm -rf conftest*
  6191. @@ -954,7 +1023,7 @@ if eval "test \"`echo '$''{'ac_cv_c_cons
  6192.    echo $ac_n "(cached) $ac_c" 1>&6
  6193.  else
  6194.    cat > conftest.$ac_ext <<EOF
  6195. -#line 958 "configure"
  6196. +#line 1027 "configure"
  6197.  #include "confdefs.h"
  6198.  
  6199.  int main() { return 0; }
  6200. @@ -1004,7 +1073,7 @@ ccp = (char const *const *) p;
  6201.  
  6202.  ; return 0; }
  6203.  EOF
  6204. -if eval $ac_compile; then
  6205. +if { (eval echo configure:1077: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
  6206.    rm -rf conftest*
  6207.    ac_cv_c_const=yes
  6208.  else
  6209. @@ -1031,15 +1100,15 @@ if eval "test \"`echo '$''{'ac_cv_header
  6210.    echo $ac_n "(cached) $ac_c" 1>&6
  6211.  else
  6212.    cat > conftest.$ac_ext <<EOF
  6213. -#line 1035 "configure"
  6214. +#line 1104 "configure"
  6215.  #include "confdefs.h"
  6216.  #include <alloca.h>
  6217. -int main() { return 0; }
  6218. +int main() { t(); return 0; }
  6219.  int t() {
  6220.  char *p = alloca(2 * sizeof(int));
  6221.  ; return 0; }
  6222.  EOF
  6223. -if eval $ac_link; then
  6224. +if { (eval echo configure:1112: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
  6225.    rm -rf conftest*
  6226.    ac_cv_header_alloca_h=yes
  6227.  else
  6228. @@ -1063,7 +1132,7 @@ if eval "test \"`echo '$''{'ac_cv_func_a
  6229.    echo $ac_n "(cached) $ac_c" 1>&6
  6230.  else
  6231.    cat > conftest.$ac_ext <<EOF
  6232. -#line 1067 "configure"
  6233. +#line 1136 "configure"
  6234.  #include "confdefs.h"
  6235.  
  6236.  #ifdef __GNUC__
  6237. @@ -1082,12 +1151,12 @@ char *alloca ();
  6238.  # endif
  6239.  #endif
  6240.  
  6241. -int main() { return 0; }
  6242. +int main() { t(); return 0; }
  6243.  int t() {
  6244.  char *p = (char *) alloca(1);
  6245.  ; return 0; }
  6246.  EOF
  6247. -if eval $ac_link; then
  6248. +if { (eval echo configure:1160: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
  6249.    rm -rf conftest*
  6250.    ac_cv_func_alloca=yes
  6251.  else
  6252. @@ -1122,7 +1191,7 @@ if eval "test \"`echo '$''{'ac_cv_os_cra
  6253.    echo $ac_n "(cached) $ac_c" 1>&6
  6254.  else
  6255.    cat > conftest.$ac_ext <<EOF
  6256. -#line 1126 "configure"
  6257. +#line 1195 "configure"
  6258.  #include "confdefs.h"
  6259.  #if defined(CRAY) && ! defined(CRAY2)
  6260.  webecray
  6261. @@ -1151,15 +1220,17 @@ if eval "test \"`echo '$''{'ac_cv_func_$
  6262.    echo $ac_n "(cached) $ac_c" 1>&6
  6263.  else
  6264.    cat > conftest.$ac_ext <<EOF
  6265. -#line 1155 "configure"
  6266. +#line 1224 "configure"
  6267.  #include "confdefs.h"
  6268.  /* System header to define __stub macros and hopefully few prototypes,
  6269.      which can conflict with char $ac_func(); below.  */
  6270.  #include <assert.h>
  6271.  /* Override any gcc2 internal prototype to avoid an error.  */
  6272. +/* We use char because int might match the return type of a gcc2
  6273. +    builtin and then its argument prototype would still apply.  */
  6274.  char $ac_func();
  6275.  
  6276. -int main() { return 0; }
  6277. +int main() { t(); return 0; }
  6278.  int t() {
  6279.  
  6280.  /* The GNU C library defines this for functions which it implements
  6281. @@ -1173,7 +1244,7 @@ $ac_func();
  6282.  
  6283.  ; return 0; }
  6284.  EOF
  6285. -if eval $ac_link; then
  6286. +if { (eval echo configure:1248: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
  6287.    rm -rf conftest*
  6288.    eval "ac_cv_func_$ac_func=yes"
  6289.  else
  6290. @@ -1205,7 +1276,7 @@ else
  6291.    ac_cv_c_stack_direction=0
  6292.  else
  6293.  cat > conftest.$ac_ext <<EOF
  6294. -#line 1209 "configure"
  6295. +#line 1280 "configure"
  6296.  #include "confdefs.h"
  6297.  find_stack_direction ()
  6298.  {
  6299. @@ -1224,7 +1295,7 @@ main ()
  6300.    exit (find_stack_direction() < 0);
  6301.  }
  6302.  EOF
  6303. -eval $ac_link
  6304. +{ (eval echo configure:1299: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
  6305.  if test -s conftest && (./conftest; exit) 2>/dev/null; then
  6306.    ac_cv_c_stack_direction=1
  6307.  else
  6308. @@ -1248,15 +1319,17 @@ if eval "test \"`echo '$''{'ac_cv_func_$
  6309.    echo $ac_n "(cached) $ac_c" 1>&6
  6310.  else
  6311.    cat > conftest.$ac_ext <<EOF
  6312. -#line 1252 "configure"
  6313. +#line 1323 "configure"
  6314.  #include "confdefs.h"
  6315.  /* System header to define __stub macros and hopefully few prototypes,
  6316.      which can conflict with char $ac_func(); below.  */
  6317.  #include <assert.h>
  6318.  /* Override any gcc2 internal prototype to avoid an error.  */
  6319. +/* We use char because int might match the return type of a gcc2
  6320. +    builtin and then its argument prototype would still apply.  */
  6321.  char $ac_func();
  6322.  
  6323. -int main() { return 0; }
  6324. +int main() { t(); return 0; }
  6325.  int t() {
  6326.  
  6327.  /* The GNU C library defines this for functions which it implements
  6328. @@ -1270,7 +1343,7 @@ $ac_func();
  6329.  
  6330.  ; return 0; }
  6331.  EOF
  6332. -if eval $ac_link; then
  6333. +if { (eval echo configure:1347: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
  6334.    rm -rf conftest*
  6335.    eval "ac_cv_func_$ac_func=yes"
  6336.  else
  6337. @@ -1346,7 +1419,7 @@ trap 'rm -f $CONFIG_STATUS conftest*; ex
  6338.  # Protect against shell expansion while executing Makefile rules.
  6339.  # Protect against Makefile macro expansion.
  6340.  cat > conftest.defs <<\EOF
  6341. -s%#define \([A-Za-z_][A-Za-z0-9_]*\) \(.*\)%-D\1=\2%g
  6342. +s%#define \([A-Za-z_][A-Za-z0-9_]*\) *\(.*\)%-D\1=\2%g
  6343.  s%[     `~#$^&*(){}\\|;'"<>?]%\\&%g
  6344.  s%\[%\\&%g
  6345.  s%\]%\\&%g
  6346. @@ -1360,7 +1433,9 @@ rm -f conftest.defs
  6347.  : ${CONFIG_STATUS=./config.status}
  6348.  
  6349.  echo creating $CONFIG_STATUS
  6350. -rm -f $CONFIG_STATUS
  6351. +# Some systems, like AmigaOS, won't allow you to remove a script that is
  6352. +# being executed, so just move it out of the way instead.
  6353. +if test -f $CONFIG_STATUS; then mv $CONFIG_STATUS $CONFIG_STATUS.old; else true; fi
  6354.  cat > $CONFIG_STATUS <<EOF
  6355.  #! /bin/sh
  6356.  # Generated automatically by configure.
  6357. @@ -1381,7 +1456,7 @@ do
  6358.      echo "running \${CONFIG_SHELL-/bin/sh} $0 $ac_configure_args --no-create --no-recursion"
  6359.      exec \${CONFIG_SHELL-/bin/sh} $0 $ac_configure_args --no-create --no-recursion ;;
  6360.    -version | --version | --versio | --versi | --vers | --ver | --ve | --v)
  6361. -    echo "$CONFIG_STATUS generated by autoconf version 2.7"
  6362. +    echo "$CONFIG_STATUS generated by autoconf version 2.10"
  6363.      exit 0 ;;
  6364.    -help | --help | --hel | --he | --h)
  6365.      echo "\$ac_cs_usage"; exit 0 ;;
  6366. @@ -1421,6 +1496,9 @@ s%@libdir@%$libdir%g
  6367.  s%@includedir@%$includedir%g
  6368.  s%@oldincludedir@%$oldincludedir%g
  6369.  s%@infodir@%$infodir%g
  6370. +s%@guidedir@%$guidedir%g
  6371. +s%@psdir@%$psdir%g
  6372. +s%@dvidir@%$dvidir%g
  6373.  s%@mandir@%$mandir%g
  6374.  s%@CC@%$CC%g
  6375.  s%@INSTALL_PROGRAM@%$INSTALL_PROGRAM%g
  6376. @@ -1493,6 +1571,7 @@ rm -f conftest.subs
  6377.  exit 0
  6378.  EOF
  6379.  chmod +x $CONFIG_STATUS
  6380. +rm -f CONFIG.STATUS.old
  6381.  rm -fr confdefs* $ac_clean_files
  6382.  test "$no_create" = yes || ${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1
  6383.  
  6384. diff -rup --new-file baseline/fsf/bison/main.c amiga/fsf/bison/main.c
  6385. --- baseline/fsf/bison/main.c    Sun Oct 15 09:44:08 1995
  6386. +++ amiga/fsf/bison/main.c    Sat Sep 28 00:00:00 1996
  6387. @@ -163,7 +163,13 @@ warn(s)
  6388.      fprintf(stderr, "(\"%s\", line %d) error: %s\n", 
  6389.          infile, lineno, s);
  6390.  
  6391. +#ifndef __amigaos__
  6392. +  /* The ADE contains at least one program (f2c) where warnings are
  6393. +     generated by the grammar files, so don't abort for now.  I'm not
  6394. +     even sure why a warnings were changed to be errors, other than
  6395. +     to try and force people to fix their grammar files. -fnf */
  6396.    failure = 1;
  6397. +#endif
  6398.  }
  6399.  
  6400.  /* Print a warning message containing the string for the integer X1.
  6401. diff -rup --new-file baseline/fsf/bison/manifests/bin amiga/fsf/bison/manifests/bin
  6402. --- baseline/fsf/bison/manifests/bin    Wed Dec 31 17:00:00 1969
  6403. +++ amiga/fsf/bison/manifests/bin    Sat Sep 28 00:00:00 1996
  6404. @@ -0,0 +1,15 @@
  6405. +COPYING
  6406. +COPYING.info
  6407. +bin/bison
  6408. +dvi/bison.dvi
  6409. +guide/bison.guide
  6410. +info/bison.info
  6411. +info/bison.info-1
  6412. +info/bison.info-2
  6413. +info/bison.info-3
  6414. +info/bison.info-4
  6415. +info/bison.info-5
  6416. +man/man1/bison.1
  6417. +ps/bison.ps
  6418. +share/bison.hairy
  6419. +share/bison.simple
  6420. diff -rup --new-file baseline/fsf/bison/manifests/src amiga/fsf/bison/manifests/src
  6421. --- baseline/fsf/bison/manifests/src    Wed Dec 31 17:00:00 1969
  6422. +++ amiga/fsf/bison/manifests/src    Sat Sep 28 00:00:00 1996
  6423. @@ -0,0 +1,58 @@
  6424. +fsf/bison/BeOS.diffs
  6425. +fsf/bison/COPYING
  6426. +fsf/bison/ChangeLog
  6427. +fsf/bison/INSTALL
  6428. +fsf/bison/LR0.c
  6429. +fsf/bison/Makefile.in
  6430. +fsf/bison/NEWS
  6431. +fsf/bison/Product-Info
  6432. +fsf/bison/README
  6433. +fsf/bison/REFERENCES
  6434. +fsf/bison/alloca.c
  6435. +fsf/bison/allocate.c
  6436. +fsf/bison/bison.1
  6437. +fsf/bison/bison.cld
  6438. +fsf/bison/bison.hairy
  6439. +fsf/bison/bison.rnh
  6440. +fsf/bison/bison.simple
  6441. +fsf/bison/bison.texinfo
  6442. +fsf/bison/build.com
  6443. +fsf/bison/closure.c
  6444. +fsf/bison/configure
  6445. +fsf/bison/configure.bat
  6446. +fsf/bison/configure.in
  6447. +fsf/bison/conflicts.c
  6448. +fsf/bison/derives.c
  6449. +fsf/bison/files.c
  6450. +fsf/bison/files.h
  6451. +fsf/bison/getargs.c
  6452. +fsf/bison/getopt.c
  6453. +fsf/bison/getopt.h
  6454. +fsf/bison/getopt1.c
  6455. +fsf/bison/gram.c
  6456. +fsf/bison/gram.h
  6457. +fsf/bison/install-sh
  6458. +fsf/bison/lalr.c
  6459. +fsf/bison/lex.c
  6460. +fsf/bison/lex.h
  6461. +fsf/bison/machine.h
  6462. +fsf/bison/main.c
  6463. +fsf/bison/manifests/bin
  6464. +fsf/bison/manifests/src
  6465. +fsf/bison/mkinstalldirs
  6466. +fsf/bison/new.h
  6467. +fsf/bison/nullable.c
  6468. +fsf/bison/output.c
  6469. +fsf/bison/print.c
  6470. +fsf/bison/reader.c
  6471. +fsf/bison/reduce.c
  6472. +fsf/bison/state.h
  6473. +fsf/bison/symtab.c
  6474. +fsf/bison/symtab.h
  6475. +fsf/bison/system.h
  6476. +fsf/bison/texinfo.tex
  6477. +fsf/bison/types.h
  6478. +fsf/bison/version.c
  6479. +fsf/bison/vmsgetargs.c
  6480. +fsf/bison/vmshlp.mar
  6481. +fsf/bison/warshall.c
  6482. diff -rup --new-file baseline/fsf/bison/output.c amiga/fsf/bison/output.c
  6483. --- baseline/fsf/bison/output.c    Wed Jan 24 20:56:24 1996
  6484. +++ amiga/fsf/bison/output.c    Sat Sep 28 00:00:00 1996
  6485. @@ -266,7 +266,8 @@ output()
  6486.      fprintf(ftable, "#include <stdio.h>\n\n");
  6487.  
  6488.    /* Make "const" do nothing if not in ANSI C.  */
  6489. -  fprintf (ftable, "#ifndef __cplusplus\n#ifndef __STDC__\n#define const\n#endif\n#endif\n\n");
  6490. +  /* However don't override a previous #define if one exists.  -fnf */
  6491. +  fprintf (ftable, "#ifndef __cplusplus\n#ifndef __STDC__\n#ifndef const\n#define const\n#endif\n#endif\n#endif\n\n");
  6492.  
  6493.    free_itemsets();
  6494.    output_defines();
  6495.