SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Thu, 22 Apr 2004 11:13:35 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Onward software soldiers

Content Type: text/plain

"...Your output, whether discrete statements or specifications,
is lacking
in all of the creative thought which went into the software.
You've lost any "why I used QuickSort instead of
Shell-Metzner" comments or insights. It's like going down to
the adult store and buying a life-size inflatable doll. It looks
about right, but there's something _missing_ here. ..."

Peter,

You realise you've just made my point while raising an
inconsequential one. While creative thinking may go into the
writing of an application none exists within the source itself
unless it exists within comments or some external
documentation. Regardless it has no effect on the proper and
accurate translation of an executable into source code.

If you paid attention to my many discussions about the
Developer's Assistant (DA), the only software tool and user
interface involved, you know it provides an interactive
environment. You also know that you only write or rewrite
specifications based on "feedback" from the DA. Thus it
supports an iterative approach to problem resolution, i.e. a
viable (and accurate) solution.

In practical terms if the translation produces "identical"
results, then it "works". It does what it is supposed to do
regardless of whatever creative thought went into the
orginal. You now have the opportunity to re-introduce or
carry on the same or higher (in my case) creative thinking.

"...As for PL/E, the syntactically closest open source compiler I
can think of is Ada. Do you think the PL/E tool development
effort should start from scratch, or do you think it should
modify an existing tool?"

Apparently we have a failure to communicate here. We don't
need an open source compiler in order to create one. We can
in fact use PL/I, which is far closer to PL/E than ADA, to
create an open source PL/E, i.e. SL/I. I outlined the approach
when I described my efforts underway to write a LPEX
equivalent as a PM application using PL/I. Bob Blair has
expressed an interest in writing the data repository/directory
component as it supports his firm belief in "literate
programming". I have at least one other volunteer to take the
LPEX equivalent with its colorized syntax analysis to the next
step of semantic analysis and then to the proof process. The
proof process includes the global source organization along
with the code generation.

Now along the way we ought to have some reassurance that
it will all work as prescribed. One stickler, about which
neither you nor I have any doubts, lies in the ability to
produce HLL source from symbolic assembly resulting from
disassembly of an executable. We might in fact consider
writing such a disassembler in PL/I that creates PL/E
machine-dependent specifications that we can then translate
into machine-independent PL/I specifications.

That means that we have a process for decomposing an
executable into its data and program segments replete with
addressability between them. Then we need a process to
decompose the data and program segments into their
individual data types and instructions respectively. Then we
need to decompose the instructions into a set of sequences as
defined by the control flow dictated by the instructions
offering a non-NSI (Next Sequential Instruction) option. These
sequences will determine the control structure type
(sequence, iteration, decision) involved. These essentially set
the source skeleton which we then will flesh out through the
pure NSI instructions.

The question remains how best to present this process to the
Programming SIG. We need to understand the context of an
executable, how to determine its data and program segments.
We need to understand the architecture as reflected in the
instruction set. We need to provide a mapping between the
symbolic form of the instruction set and its equivalent PL/E
source. Then we need to show the process of going from a
machine-dependent HLL to a machine-independent one within
the same HLL.

Taking these steps along their understanding and acceptance
by Programming SIG participants should go a long way toward
assuring the viability of the entire project.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 22 | April | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.