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

[Brian Tiffin]

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
>
>