Thread: [Cobolforgcc-devel] yacc/bison question
Status: Pre-Alpha
Brought to you by:
timjosling
From: Matthew V. <lin...@ho...> - 2001-06-11 01:36:18
|
Tim, I was working on my file i/o grammar this weekend, and ran into some issues with the LOCK MODE clause. I've kinda got it figured out, but I'm not certain that it's the correct way: I've got a clause: LOCK [MODE IS] {MANUAL | AUTOMATIC} [[WITH] LOCK ON {RECORD | RECORDS}] The two LOCKs were causing reduce/reduce errors. I finally ended up sticking a "LOCK_ON" token in cobctok.def to alleviate the ambiguity for bison/yacc. I'm a little worried about the kvalue, however. I've set it to "LOCK ON". I'd like to figure out a way to delete that token, and still not have any shift/reduce or reduce/reduce errors.=20 Here's the relevant bit from my file.tpl: lock_mode_clause: LOCK opt_mode opt_is manual_or_auto_kw opt_lock_on_clause { RSN($1, "Lock Mode not yet supported"); } ; manual_or_auto_kw: MANUAL | AUTOMATIC ; opt_lock_on_clause: /* nothing */ | with_lock_on ; with_lock_on: opt_with lock_on ; lock_on: LOCK_ON record_or_records ; record_or_records: RECORD | RECORDS ; If I change the "LOCK_ON" to "LOCK ON", I get a reduce/reduce error. I would rather not have any errors, but I'm still a little dubious about a "LOCK_ON" token. Thoughts? -- Matthew Vanecek perl -e 'print $i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ***************************************************************************= ***** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... |
From: Tim J. <te...@me...> - 2001-06-11 02:49:55
|
Matthew, Good to hear from you. There is no LOCK MODE in COBOL 85, so you can just omit it (for now). It is only in COBOL 2002. The problem appears to be due to the fact that the LOCK could be the start of a LOCK ON MULTIPLE or the start of a second occurrence of the LOCK MODE clause. You basically have the right answer. Function set_up_magic_tokens will need to be updated to change the first LOCK to a magic token like LOCK_magic_starts_whole_clause. The logic for this would be if it is not followed by ON, RECORD or RECORDS it must be the first one. If this makes no sense, please send me *all* the files. Are you in a position to do a copyright assignment to the free software foundation for this work. I will attach the files which explain it all. Without the assignments we will not be able to have the compiler incorporated into the official GCC. Please have a look. Tim Josling Matthew Vanecek wrote: > > Tim, > I was working on my file i/o grammar this weekend, and ran into some > issues with the LOCK MODE clause. I've kinda got it figured out, but > I'm not certain that it's the correct way: > > I've got a clause: > > LOCK [MODE IS] {MANUAL | AUTOMATIC} [[WITH] LOCK ON {RECORD | RECORDS}] > > The two LOCKs were causing reduce/reduce errors. I finally ended up > sticking a "LOCK_ON" token in cobctok.def to alleviate the ambiguity for > bison/yacc. I'm a little worried about the kvalue, however. I've set > it to "LOCK ON". I'd like to figure out a way to delete that token, and > still not have any shift/reduce or reduce/reduce errors. > > Here's the relevant bit from my file.tpl: > > lock_mode_clause: > LOCK opt_mode opt_is manual_or_auto_kw opt_lock_on_clause { > RSN($1, "Lock Mode not yet supported"); > } > ; > > manual_or_auto_kw: > MANUAL > | AUTOMATIC > ; > > opt_lock_on_clause: > /* nothing */ > | with_lock_on > ; > > with_lock_on: > opt_with lock_on > ; > > lock_on: > LOCK_ON record_or_records > ; > > record_or_records: > RECORD > | RECORDS > ; > > If I change the "LOCK_ON" to "LOCK ON", I get a reduce/reduce error. I > would rather not have any errors, but I'm still a little dubious about a > "LOCK_ON" token. > > Thoughts? > -- > Matthew Vanecek > perl -e 'print > $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' > ******************************************************************************** > For 93 million miles, there is nothing between the sun and my shadow > except me. > I'm always getting in the way of something... > > ----------------------------------------------------------------- > Part 1.2Type: application/pgp-signature |
From: William M. K. <wm...@ix...> - 2001-06-11 18:53:08
|
FYI - even in the draft COBOL Standard "file-sharing/record-locking" is in the Processor Dependent list. Therefore, I would suggest (?) that it be placed in the "later" category, and that any work on 200x features concentrate on those features that are REQUIRED (at least first). > -----Original Message----- > From: cob...@li... > [mailto:cob...@li...]On Behalf Of Tim > Josling > Sent: Sunday, June 10, 2001 9:42 PM > To: cob...@li... > Subject: Re: [Cobolforgcc-devel] yacc/bison question > > > Matthew, > > Good to hear from you. > > There is no LOCK MODE in COBOL 85, so you can just omit it (for > now). It is only in COBOL 2002. > > The problem appears to be due to the fact that the LOCK could be > the start of a LOCK ON MULTIPLE or the start of a second > occurrence of the LOCK MODE clause. > > You basically have the right answer. Function set_up_magic_tokens > will need to be updated to change the first LOCK to a magic token > like LOCK_magic_starts_whole_clause. The logic for this would be > if it is not followed by ON, RECORD or RECORDS it must be the > first one. > > If this makes no sense, please send me *all* the files. > > Are you in a position to do a copyright assignment to the free > software foundation for this work. I will attach the files which > explain it all. Without the assignments we will not be able to > have the compiler incorporated into the official GCC. Please have > a look. > > Tim Josling > > Matthew Vanecek wrote: > > > > Tim, > > I was working on my file i/o grammar this weekend, and ran into some > > issues with the LOCK MODE clause. I've kinda got it figured out, but > > I'm not certain that it's the correct way: > > > > I've got a clause: > > > > LOCK [MODE IS] {MANUAL | AUTOMATIC} [[WITH] LOCK ON {RECORD | RECORDS}] > > > > The two LOCKs were causing reduce/reduce errors. I finally ended up > > sticking a "LOCK_ON" token in cobctok.def to alleviate the ambiguity for > > bison/yacc. I'm a little worried about the kvalue, however. I've set > > it to "LOCK ON". I'd like to figure out a way to delete that token, and > > still not have any shift/reduce or reduce/reduce errors. > > > > Here's the relevant bit from my file.tpl: > > > > lock_mode_clause: > > LOCK opt_mode opt_is manual_or_auto_kw opt_lock_on_clause { > > RSN($1, "Lock Mode not yet supported"); > > } > > ; > > > > manual_or_auto_kw: > > MANUAL > > | AUTOMATIC > > ; > > > > opt_lock_on_clause: > > /* nothing */ > > | with_lock_on > > ; > > > > with_lock_on: > > opt_with lock_on > > ; > > > > lock_on: > > LOCK_ON record_or_records > > ; > > > > record_or_records: > > RECORD > > | RECORDS > > ; > > > > If I change the "LOCK_ON" to "LOCK ON", I get a reduce/reduce error. I > > would rather not have any errors, but I'm still a little dubious about a > > "LOCK_ON" token. > > > > Thoughts? > > -- > > Matthew Vanecek > > perl -e 'print > > $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' > > > ****************************************************************** > ************** > > For 93 million miles, there is nothing between the sun and my shadow > > except me. > > I'm always getting in the way of something... > > > > ----------------------------------------------------------------- > > Part 1.2Type: application/pgp-signature |
From: Matthew V. <lin...@ho...> - 2001-06-12 01:15:08
|
On 11 Jun 2001 13:53:04 -0500, William M. Klein wrote: > FYI - even in the draft COBOL Standard "file-sharing/record-locking" is in > the Processor Dependent list. Therefore, I would suggest (?) that it be > placed in the "later" category, and that any work on 200x features > concentrate on those features that are REQUIRED (at least first). > Very true, and I will be marking much as RSN. I just wanted to get the grammar itself as complete as possible. -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ******************************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... |
From: Tim J. <te...@me...> - 2001-06-12 22:53:52
|
Matthew, I would prefer to leave out anything that is not in the COBOL 85 standard at this stage. Building a cobol 85 compiler is big enough. I have had my fingers burned in the past doing extensions. If you do add any other features, please make sure it does not break any legal cobol 85 programs (eg by adding new keywords that cannot be turned off). Tim Josling Matthew Vanecek wrote: > > On 11 Jun 2001 13:53:04 -0500, William M. Klein wrote: > > FYI - even in the draft COBOL Standard "file-sharing/record-locking" is in > > the Processor Dependent list. Therefore, I would suggest (?) that it be > > placed in the "later" category, and that any work on 200x features > > concentrate on those features that are REQUIRED (at least first). > > > > Very true, and I will be marking much as RSN. I just wanted to get the > grammar itself as complete as possible. > -- > Matthew Vanecek > perl -e 'print > $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' > ******************************************************************************** > For 93 million miles, there is nothing between the sun and my shadow > except me. > I'm always getting in the way of something... > > _______________________________________________ > Cobolforgcc-devel mailing list > Cob...@li... > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel |