Re: [open-cobol-list] Improvement to screen handling.

[Patrick]

> There is an issue concerning who calls who. There
> is an extended version of Tcl/Tk called Expect,
> and a book on same on my shelf called "Exploring
> Expect". Expect calls a program and then
> exchanges information depending on the last
> message from the called program. Whether this is
> your ultimate version of Tcl/TK is of course up
> to you but that is another and interesting option.
>
> Another option:
>
> Tiny COBOL allowed the calling program to be
> COBOL and had a C language interface program to
> tcl/tk. In the tinycobol66 release look for examples
> tgui01 and tgui02 in the test.code directory.
Thanks for the tip John, tinycobol does have some good hints.

I haven't made up my mind but here is roughly what I had in mind:

I was thinking that I could rewrite both SCREEN SECTION related code and 
CALL related code. I was thinking that the compiler would generate 3 
files from foo.cob, foo.so, foo.tcl and foo-user.tcl.

The entry point would be foo.tcl. It would then load and call foo.so but 
before this it would package require foo-user.tcl, which would contain 
user written code and would not be overwritten later. this woudl be an 
entry point for Tcl code and C Tcl modules.

Tcl 8.6 has full OO. I could potentially support Cobol 2002 OO by having 
the compiler emit Tcl OO code. The SCREEN SECTION code could also be 
emitted as Tcl/Tk code, this would all end up in foo.tcl.

The Gnu Cobol code we know today would end up as C Tcl modules that 
would be called as procedures or methods.

Using Tcl/Tk would result in performance loss and intellectual property 
leakage but with statically typed procedures and methods, some of this 
could be mitigated.

I love how tightly integrated everything is with Cobol, it makes for a 
wonderful programming environment. However this is the thing I also 
dislike about it as well.

I have read that there is more Cobol code than any other language and I 
even read that there is more than all other languages combined. I don't 
know what is true but there is certainly heaps of it. However with all 
this code there are few to no libraries and there weren't really even 
suitable mechanisms for building them before 2002. Now with 2002, I am 
hoping to create something that will be able instantiate objects write 
in other languages such as Tcl or Tcl C modules.

Tcl/Tk is seriously out of fashion but it's problems are largely 
marketing now. Tk looks great on Posix. It has anti-aliased fonts and 
PNG support too. The thing I hate about Tcl is the readability. I think 
Cobol and Tcl are a match made in heaven.

Thanks again