Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Object Oriented pre-compiler, request for feedback
55 views
Skip to first unread message
Message has been deleted
Pete Dashwood
May 17, 2013, 9:55:34 PM5/17/13
to
Patrick wrote:
> Hi Everyone
>
> I am trying to use Cobol well outside of it's traditional domain. My
> interest is in controlling scientific instruments and processing data
> from them. Open Cobol is easy to use in tandem with C, the only thing
> is I would like to use the best strategy to create reusable code for
> others when I write Cobol libraries.
>
> OO seems to offer a somewhat standard way of organizing code, at
> least in comparison to Cobol 85 but currently open Cobol does not
> support OO.
>
> I am thinking about writing a small compiler that will translate OO
> Cobol into Cobol 85.
>
> It's my understanding that the first C++ complier merely translated
> C++ code into C. It seems like someone could still get good C++
> coverage with just C, it's just that stuffing function pointers into
> structs makes for hard to read code and so on.
>
> Is it reasonable to assume that Cobol 85 code could be organized to
> simulate OO Cobol constructs? If so I could probably right my
> libraries in OO style and then use a command to translate them to
> what might be called Cobol 85+, open Cobol, with support for some of
> the 2002 standard and most of the 85 one.
>
> Feedback would be appreciated-Patrick
The ONLY reason I am not using Open COBOL (which I support in spirit) is
because it doesn't support Object Oriented COBOL constructs and the
Component Object Model interface.
Any move to extend it in this direction can only be welcomed.
COM enabled COBOL works very well with other OO languages and I have Fujitsu
NetCOBOL (Native code) components I have written over years which interface
easily with components written in Java (through CORBA), VB.Net, and C#.
These components run without problem in the .Net environment, using the
InterOP services of the .Net Framework, provided by Microsoft.
I would gladly replace all of them with Open COBOL if it could support the
COM interface.
Coming back to your post; I don't think you need to "translate" OO COBOL to
COBOL 85; is it not possible to use the C++ libraries directly?
Good luck with your endeavour.
Pete.
--
"I used to write COBOL...now I can do anything."
> Hi Everyone
>
> I am trying to use Cobol well outside of it's traditional domain. My
> interest is in controlling scientific instruments and processing data
> from them. Open Cobol is easy to use in tandem with C, the only thing
> is I would like to use the best strategy to create reusable code for
> others when I write Cobol libraries.
>
> OO seems to offer a somewhat standard way of organizing code, at
> least in comparison to Cobol 85 but currently open Cobol does not
> support OO.
>
> I am thinking about writing a small compiler that will translate OO
> Cobol into Cobol 85.
>
> It's my understanding that the first C++ complier merely translated
> C++ code into C. It seems like someone could still get good C++
> coverage with just C, it's just that stuffing function pointers into
> structs makes for hard to read code and so on.
>
> Is it reasonable to assume that Cobol 85 code could be organized to
> simulate OO Cobol constructs? If so I could probably right my
> libraries in OO style and then use a command to translate them to
> what might be called Cobol 85+, open Cobol, with support for some of
> the 2002 standard and most of the 85 one.
>
> Feedback would be appreciated-Patrick
The ONLY reason I am not using Open COBOL (which I support in spirit) is
because it doesn't support Object Oriented COBOL constructs and the
Component Object Model interface.
Any move to extend it in this direction can only be welcomed.
COM enabled COBOL works very well with other OO languages and I have Fujitsu
NetCOBOL (Native code) components I have written over years which interface
easily with components written in Java (through CORBA), VB.Net, and C#.
These components run without problem in the .Net environment, using the
InterOP services of the .Net Framework, provided by Microsoft.
I would gladly replace all of them with Open COBOL if it could support the
COM interface.
Coming back to your post; I don't think you need to "translate" OO COBOL to
COBOL 85; is it not possible to use the C++ libraries directly?
Good luck with your endeavour.
Pete.
--
"I used to write COBOL...now I can do anything."
Robert Wessel
May 18, 2013, 5:24:17 AM5/18/13
to
On Fri, 17 May 2013 17:27:15 -0700 (PDT), Patrick
<halfm...@gmail.com> wrote:
>Hi Everyone
>
>I am trying to use Cobol well outside of it's traditional domain. My interest is in controlling scientific instruments and processing data from them. Open Cobol is easy to use in tandem with C, the only thing is I would like to use the best strategy to create reusable code for others when I write Cobol libraries.
>
>OO seems to offer a somewhat standard way of organizing code, at least in comparison to Cobol 85 but currently open Cobol does not support OO.
>
>I am thinking about writing a small compiler that will translate OO Cobol into Cobol 85.
>
>It's my understanding that the first C++ complier merely translated C++ code into C. It seems like someone could still get good C++ coverage with just C, it's just that stuffing function pointers into structs makes for hard to read code and so on.
>
>Is it reasonable to assume that Cobol 85 code could be organized to simulate OO Cobol constructs? If so I could probably right my libraries in OO style and then use a command to translate them to what might be called Cobol 85+, open Cobol, with support for some of the 2002 standard and most of the 85 one.
First, you can do OO programming in almost any languages, although
<halfm...@gmail.com> wrote:
>Hi Everyone
>
>I am trying to use Cobol well outside of it's traditional domain. My interest is in controlling scientific instruments and processing data from them. Open Cobol is easy to use in tandem with C, the only thing is I would like to use the best strategy to create reusable code for others when I write Cobol libraries.
>
>OO seems to offer a somewhat standard way of organizing code, at least in comparison to Cobol 85 but currently open Cobol does not support OO.
>
>I am thinking about writing a small compiler that will translate OO Cobol into Cobol 85.
>
>It's my understanding that the first C++ complier merely translated C++ code into C. It seems like someone could still get good C++ coverage with just C, it's just that stuffing function pointers into structs makes for hard to read code and so on.
>
>Is it reasonable to assume that Cobol 85 code could be organized to simulate OO Cobol constructs? If so I could probably right my libraries in OO style and then use a command to translate them to what might be called Cobol 85+, open Cobol, with support for some of the 2002 standard and most of the 85 one.
non-OO languages offer little direct support for that sort of thing,
and you end up doing much of the bookkeeping yourself.
Cfront was a fairly straight-forward creature because many of the
basic C++ OO extensions mapped quite simply onto existing C
constructs. Classes map obviously onto structures (possibly with the
need for some hidden pointers), the "this" pointer is simply an extra
initial parameter passed to member functions, and the name space
issues can be dealt with via fairly simple name mangling schemes.
It's not at all clear to me that Cobol85 supports the stuff you need
to do any of that. Exactly on what Cobol85 facility would you map the
instantiation of an object? There is no really structure definition,
nor even memory allocation. Sure you could hack something out, but it
would be a lot of work. Early versions of cfront were on the order of
25KLOCs, but mainly because the early C++ features were such simple
mappings onto C.
Nor is parsing Cobol easy. C, and early C++, are trivial by
comparison.
FWIW, cfront collapsed as C++ started implementing things that did not
map onto C well, namely exceptions, and I doubt that templates would
have be an easy retrofit into that structure either.
I suspect contributing to the OpenCobol project and adding OO to that
might be more productive.
Message has been deleted
Message has been deleted
Message has been deleted
Pete Dashwood
May 18, 2013, 9:21:02 AM5/18/13
to
Patrick wrote:
> Actually one other idea for code reuse, dead simple......
>
> If I wrote a Cobol library, marked the program as COMMON and prefixed
> every identifier as unnamed, would it be easy for other people to
> COPY the program in as a nested program and by using the REPLACING
> feature, create one or more "instances" of it ?
>
> For example.
>
> unnamed-foo becomes my-foo your-foo
You must do whatever you feel comfortable with but I'd run your ideas past
Roger at Open COBOL before you invest too much time.
Although Fujitsu use nested programs to implement methods in PowerCOBOL, it
is not (generally) a good idea (and they don't encourage anyone to look at
the generated code.) In effect, all of your objects would be static and
would have to be pre-defined which kind of defeats the object, if you'll
pardon the pun...:-)
If at all possible use the existing Open COBOL libraries and talk to Roger
about extending them to support OO. I'm not a C++ expert but I should think
there are existing libraries that support instantiation, garbage collection,
and so on.
I admire what you are doing, but you need to get some help and discussion
from people who have already worked on Open COBOL.
Try contacting some of the people here:
http://opencobol.add1tocobol.com/#roger
> Actually one other idea for code reuse, dead simple......
>
> If I wrote a Cobol library, marked the program as COMMON and prefixed
> every identifier as unnamed, would it be easy for other people to
> COPY the program in as a nested program and by using the REPLACING
> feature, create one or more "instances" of it ?
>
> For example.
>
> unnamed-foo becomes my-foo your-foo
You must do whatever you feel comfortable with but I'd run your ideas past
Roger at Open COBOL before you invest too much time.
Although Fujitsu use nested programs to implement methods in PowerCOBOL, it
is not (generally) a good idea (and they don't encourage anyone to look at
the generated code.) In effect, all of your objects would be static and
would have to be pre-defined which kind of defeats the object, if you'll
pardon the pun...:-)
If at all possible use the existing Open COBOL libraries and talk to Roger
about extending them to support OO. I'm not a C++ expert but I should think
there are existing libraries that support instantiation, garbage collection,
and so on.
I admire what you are doing, but you need to get some help and discussion
from people who have already worked on Open COBOL.
Try contacting some of the people here:
http://opencobol.add1tocobol.com/#roger
Message has been deleted
Louis Krupp
May 19, 2013, 9:58:48 PM5/19/13
to
On Fri, 17 May 2013 17:27:15 -0700 (PDT), Patrick
<halfm...@gmail.com> wrote:
>Hi Everyone
>
>I am trying to use Cobol well outside of it's traditional domain. My interest is in controlling scientific instruments and processing data from them. Open Cobol is easy to use in tandem with C, the only thing is I would like to use the best strategy to create reusable code for others when I write Cobol libraries.
>
>OO seems to offer a somewhat standard way of organizing code, at least in comparison to Cobol 85 but currently open Cobol does not support OO.
>
>I am thinking about writing a small compiler that will translate OO Cobol into Cobol 85.
>
>It's my understanding that the first C++ complier merely translated C++ code into C. It seems like someone could still get good C++ coverage with just C, it's just that stuffing function pointers into structs makes for hard to read code and so on.
>
>Is it reasonable to assume that Cobol 85 code could be organized to simulate OO Cobol constructs? If so I could probably right my libraries in OO style and then use a command to translate them to what might be called Cobol 85+, open Cobol, with support for some of the 2002 standard and most of the 85 one.
>
>Feedback would be appreciated-Patrick
<halfm...@gmail.com> wrote:
>Hi Everyone
>
>I am trying to use Cobol well outside of it's traditional domain. My interest is in controlling scientific instruments and processing data from them. Open Cobol is easy to use in tandem with C, the only thing is I would like to use the best strategy to create reusable code for others when I write Cobol libraries.
>
>OO seems to offer a somewhat standard way of organizing code, at least in comparison to Cobol 85 but currently open Cobol does not support OO.
>
>I am thinking about writing a small compiler that will translate OO Cobol into Cobol 85.
>
>It's my understanding that the first C++ complier merely translated C++ code into C. It seems like someone could still get good C++ coverage with just C, it's just that stuffing function pointers into structs makes for hard to read code and so on.
>
>Is it reasonable to assume that Cobol 85 code could be organized to simulate OO Cobol constructs? If so I could probably right my libraries in OO style and then use a command to translate them to what might be called Cobol 85+, open Cobol, with support for some of the 2002 standard and most of the 85 one.
>
My question is: What do you intend to do with the extended COBOL code
you hope to write? If you plan to maintain the code for your own use,
and if doing it in some object-oriented extension of COBOL sounds like
a good idea, then I can't think of a single reason why you shouldn't
do it.
On the other hand, if you plan to sell the code you write, especially
in source form, do you really want yours to be the only scientific
instrument interface written in *any* version of COBOL, let alone the
version you're thinking of creating?
C++ can be a nightmare, but it's sometimes possible to find a
reasonable subset. You don't have to use the language's more cryptic
features if you don't want to. If you need object orientation and
speed, then C++ might be the way to go.
If you don't need as much speed, there's Java. I know almost nothing
about Java.
If you want a lightweight scripting language, there's Lua. It's used,
from what I hear, for implementing games. I've played with Lua. I've
gotten simple things to work.
A war story: In the early 80s, I worked at a university that had
bought an academic administrative package written in COBOL and bundled
with a Harris 530 minicomputer. The 530 was a 24-bit machine designed
for number crunching, but someone at Harris apparently wanted to
expand into the data processing market.
Since we needed a package to drive tape backups and track which files
had been backed up to which tapes, I wrote one in COBOL, since that
was the only language compiler we had (I didn't want to write it in
assembler). What I hadn't taken into account was the fact that the
Harris COBOL compiler generated code for branches but library calls
for moves and adds and everything else COBOL did. The backup driver
took way too long to run, and the project was not a success. I don't
recall any complaints about the administrative software, but the
Harris went away after a few years, and the Vaxes came.
Louis
Richard
May 19, 2013, 10:37:27 PM5/19/13
to
On May 20, 1:58 pm, Louis Krupp <lkr...@nospam.pssw.com.invalid>
wrote:
Lua is a very simple and compact scripting language that is mainly
intended as an embedded language. For example I have Lua in one of my
cameras so that it can be scripted to do stuff like focus stacking or
movement detection (see CHDK).
Lua could be easily embedded in a COBOL program and an interface is
available for OpenCOBOL: http://opencobol.add1tocobol.com/oclua.html
A better option might be Python as this is also portable and free, but
has OO features and has a rich set of libraries that would support
interfacing in various ways.
wrote:
> On Fri, 17 May 2013 17:27:15 -0700 (PDT), Patrick
>
>
intended as an embedded language. For example I have Lua in one of my
cameras so that it can be scripted to do stuff like focus stacking or
movement detection (see CHDK).
Lua could be easily embedded in a COBOL program and an interface is
available for OpenCOBOL: http://opencobol.add1tocobol.com/oclua.html
A better option might be Python as this is also portable and free, but
has OO features and has a rich set of libraries that would support
interfacing in various ways.
Richard
May 19, 2013, 10:46:17 PM5/19/13
to
On May 18, 12:27 pm, Patrick <halfmad...@gmail.com> wrote:
> Hi Everyone
>
> I am trying to use Cobol well outside of it's traditional domain. My interest is in controlling scientific instruments and processing data from them. Open Cobol is easy to use in tandem with C, the only thing is I would like to use the best strategy to create reusable code for others when I write Cobol libraries.
>
> OO seems to offer a somewhat standard way of organizing code, at least in comparison to Cobol 85 but currently open Cobol does not support OO.
>
> I am thinking about writing a small compiler that will translate OO Cobol into Cobol 85.
>
> It's my understanding that the first C++ complier merely translated C++ code into C. It seems like someone could still get good C++ coverage with just C, it's just that stuffing function pointers into structs makes for hard to read code and so on.
>
> Is it reasonable to assume that Cobol 85 code could be organized to simulate OO Cobol constructs? If so I could probably right my libraries in OO style and then use a command to translate them to what might be called Cobol 85+, open Cobol, with support for some of the 2002 standard and most of the 85 one.
>
> Feedback would be appreciated-Patrick
As a test I have written some COBOL both as OO and as Cobol'85. Both
> Hi Everyone
>
> I am trying to use Cobol well outside of it's traditional domain. My interest is in controlling scientific instruments and processing data from them. Open Cobol is easy to use in tandem with C, the only thing is I would like to use the best strategy to create reusable code for others when I write Cobol libraries.
>
> OO seems to offer a somewhat standard way of organizing code, at least in comparison to Cobol 85 but currently open Cobol does not support OO.
>
> I am thinking about writing a small compiler that will translate OO Cobol into Cobol 85.
>
> It's my understanding that the first C++ complier merely translated C++ code into C. It seems like someone could still get good C++ coverage with just C, it's just that stuffing function pointers into structs makes for hard to read code and so on.
>
> Is it reasonable to assume that Cobol 85 code could be organized to simulate OO Cobol constructs? If so I could probably right my libraries in OO style and then use a command to translate them to what might be called Cobol 85+, open Cobol, with support for some of the 2002 standard and most of the 85 one.
>
> Feedback would be appreciated-Patrick
were equally easy to write. The non-OO was written as a callable
module where the OO had a class.
https://groups.google.com/group/comp.lang.cobol/browse_frm/thread/41f28746f0fe0366/809a400124d02abe?lnk=gst&q=rawprint#809a400124d02abe
The significant advantage of the OO approach is that multiple objects
could be created for the class, while the module could only have one
occurrence in a run-unit.
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Charles Hottel
May 20, 2013, 2:35:19 PM5/20/13
to
"Patrick" <halfm...@gmail.com> wrote in message
news:c4e9fd08-7f9b-4caa...@googlegroups.com...
Hi Louis
<snip>
Thing things I am really missing is a #include/import/require/with statement
that will bring existing code in, in a manner similar to other languages.
COPY is not the same as #include because code is organized in sections, we
have to use COPY in each section to get the same effect of two files being
merged.
<snip>
IIRC there was an include utility for COBOL written in C. I believe there
was an article about it in Computer Language(?) magazine. I thought I had a
copy of it but I can't find it at the moment. When I have time I will see
if I can locate the article. The book Software Tools bu Kernighan and
Ritchie also has an example of this kind of utility.
Charles Hottel
May 20, 2013, 5:56:13 PM5/20/13
to
"Charles Hottel" <cho...@earthlink.net> wrote in message
news:eIWdnfhBe7J48QfM...@earthlink.com...
Nov. 1991, "Dusting off COBOL" by Jim Mischel, pages 40-46. It is about a
COBOL preprocessor call CBPP that provides:
1. conditional compilation
2. limited macro expansion
3. nested COPY statements
4. in-line comments
The article says it was written and test using Turbo C v 2.0 and he tried to
make it conform to the ANSI standard. It was once available on CompuServe
in LIB1 of CLMFORUM.
I remember contacting him and he sent me the source code but right now I
cannot seem to find it. If tou google for his name you may be able to find
and contact him.
Message has been deleted
Pete Dashwood
May 20, 2013, 5:32:35 PM5/20/13
to
Patrick wrote:
> Sorry to answer my own post but what about this XML file:
>
> <?xml version="1.0"?>
>
> <project-root>
>
>
> <file-write file="output.cob">This is the file name that will be
> written
>
>
> <copy file="outer.cob">This is the outer most .cob file
>
> <copy file="nested.cob">This is inside outer.cob
>
> <copy file="nested-private.cob">This .cob file is only callable
> from it's parent nested.cob
> </copy>
>
> <copy file="another-private">This file is also only
> accessible from nested.cob and not a sibling
> </copy>
>
>
> </copy>
> </copy>
>
>
> </file-write>
> </project-root>
>
>
> Imagine all the .cob files in one messy folder but an XML document
> that outlines their use and describes how they will be copied into
> various larger .cob files, which would be the ones to be compiled.
> The XML tags could outline what files are to be copied to what files
> and the contents of the tags could just serve as comments.
I think it is a good approach but I'm not sure what COBOL we are talking
about.
I use Fujitsu NetCOBOL and PowerCOBOL (which are both native code, NOT CIL
generating compilers, and both support the full OO COBOL facilities).
They already have all of the things you are talking about, as well as
"include".
I'm fairly sure Micro Focus does too.
Are you talking about a pre-processor for Open COBOL?
(Sorry, if I seem to have lost the plot here, but let's just be clear what
this is about.)
I don't know what facilities Open COBOL has or doesn't have because I don't
use it. I don't use it because it doesn't support the Component Object
Model, which is fundamental to the business I do.
To support that model it would need to support OO, but OO support on its own
wouldn't be enough for me. Fujitsu supports OO and the COM model and so does
Micro Focus (although the Micro Focus implementation of COM in Net Express
is cumbersome and useless for any serious work with components and modules,
plus they charge run time fees...), so I use Fujitsu. (I would LOVE to be
able to use Open COBOL, but over the last few years there has been no sign
of OO or COM coming from that direction.)
I think most of the people in this forum will already be using some form of
PC COBOL from a major vendor, so it seems like you are re-inventing the
wheel for many people.
Your XML approach could apply to any version of COBOL, but it isn't needed
for Fujitsu. (I'm not sure about Micro Focus support for nested rograms, but
I'd be surprised if it isn't supported.)
But, if you intend it to be used for Open COBOL, and there is no such
existing facility, then I think you have a good idea.
> Sorry to answer my own post but what about this XML file:
>
> <?xml version="1.0"?>
>
> <project-root>
>
>
> <file-write file="output.cob">This is the file name that will be
> written
>
>
> <copy file="outer.cob">This is the outer most .cob file
>
> <copy file="nested.cob">This is inside outer.cob
>
> <copy file="nested-private.cob">This .cob file is only callable
> from it's parent nested.cob
> </copy>
>
> <copy file="another-private">This file is also only
> accessible from nested.cob and not a sibling
> </copy>
>
>
> </copy>
> </copy>
>
>
> </file-write>
> </project-root>
>
>
> Imagine all the .cob files in one messy folder but an XML document
> that outlines their use and describes how they will be copied into
> various larger .cob files, which would be the ones to be compiled.
> The XML tags could outline what files are to be copied to what files
> and the contents of the tags could just serve as comments.
I think it is a good approach but I'm not sure what COBOL we are talking
about.
I use Fujitsu NetCOBOL and PowerCOBOL (which are both native code, NOT CIL
generating compilers, and both support the full OO COBOL facilities).
They already have all of the things you are talking about, as well as
"include".
I'm fairly sure Micro Focus does too.
Are you talking about a pre-processor for Open COBOL?
(Sorry, if I seem to have lost the plot here, but let's just be clear what
this is about.)
I don't know what facilities Open COBOL has or doesn't have because I don't
use it. I don't use it because it doesn't support the Component Object
Model, which is fundamental to the business I do.
To support that model it would need to support OO, but OO support on its own
wouldn't be enough for me. Fujitsu supports OO and the COM model and so does
Micro Focus (although the Micro Focus implementation of COM in Net Express
is cumbersome and useless for any serious work with components and modules,
plus they charge run time fees...), so I use Fujitsu. (I would LOVE to be
able to use Open COBOL, but over the last few years there has been no sign
of OO or COM coming from that direction.)
I think most of the people in this forum will already be using some form of
PC COBOL from a major vendor, so it seems like you are re-inventing the
wheel for many people.
Your XML approach could apply to any version of COBOL, but it isn't needed
for Fujitsu. (I'm not sure about Micro Focus support for nested rograms, but
I'd be surprised if it isn't supported.)
But, if you intend it to be used for Open COBOL, and there is no such
existing facility, then I think you have a good idea.
Message has been deleted
Charles Hottel
May 21, 2013, 12:22:24 AM5/21/13
to
news:9973091c-54f1-4e0f...@googlegroups.com...
> Hi Charles
>
> Thanks for your posts today.
>
> I tried to find the article. I ended up here:
> http://ftp.math.utah.edu/pub/tex/bib/toc/complang.html#8%289%29:September:1991
> But I don't seem to be able to access anything beyond the bibliography
>
> Could you point me in the right direction?
I don't see anything online but the bibliography. I still have the actual
magazine and I could photocopy the article and snail mail it to you, but it
does not contain the actual source code.
You could try to contact Jim Mischel here: http://www.mischel.com/
> Hi Charles
>
> Thanks for your posts today.
>
> I tried to find the article. I ended up here:
> http://ftp.math.utah.edu/pub/tex/bib/toc/complang.html#8%289%29:September:1991
> But I don't seem to be able to access anything beyond the bibliography
>
> Could you point me in the right direction?
I don't see anything online but the bibliography. I still have the actual
magazine and I could photocopy the article and snail mail it to you, but it
does not contain the actual source code.
You could try to contact Jim Mischel here: http://www.mischel.com/
0 new messages