Re: [open-cobol-list] Daydreaming about another language to emit

[Patrick]

Hi David !

I borrowed a C# book from the library last night. I want to learn C# but 
the real goal is to help me shore up my Vala. Vala and C# are so similar 
that it might not be so hard to create a code generator that emitted 
both C# and Vala.

If we are joining GNU this would provide an alternative to mono. it 
would be a bit weird to emit Vala though, as it in turn emits C but at 
least it would not have political issues.

I also borrowed a Java book.

I had to register at a site last night to access a Cobol to Java pdf 
that might have clues on how to emit Java. Now some sales person will be 
all over me on Monday.

I have uploaded it here so that others can avoid the fly-on-poo experience:

http://spellingbeewinnars.org/BPHX_Whitepaper-COBOL-to-Java-or-C-Automated-Translation.pdf

I haven't read it all yet but I see some problems already on how they 
represent level 88 fields.

C# appears to have a string method PadRight(), so 
somestring.PadRight(40) will add 37 spaces to "foo" after the final "o".

This might eliminate the need for memset and perhaps cobfield.

Javascript and Lua are so formless but they have tools built in for OO 
and many other constructs. It might be neat to have a structured, easy 
to read language act as a front end for them. I was just tinkering with 
100 lines of Lua two nights ago and I was already losing track of it. 
Perhaps if this was ever to come-to-be, it could be designed in a 
modular way so that emissions were optional and people could just work 
on the languages they wanted to emit without getting tied up in the 
details of the rest of the project.

-Patrick








On 10/06/2013 07:36 AM, David L Lambert wrote:
> Don't be so sure about that... "goto" is a reserved keyword in Java
> (causes a compilation error if you try to use it as an identifier, but
> has no other purpose in the current language grammar).
>
> Seriously, I think there would be interest in an open-source COBOL
> implementation that generated at least one of the following:
>
> * Java code or bytecode, using JDBC (with system properties to
> configure) as the persistent record store
> * .NET (C# or VB or raw CIL)
> * JavaScript (like GWT), perhaps use HTML5 local storage as one
> persistent record store, AJAX calls according to some simple pattern as
> another
>
>
> On 10/05/2013 11:46 AM, Sergey Kashyrin wrote:
> > :-)
> >
> > Java will never make COBOL people happy :-)
> > It does not have GO TO statement !
> >
> > Cheers,
> > SK
> >
> > On 10/5/2013 11:14 AM, Brian Tiffin wrote:
> >     
> > > I'll just pipe up a little.
> > >
> > > Patrick; because of Sergey's C++ emit implementation, it'll be pretty
> > > easy now to figure out how to emit other code.  Java might make some
> > > people happy.
> > >
> > > I'm actually amazed how readable GNU Cobol machine generated C is.
> > > Beats Vala and Algol68g (two other C emit systems) hands down.
> > >
> > > Charles;   LLVM.  We do clang.  Build compiler with clang, generated
> > > code compiled with clang.  All worked first try.  One small compiler
> > > switch change meant ALL the make check passes as well.
> > > http://opencobol.add1tocobol.com/#does-opencobol-work-with-llvm
> > >
> > > When we implement --with-guile as a ./configure option I'd like to
> > > implement the internals with EXEC GUILE
> > > ...
> > > END-EXEC
> > >
> > > (we have ocesql for 'code method' scaffolding now, so yayys)
> > >
> > > Once that is in place, along with having Guiles' LISP and ECMAScript
> > > (and bf, but I doubt an auditor would appreciate decoding bf in a
> > > financial application) we'll have a framework to implement just about
> > > any
> > >
> > > EXEC engine ... END-EXEC
> > >
> > > paragraphs that we can imagine.
> > >
> > > Patrick; keep thinking along these lines.  There may well be a GNU
> > > Cobol ->  Node.js emitter someday.  But for the now, C and C++ are
> > > options, and once FUNCTION-ID is ubiquitous, a lot of need for CALL
> > > can be removed as well.
> > >
> > > Things like
> > >
> > > MOVE FUNCTION PASCAL-SUB(args) TO COBOL-VAR
> > >
> > > is just over the horizon.
> > >
> > > And I'll ditto VBISAM. I'd like to pester Trevor to see if he'd be up
> > > for GNU-ification  of VBISAM, and then let it loose on the world as
> > > well, released along with GNU Cobol source tree.
> > >
> > > Cheers,
> > > Brian
> > >
> > > On 10/4/13, Sergey Kashyrin<address@hidden>  wrote:
> > >       
> > > > VBISAM
> > > >
> > > > We just need a people who can fix some locking issues on unix.
> > > >
> > > > Cheers,
> > > > SK
> > > >
> > > > On 10/4/2013 10:46 PM, Michael Potter wrote:
> > > >         
> > > > > I think getting rid of BDB is a great idea.
> > > > >
> > > > > It would make OpenCOBOL more commercially viable to implement this
> > > > > interface:
> > > > > http://supportline.microfocus.com/documentation/books/sx20books/fhexfh.htm
> > > > >
> > > > > Microfocus allows their users to replace their file handler by
> > > > > implementing to that specification.
> > > > >
> > > > > Fujitsu and COBOL-IT implemented the same interface for the compilers
> > > > > they sell.
> > > > >
> > > > > My implementing that interface, it would make it easier for people to
> > > > > port from those compilers to OpenCOBOL.
> > > > >
> > > > > I have implemented a couple of file handlers that "plug in" to
> > > > > microfocus.  Their system works well.
> > > > >
> > > > > Note: I am giving credit to microfocus for inventing this interface,
> > > > > but I have the feeling it was invented somewhere else.
> > > > >
> > > > > The implementation would go something like this:
> > > > > 1) Implement EXTFH interface in OpenCOBOL.
> > > > > 2) Implement EXTFH wrapping BDB.
> > > > >
> > > > > as this point existing user could continue to use the BDB data, but
> > > > > have the flexibility to add new EXTFH that access data in other backends.
> > > > >
> > > > > I had one of my programmers replace BDB in OpenCOBOL so I could be
> > > > > compatible with MicroFocus as part of my OpenKicks framework.  It
> > > > > would make a good starting point for this effort.  We basically wrote
> > > > > a library with same interface as BDB and linked it into OpenCOBOL.
> > > > >     Don't get your hopes up that it will be very useful for this effort.
> > > > >
> > > > > I will look into making that open source so you can use it in
> > > > > OpenCOBOL, much like I open sourced EZASOKET
> > > > > http://code.google.com/p/ezasoket/.
> > > > >
> > > > >
> > > > > On Fri, Oct 4, 2013 at 5:15 PM, Patrick
> > > > > <address@hidden
> > > > > <mailto:address@hidden>>  wrote:
> > > > >
> > > > >        On 10/04/2013 04:31 PM, Michael Anderson wrote:
> > > > >        >  On 10/04/2013 02:42 PM, Patrick wrote:
> > > > >        >>  I did say that I was just hoping to have a theoretical chat and
> > > > >        that I
> > > > >        >>  was not saying we had to change anything. Calling my comments
> > > > >        >>  ridiculous isn't very chatty
> > > > >        >  Sorry Patrick, I am often hurtfull in my choice of words, I
> > > > >        didn't mean
> > > > >        >  to ofend you, or anyone.
> > > > >        >  But you're a are right, it does not enable a good theoretical chat.
> > > > >        >  I'll try to choose better words in the future.
> > > > >        >
> > > > >        >  --
> > > > >        >  Mike.
> > > > >        >  We are all sharing this planet together, we should all try
> > > > >        harder to get
> > > > >        >  along.
> > > > >        >
> > > > >        Hi Mike
> > > > >
> > > > >        Not to worry.
> > > > >
> > > > >        I keep doing this over and over again, I have to learn.
> > > > >
> > > > >        I don't have any friends, co-workers or family that I can talk about
> > > > >        programming with.
> > > > >
> > > > >        I bet I have posted to more then 40 different mailing lists over the
> > > > >        past 7 years.
> > > > >
> > > > >        Every time I just want to just chat things go bad. I guess mailing
> > > > >        lists
> > > > >        are for black&  white, "how is this done" sort of questions and
> > > > >        not just
> > > > >        friendly coffee time like chatter.
> > > > >
> > > > >        Have a great day !
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------------------
> > > > >        October Webinars: Code for Performance
> > > > >        Free Intel webinars can help you accelerate application performance.
> > > > >        Explore tips for MPI, OpenMP, advanced profiling, and more. Get
> > > > >        the most from
> > > > >        the latest Intel processors and coprocessors. See abstracts and
> > > > >        register>
> > > > >
> > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > > > >        _______________________________________________
> > > > >        open-cobol-list mailing list
> > > > >        address@hidden
> > > > >        <mailto:address@hidden>
> > > > >        https://lists.sourceforge.net/lists/listinfo/open-cobol-list
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Michael Potter
> > > > >      Tapp Solutions, LLC
> > > > >      Replatform Technologies, LLC
> > > > > +1 770 815 6142  ** Atlanta ** address@hidden
> > > > > <mailto:address@hidden>   ** www.linkedin.com/in/michaelpotter
> > > > > <http://www.linkedin.com/in/michaelpotter>
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------------------
> > > > > October Webinars: Code for Performance
> > > > > Free Intel webinars can help you accelerate application performance.
> > > > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > > > > from
> > > > > the latest Intel processors and coprocessors. See abstracts and register
> > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > open-cobol-list mailing list
> > > > > address@hidden
> > > > > https://lists.sourceforge.net/lists/listinfo/open-cobol-list
> > > > >           
> > > >         
> > ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> > the latest Intel processors and coprocessors. See abstracts and register>
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > _______________________________________________
> > open-cobol-list mailing list
> > address@hidden
> > https://lists.sourceforge.net/lists/listinfo/open-cobol-list
> >