While parsing our COBOL with Koopa I found that paragraphnames like: "00-00", are not accepted by Koopa while our (IBM)compiler doesn't mind. Koopa probably doesn't classify this string as a cobolword while the compiler probably recognizes this string as a paragraphname because of it's position. How can I make Koopa to also recognize this type of string as a paragraphname?
Thanx in advance for your reply.
Rob Stapper
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"00-00" is being rejected by the cobolWord grammar rule, which you can find in CobolPreprocessing.natives. The logic is based on specs I found which say that you need at least one letter to get a valid cobolWord.
Could you share which version of IBM Cobol you're using ? I'll then see about relaxing the rule a bit; but I would like to attribute the relaxed rule to something concrete.
Kris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You'll find the rule in the COBOL standard (if you have the 20xx draft it's 8.3.1.1 COBOL words), here is a quote of the important part (bold [**] added by me to highlight, italic [*] added by me as comment:
A COBOL word is a character-string of not more than 31 characters(the number of characters varies in each standard and different vendors allow longer words) that forms a compiler-directive word, a context-sensitive word, an intrinsic-function-name, a reserved word, a system-name, or a user-defined word. Each character of a COBOL word that is not a special character word shall be selected from the set of basic letters, basic digits, extended letters, and the basic special characters hyphen and underscore. The hyphen or underscore shall not appear as the first or last character in such words.
The standard is very clear that a level-number is a user-defined word (which has additional rules...) and that a level-number can be used multiple times (of course ;-) and can be identical to a paragraph-/section-name.
Therefore both 00 and 00-00 are totaly valid as paragraph-/section-name (and ever were, as far as I know).
I'll try to fix this soon. I'll need to make the cobolWord logic a bit more complex as an input like "00-00" gets split into several tokens, which I'll need to "weld" back together. Nothing problematic; will just require some time.
PS. Cobol rulez. ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I decided to commit a version ([r183]) which resolves Rob's original problem, but does not go as far as allowing all integers as valid cobol words. I'll take another look at that later.
@Simon:
What does GnuCobol have to do with this topic?
This question is meant seriously, not provocative.
If one is interested in static source code analysis, how does GnuCobol help here? Are there ways to access the internal structures occuring during the compile process?
I guess there are any internal structues? Or are the statements (more or less) 1:1 translated to C. I really know only a little bit about GnuCobol, but it would be interesting for me if I could (easily) access internal compiler structures with Java or any other PL.
In my eyes koopa and GnuCobol are completely different projects with completely different goals.
Btw: As koopa keeps evolving, one of its original purposes gets redundant: the WATER fades away, so koopa is not an island-grammar anymore but a dessert with some oases. ;-)
(at least for my modules)
Last edit: FrankTheTank 2015-01-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Despite the teasing between the projects that is possible because of the different goals (GnuCOBOL as a compiler has to know what everything means, translate it to actually work and pass as much as possible syntax issues clearly back to the programmer <-> Koopa as an external parser for accessing structures only without the need to know what's what; the option to WATER [which it still does on some of the sources I've to cope with - getting better and better, of course]), there is always the possibilities for these projects to enlighten each other (including possible issues both have and source samples which are provided to reproduce them ;-).
And both projects may share (at least for some time) the same users, maybe even in kind of advertising.
Concerning your second question: GnuCOBOL reads the necessary files into it's internal structures in different steps. Most of them are not exported as it's not the goal of the compiler to be a frontend, but you can easily change it as it is GPLed (as long as you don't breach the GPL of course and provide back). The likely cleanest solution would be another source file in cobc that implements functions to parse a file completely and access these structures with/without creating C files.
Some of the structures get exported and included in the runtime modules / executables and therefore are accessible at runtime, too, for example the fields (definition, size, value, ...).
If someone is up to extend cobc for an easy external access (something like a new libparsecob within cobc and the cobc executable calling its functions) I'm willing to open a semi-official branch in GC's repository :-)
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I was working on AspectCobol stuff for my PhD research I had to figure out a way to parse and manipulate the Cobol sources I was given. I tried several solutions which existed at that time, including cobc (now GnuCOBOL). None of them worked to my satisfaction for two big reasons: I was not given all source code for it to be a compilable unit (it was industrial code shared for research purposes, but only selected parts), and what I did have typically contained constructs which were not understood by the existing tools.
And this is the big difference between Koopa and GnuCOBOL: Koopa should accept whatever you throw at it and tell you as much about it as it can. GnuCOBOL, on the other hand, should tell you when you throw something at it which it doesn't understand. (In island grammar terms: Koopa embraces the water, while GnuCOBOL does not want to get its feet wet.)
I'm actually very grateful to have Simon be part of the Koopa community. He has a lot of active Cobol knowledge, which has helped me out tremendously trying to figure out some of the parse problems which have been reported here. I wish I could do more and help him out on GnuCOBOL as well, but that's beyond me for now. :-)
Kris
PS. Some of the reasoning and guiding principles of Koopa can be found in the guide.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Simon:
Thank you for your comment. To read more about (and get used to) GnuCobol is definitly on my ToDo list.
@Kris:
I read your paper on AspectCobol quite a long time ago. I found it very interesting and aspect-oriented features would without a doubt be useful AddOns for Cobol.
Do you know if there are any follow-ups to your paper or even an active development for AspectCobol?
I once asked in the GnuCobol forum if they would support aspect orientation in the future, but Brian Tiffin was pessimistic because of some legal issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only follow up to AspectCobol that I know off was by Hitachi. They presented a paper on it at AOSD 2008: An aspect-oriented Cobol for the industrial setting, by T Morioka, H. Danno and H. Shinomi (Hitachi).
Not sure what legal issues there would be with adding AOP to Cobol ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Kris,
While parsing our COBOL with Koopa I found that paragraphnames like: "00-00", are not accepted by Koopa while our (IBM)compiler doesn't mind. Koopa probably doesn't classify this string as a cobolword while the compiler probably recognizes this string as a paragraphname because of it's position. How can I make Koopa to also recognize this type of string as a paragraphname?
Thanx in advance for your reply.
Rob Stapper
"00-00" is being rejected by the cobolWord grammar rule, which you can find in CobolPreprocessing.natives. The logic is based on specs I found which say that you need at least one letter to get a valid cobolWord.
Could you share which version of IBM Cobol you're using ? I'll then see about relaxing the rule a bit; but I would like to attribute the relaxed rule to something concrete.
Kris
You'll find the rule in the COBOL standard (if you have the 20xx draft it's 8.3.1.1 COBOL words), here is a quote of the important part (bold [**] added by me to highlight, italic [*] added by me as comment:
The standard is very clear that a level-number is a user-defined word (which has additional rules...) and that a level-number can be used multiple times (of course ;-) and can be identical to a paragraph-/section-name.
Therefore both 00 and 00-00 are totaly valid as paragraph-/section-name (and ever were, as far as I know).
Simon
BTW: GnuCOBOL rulez ;-)
Last edit: Simon Sobisch 2015-01-13
Cool; thanks for that Simon. :-)
I'll try to fix this soon. I'll need to make the cobolWord logic a bit more complex as an input like "00-00" gets split into several tokens, which I'll need to "weld" back together. Nothing problematic; will just require some time.
PS. Cobol rulez. ;-)
Allowing integers as valid cobolWords is causing some regressions in the Cobol grammar... This is going to take a bit more time than I expected.
I decided to commit a version ([r183]) which resolves Rob's original problem, but does not go as far as allowing all integers as valid cobol words. I'll take another look at that later.
Related
Commit: [r183]
thanx Kris.
@Simon:
What does GnuCobol have to do with this topic?
This question is meant seriously, not provocative.
If one is interested in static source code analysis, how does GnuCobol help here? Are there ways to access the internal structures occuring during the compile process?
I guess there are any internal structues? Or are the statements (more or less) 1:1 translated to C. I really know only a little bit about GnuCobol, but it would be interesting for me if I could (easily) access internal compiler structures with Java or any other PL.
In my eyes koopa and GnuCobol are completely different projects with completely different goals.
Btw: As koopa keeps evolving, one of its original purposes gets redundant: the WATER fades away, so koopa is not an island-grammar anymore but a dessert with some oases. ;-)
(at least for my modules)
Last edit: FrankTheTank 2015-01-16
Hi Frank,
the question is valid and fine.
Despite the teasing between the projects that is possible because of the different goals (GnuCOBOL as a compiler has to know what everything means, translate it to actually work and pass as much as possible syntax issues clearly back to the programmer <-> Koopa as an external parser for accessing structures only without the need to know what's what; the option to WATER [which it still does on some of the sources I've to cope with - getting better and better, of course]), there is always the possibilities for these projects to enlighten each other (including possible issues both have and source samples which are provided to reproduce them ;-).
And both projects may share (at least for some time) the same users, maybe even in kind of advertising.
Concerning your second question: GnuCOBOL reads the necessary files into it's internal structures in different steps. Most of them are not exported as it's not the goal of the compiler to be a frontend, but you can easily change it as it is GPLed (as long as you don't breach the GPL of course and provide back). The likely cleanest solution would be another source file in cobc that implements functions to parse a file completely and access these structures with/without creating C files.
Some of the structures get exported and included in the runtime modules / executables and therefore are accessible at runtime, too, for example the fields (definition, size, value, ...).
If someone is up to extend cobc for an easy external access (something like a new libparsecob within cobc and the cobc executable calling its functions) I'm willing to open a semi-official branch in GC's repository :-)
Simon
When I was working on AspectCobol stuff for my PhD research I had to figure out a way to parse and manipulate the Cobol sources I was given. I tried several solutions which existed at that time, including cobc (now GnuCOBOL). None of them worked to my satisfaction for two big reasons: I was not given all source code for it to be a compilable unit (it was industrial code shared for research purposes, but only selected parts), and what I did have typically contained constructs which were not understood by the existing tools.
And this is the big difference between Koopa and GnuCOBOL: Koopa should accept whatever you throw at it and tell you as much about it as it can. GnuCOBOL, on the other hand, should tell you when you throw something at it which it doesn't understand. (In island grammar terms: Koopa embraces the water, while GnuCOBOL does not want to get its feet wet.)
I'm actually very grateful to have Simon be part of the Koopa community. He has a lot of active Cobol knowledge, which has helped me out tremendously trying to figure out some of the parse problems which have been reported here. I wish I could do more and help him out on GnuCOBOL as well, but that's beyond me for now. :-)
Kris
PS. Some of the reasoning and guiding principles of Koopa can be found in the guide.
@Simon:
Thank you for your comment. To read more about (and get used to) GnuCobol is definitly on my ToDo list.
@Kris:
I read your paper on AspectCobol quite a long time ago. I found it very interesting and aspect-oriented features would without a doubt be useful AddOns for Cobol.
Do you know if there are any follow-ups to your paper or even an active development for AspectCobol?
I once asked in the GnuCobol forum if they would support aspect orientation in the future, but Brian Tiffin was pessimistic because of some legal issues.
The only follow up to AspectCobol that I know off was by Hitachi. They presented a paper on it at AOSD 2008: An aspect-oriented Cobol for the industrial setting, by T Morioka, H. Danno and H. Shinomi (Hitachi).
Not sure what legal issues there would be with adding AOP to Cobol ?
See http://sourceforge.net/p/open-cobol/discussion/cobol/thread/dff22a1f/?limit=25#5f05