While we're waiting for someone to synthesize a coherent essay on the topic above, here's valuable reading to warm us all up to the topic:

• Combining FORTRAN and Tcl in one program - Arjen Markus promises to make this page!
• Critcl
• Expect for Windows--or maybe just Expect
• FORTRAN
• Keep a GUI alive during a long calculation [advanced topic]
• Managing FORTRAN programs
• FORTRAN via open pipe
• GUI for an existing program
• exec and related essays
• [tutorials]
• [... much more ...]

[Sort the order of the stuff above.]

---

Why privilege FORTRAN? That is, why wouldn't this have been a better page, titled "... on interacting with applications written in other languages ..." or "... how to write Tcl/Tk applications with external programs that request character-based interaction"?

It's a good question. First, if someone writes such a page, I'm one contributor who'll happily factor out common elements, and refer to them there.

For me, FORTRAN does deserve special attention, for several reasons:

• While the technology of "gluing" together C and Tcl, or FORTRAN and Tcl, is largely identical, C programmers seem to expect its feasibility, while FORTRANners think everything will be hard. FORTRAN programmers appear to respond disproportionately better to, "this is how to do it in FORTRAN" than, "this is how to do it in C, and translate it in the obvious way for FORTRAN". Think of this as "outreach".
• I believe a far larger percentage of all interesting FORTRAN programs are GUIless "console" applications, than is the case with C. C programmers generally have plenty of opinions about how to connect a GUI. FORTRAN programmers are singularly grateful for the realization that they, too, can join the GUI game, in particular with Tk's ease.
• FORTRAN programmers are also different in that so many of them do not characterize themselves as programmers. They're engineers, scientists, and so on, and they just want results. They have little patience with the esoterica of syntax arguments. If stuff works, they're happy.
• Related to these other differences, FORTRAN programmers appear particularly disposed not to see their applications as "external programs". Their stuff is at the center, and we need to explain architectural realities in language they can better explain.
• ...

For all these reasons, CL regards it as advantageous to address FORTRANners specifically.

---

I don't think it's so much giving FORTRAN a privilege, it's a question of getting FORTRAN in the title, so the page comes up in a search for FORTRAN.

---

Who chose this super long title? It's much too long for referencing it in a pleasing manner. Michael Schlenker

I committed it, Michael--I'm Cameron. I thought it would work out well. I must not be seeing it the same way. Hmmmm; I'm not sure what to do now, except to have you help convince me to style things differently in the future.

LV Well, one can always refer to the number of the page, to get a shorter though non-descript, title,

---

[RickE] - 2012-11-02 11:05:40

I have some FreePascal (effectively C) serial port programs I'm trying to interface to Tk. The TCL/TCLX pipe interface (including the new "chan" command) is suspicious so I thought an Expect pseudoterminal would work. The FreePascal programs set up listeners for serial port interrupts using child process pipes, so I understand pipes. I have a nice Tk Gui. All I want is to link the TCL with the FreePascal interactively, reliably. I've tried reading the Expect book. Have a good TCL library. Details are obscure.

---