gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Charles Anthony
Subject: Re: [open-cobol-list] Daydreaming about another language to emit
Date: Fri, 4 Oct 2013 08:03:19 -0700

 > I am just THINKING, keyword... thinking" about what other languages might be better then C for intermediate generation.

You want LLVM: llvm.org


On Thu, Oct 3, 2013 at 8:31 PM, Patrick <address@hidden> wrote:
Hi Everyone

I hope this email won't upset anyone. I am just THINKING, keyword...
"thinking" about what other languages might be better then C for
intermediate generation. I am not saying that we have to change
anything, I was just hoping to have a theoretical chat.

We have 4 main dependencies:
ncurses
libtool
GMP
BDB

I would really like to get rid of Berkeley DB due to the licensing
issues it brings to the project but aside from openLDAP I have not come
up with anything. I also don't really understand the parts it's used in,
not understanding, it makes it hard to come up with logical alternatives.

However something I have been researching a little is if there was
another language that the code generator could emit rather then C, it
might really simplify libcob.

For instance libcob has a function stack. I don't yet know how it works
but I am assuming it's passing pointers to functions around. This is
necessary because C does not support nested functions. However several
other languages do natively, I consider these to be possible matches:

Free Pascal
Ada
D

These do as well but they have enormous runtimes and/or limitations such
as speed or nesting levels:
Fortran(1 level only)
Functional languages, such as Erlang and Scala
Dynamic languages such as Lua


C is so important, if we didn't use C itself it would have to be
something that interfaces well with it. I really love Ada but it's quite
painful to write bindings for it and there are few bindings available,
although there is already an ncurses one.

Free Pascal has a lot more bindings and quite an active community. Free
pascal is good to 18 decimal places( I imagine Ada is similar but I will
have to double check), at 18 decimal places is there a reason to use GMP
? Would this eliminate a dependency?

Ada's GNAT is pretty painful to use. gnatmake is a nice command that
calls other stages and you can compile large pure Ada projects with just
the one command but as soon as you start mixing languages the pain goes
up quickly.

It looks like FPC is simple for pure pascal projects but it may also be
painful with mixed programming, I don't have enough experience under my
belt yet to say for sure. h2pas is a binding program that helps bring in
C to Pascal. It appears to work by reading header files and I think it
may work on just the file's text without the need to compile. Ada has
gcc --fdump-ada-spec but the auto-generated binding can only be produced
if the application can be compiled on the computer with GCC. Sometimes
it might be nice to write bindings for programs just retrieved from the
repos, along with their header.

Free pascal already has a ncurses binding.

I don't know enough about D. I don't know if it's easy to bind to C or
if GMP would still be needed. I found a beta ncurses D binding but
that's it, not so great.

So after all this, you might be asking "why are you even considering this".

In my last post I mentioned that I have to get a project started and I
have to do it in C++ ? Well I just can't bring myself to do it and I
have already abandoned this. I really love Cobol so much. I can't even
get away from it when it would probably be logical to do some things in
another language.

I love it so much but one thing it is really missing is a way to bring
in libraries in a native way. We don't have enough libraries for general
purpose programming. I need ways to visualize data, use sockets and much
more.

Once a good binding is written for python, ruby, lua etc, the C code is
programmed into the programming model of the language, it just feels
natural.

Using CALL is fine but over and over again, it just doesn't feel
integrated. I am daydreaming about how to make the compiler approachable
and modifiable. It looks like the only way we could create native
feeling bindings in Cobol is to build them right into the language with
optional build flags and right now it's pretty daunting tinkering with
anything, with so much C.

I have made a lot of progress with C over the past year or so but it's
the trickiest little language and much more complex that supposedly
larger ones.

I love Cobol's readability and I hate C's lack of it. Auto generated
Pascal, Ada or D might be so much easier to read the auto-generated C
and not having to add missing features to C would simplify libcob. The
compiler would still be challenging  but I have some ideas of how this
could be changed too. I will report back, one day, with more daydreaming
ideas about.

I really wish I could contribute to the project, I still can't really
yet but I might have been able to by now if C was not in the way-Patrick


















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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]