* [TUHS] struct(1) revived! And a request for help
@ 2022-01-12 12:58 arnold
2022-01-13 4:23 ` [TUHS] Fwd: " Douglas McIlroy
2022-01-13 22:21 ` [TUHS] " Skip Tavakkolian
0 siblings, 2 replies; 5+ messages in thread
From: arnold @ 2022-01-12 12:58 UTC (permalink / raw)
To: tuhs
Hello All.
We recently discussed Brenda Baker's struct program, that read Fortran
and generated Ratfor. Many of us remarked as to what a really cool
program it was and how much we admired it, myself included.
For fun (for some definition of "fun") I decided to try to bring the code
into the present. I set up a GitHub repo with the V7, V8 and V10 code,
and then started work in a separate branch.
(https://github.com/arnoldrobbins/struct, branch "modernize".)
The program has three main parts:
- structure, which reads Fortran and outputs something that is
almost Ratfor on standard output.
- beautify, which reads the output of structure and finishes the job,
primarily making conditions readable (.not. --> !, removing double
negatives, etc.)
- struct.sh - a simple shell script that runs the above two components.
This is what the user invokes.
The code was written in 1974. As such, it is rife with "type punning"
between int, int *, int **, and char *. These produce a lot of warnings
from a modern day C compiler. The code also uses a, er, "unique" bracing
style, making it nearly illegible to my stuck-in-a-rut programming brain.
Here is what I've accomplished so far:
* Converted every function definition and declaration to use modern (ANSI)
C style, adding a header file with function declarations that is
included everywhere.
* Run all the code through the indent program, formatting it as traditional
K&R bracing style, with tabs.
* Fixed some macros to use modern style for getting parameter values as strings
into the macros.
* Fixed a few small bugs here and there.
* Fixed beautify to work with modern byacc/bison (%union) and to work with
flex instead of lex. This latter was a challenge.
In structure, only three files still generate warnings, but they all relate
to integer <--> pointer assignment / use as. However, when compiled in
32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer),
despite the warnings, structure works!!
Beautify works, whether compiled in 32 or 64 bit mode.
What I've done so far has been mostly mechanical. I hereby request help from
anyone who's interested in making progress on "the hard part" --- those three
files that still generate warnings.
I think the right way to go is to replace int's with a union that holds and
int, a char* and an int*. But I have not had the quiet time to dive into
the code to see if this can be done.
Anyone who has some time to devote to this and is interested, please drop
me a note off-list.
Thanks,
Arnold Robbins
^ permalink raw reply [flat|nested] 5+ messages in thread
* [TUHS] Fwd: struct(1) revived! And a request for help
2022-01-12 12:58 [TUHS] struct(1) revived! And a request for help arnold
@ 2022-01-13 4:23 ` Douglas McIlroy
2022-01-13 6:30 ` [TUHS] " Rich Morin
2022-01-13 15:19 ` [TUHS] Fwd: " arnold
2022-01-13 22:21 ` [TUHS] " Skip Tavakkolian
1 sibling, 2 replies; 5+ messages in thread
From: Douglas McIlroy @ 2022-01-13 4:23 UTC (permalink / raw)
To: TUHS main list; +Cc: Brenda Baker
Arnold,
I'm very glad you have revived struct. It is an important historical
artifact, and it's nice to have it freed from distracting obsolete
usage.
To my mind, struct ranks among the top accomplishments of our
department at Bell Labs. It was also a lesson in humility to me.
When Brenda proposed struct, it was obvious that it could be built,
but I advised against doing so. I thought it would take an endless
pile of special cases to generate respectable Ratfor. She demurred,
saying that she thought she could do better than that. And she was
right. She produced not only working Ratfor programs, but a
canonical-form theorem that distinguished those programs from all the
ad hoc alternatives I had imagined. The value of the theorem was
attested by users' reports that the derived Ratfort was easier to
understand than the Fortran they had written themselves.
Doug
---------- Forwarded message ---------
From: <arnold@skeeve.com>
Date: Wed, Jan 12, 2022 at 7:58 AM
Subject: [TUHS] struct(1) revived! And a request for help
To: <tuhs@tuhs.org>
Hello All.
We recently discussed Brenda Baker's struct program, that read Fortran
and generated Ratfor. Many of us remarked as to what a really cool
program it was and how much we admired it, myself included.
For fun (for some definition of "fun") I decided to try to bring the code
into the present. I set up a GitHub repo with the V7, V8 and V10 code,
and then started work in a separate branch.
(https://github.com/arnoldrobbins/struct, branch "modernize".)
The program has three main parts:
- structure, which reads Fortran and outputs something that is
almost Ratfor on standard output.
- beautify, which reads the output of structure and finishes the job,
primarily making conditions readable (.not. --> !, removing double
negatives, etc.)
- struct.sh - a simple shell script that runs the above two components.
This is what the user invokes.
The code was written in 1974. As such, it is rife with "type punning"
between int, int *, int **, and char *. These produce a lot of warnings
from a modern day C compiler. The code also uses a, er, "unique" bracing
style, making it nearly illegible to my stuck-in-a-rut programming brain.
Here is what I've accomplished so far:
* Converted every function definition and declaration to use modern (ANSI)
C style, adding a header file with function declarations that is
included everywhere.
* Run all the code through the indent program, formatting it as traditional
K&R bracing style, with tabs.
* Fixed some macros to use modern style for getting parameter values as strings
into the macros.
* Fixed a few small bugs here and there.
* Fixed beautify to work with modern byacc/bison (%union) and to work with
flex instead of lex. This latter was a challenge.
In structure, only three files still generate warnings, but they all relate
to integer <--> pointer assignment / use as. However, when compiled in
32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer),
despite the warnings, structure works!!
Beautify works, whether compiled in 32 or 64 bit mode.
What I've done so far has been mostly mechanical. I hereby request help from
anyone who's interested in making progress on "the hard part" --- those three
files that still generate warnings.
I think the right way to go is to replace int's with a union that holds and
int, a char* and an int*. But I have not had the quiet time to dive into
the code to see if this can be done.
Anyone who has some time to devote to this and is interested, please drop
me a note off-list.
Thanks,
Arnold Robbins
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [TUHS] struct(1) revived! And a request for help
2022-01-13 4:23 ` [TUHS] Fwd: " Douglas McIlroy
@ 2022-01-13 6:30 ` Rich Morin
2022-01-13 15:19 ` [TUHS] Fwd: " arnold
1 sibling, 0 replies; 5+ messages in thread
From: Rich Morin @ 2022-01-13 6:30 UTC (permalink / raw)
To: TUHS main list
> On Jan 12, 2022, at 20:23, Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>
> ... users' reports that the derived Ratfort was easier to
> understand than the Fortran they had written themselves.
In the late 70's, I started working on some Fortran code for an astrophysicist. The code was written in Fortran II and I found it very difficult to read. So, I turned it into VAX VMS Fortran 77 (not Ratfor, but a lot closer to it :-).
The scientist was _not_ happy, saying that he would no longer be able to read his code. I informed him that (a) Fortran 77 was the current standard and (b) he was welcome to go back to his Fortran II version, but that he'd have to do so without my assistance. He grumbled a bit, but acquiesced...
-r
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [TUHS] Fwd: struct(1) revived! And a request for help
2022-01-13 4:23 ` [TUHS] Fwd: " Douglas McIlroy
2022-01-13 6:30 ` [TUHS] " Rich Morin
@ 2022-01-13 15:19 ` arnold
1 sibling, 0 replies; 5+ messages in thread
From: arnold @ 2022-01-13 15:19 UTC (permalink / raw)
To: tuhs, douglas.mcilroy; +Cc: brendasuebaker
Thanks Doug.
Let's hope it can be brought all the way into 64 bit mode.
Dr. Baker has been brought into the loop, so I am hopeful. :-)
Arnold
Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
> Arnold,
>
> I'm very glad you have revived struct. It is an important historical
> artifact, and it's nice to have it freed from distracting obsolete
> usage.
>
> To my mind, struct ranks among the top accomplishments of our
> department at Bell Labs. It was also a lesson in humility to me.
>
> When Brenda proposed struct, it was obvious that it could be built,
> but I advised against doing so. I thought it would take an endless
> pile of special cases to generate respectable Ratfor. She demurred,
> saying that she thought she could do better than that. And she was
> right. She produced not only working Ratfor programs, but a
> canonical-form theorem that distinguished those programs from all the
> ad hoc alternatives I had imagined. The value of the theorem was
> attested by users' reports that the derived Ratfort was easier to
> understand than the Fortran they had written themselves.
>
> Doug
>
> ---------- Forwarded message ---------
> From: <arnold@skeeve.com>
> Date: Wed, Jan 12, 2022 at 7:58 AM
> Subject: [TUHS] struct(1) revived! And a request for help
> To: <tuhs@tuhs.org>
>
>
> Hello All.
>
> We recently discussed Brenda Baker's struct program, that read Fortran
> and generated Ratfor. Many of us remarked as to what a really cool
> program it was and how much we admired it, myself included.
>
> For fun (for some definition of "fun") I decided to try to bring the code
> into the present. I set up a GitHub repo with the V7, V8 and V10 code,
> and then started work in a separate branch.
>
> (https://github.com/arnoldrobbins/struct, branch "modernize".)
>
> The program has three main parts:
>
> - structure, which reads Fortran and outputs something that is
> almost Ratfor on standard output.
>
> - beautify, which reads the output of structure and finishes the job,
> primarily making conditions readable (.not. --> !, removing double
> negatives, etc.)
>
> - struct.sh - a simple shell script that runs the above two components.
> This is what the user invokes.
>
> The code was written in 1974. As such, it is rife with "type punning"
> between int, int *, int **, and char *. These produce a lot of warnings
> from a modern day C compiler. The code also uses a, er, "unique" bracing
> style, making it nearly illegible to my stuck-in-a-rut programming brain.
>
> Here is what I've accomplished so far:
>
> * Converted every function definition and declaration to use modern (ANSI)
> C style, adding a header file with function declarations that is
> included everywhere.
>
> * Run all the code through the indent program, formatting it as traditional
> K&R bracing style, with tabs.
>
> * Fixed some macros to use modern style for getting parameter values as strings
> into the macros.
>
> * Fixed a few small bugs here and there.
>
> * Fixed beautify to work with modern byacc/bison (%union) and to work with
> flex instead of lex. This latter was a challenge.
>
> In structure, only three files still generate warnings, but they all relate
> to integer <--> pointer assignment / use as. However, when compiled in
> 32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer),
> despite the warnings, structure works!!
>
> Beautify works, whether compiled in 32 or 64 bit mode.
>
> What I've done so far has been mostly mechanical. I hereby request help from
> anyone who's interested in making progress on "the hard part" --- those three
> files that still generate warnings.
>
> I think the right way to go is to replace int's with a union that holds and
> int, a char* and an int*. But I have not had the quiet time to dive into
> the code to see if this can be done.
>
> Anyone who has some time to devote to this and is interested, please drop
> me a note off-list.
>
> Thanks,
>
> Arnold Robbins
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [TUHS] struct(1) revived! And a request for help
2022-01-12 12:58 [TUHS] struct(1) revived! And a request for help arnold
2022-01-13 4:23 ` [TUHS] Fwd: " Douglas McIlroy
@ 2022-01-13 22:21 ` Skip Tavakkolian
1 sibling, 0 replies; 5+ messages in thread
From: Skip Tavakkolian @ 2022-01-13 22:21 UTC (permalink / raw)
To: arnold; +Cc: tuhs
On Wed, Jan 12, 2022 at 4:59 AM <arnold@skeeve.com> wrote:
>
> Hello All.
>
> We recently discussed Brenda Baker's struct program, that read Fortran
> and generated Ratfor. Many of us remarked as to what a really cool
> program it was and how much we admired it, myself included.
>
> For fun (for some definition of "fun") I decided to try to bring the code
> into the present. I set up a GitHub repo with the V7, V8 and V10 code,
> and then started work in a separate branch.
>
> (https://github.com/arnoldrobbins/struct, branch "modernize".)
>
> The program has three main parts:
>
> - structure, which reads Fortran and outputs something that is
> almost Ratfor on standard output.
>
> - beautify, which reads the output of structure and finishes the job,
> primarily making conditions readable (.not. --> !, removing double
> negatives, etc.)
>
> - struct.sh - a simple shell script that runs the above two components.
> This is what the user invokes.
>
> The code was written in 1974. As such, it is rife with "type punning"
> between int, int *, int **, and char *. These produce a lot of warnings
> from a modern day C compiler. The code also uses a, er, "unique" bracing
> style, making it nearly illegible to my stuck-in-a-rut programming brain.
That is the same style that P.J. Plauger/Whitesmiths used in Idris OS. The brace
indentation levels also match the Ratfor code in Software Tools.
>
> Here is what I've accomplished so far:
>
> * Converted every function definition and declaration to use modern (ANSI)
> C style, adding a header file with function declarations that is
> included everywhere.
>
> * Run all the code through the indent program, formatting it as traditional
> K&R bracing style, with tabs.
>
> * Fixed some macros to use modern style for getting parameter values as strings
> into the macros.
>
> * Fixed a few small bugs here and there.
>
> * Fixed beautify to work with modern byacc/bison (%union) and to work with
> flex instead of lex. This latter was a challenge.
>
> In structure, only three files still generate warnings, but they all relate
> to integer <--> pointer assignment / use as. However, when compiled in
> 32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer),
> despite the warnings, structure works!!
>
> Beautify works, whether compiled in 32 or 64 bit mode.
>
> What I've done so far has been mostly mechanical. I hereby request help from
> anyone who's interested in making progress on "the hard part" --- those three
> files that still generate warnings.
>
> I think the right way to go is to replace int's with a union that holds and
> int, a char* and an int*. But I have not had the quiet time to dive into
> the code to see if this can be done.
>
> Anyone who has some time to devote to this and is interested, please drop
> me a note off-list.
>
> Thanks,
>
> Arnold Robbins
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-01-13 22:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-12 12:58 [TUHS] struct(1) revived! And a request for help arnold
2022-01-13 4:23 ` [TUHS] Fwd: " Douglas McIlroy
2022-01-13 6:30 ` [TUHS] " Rich Morin
2022-01-13 15:19 ` [TUHS] Fwd: " arnold
2022-01-13 22:21 ` [TUHS] " Skip Tavakkolian
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).