(Long) Re: Autocoding project proposal.

[David Masterson]

>>>>> Timothy Rue writes:

> On 04-Feb-02 12:59:12 David Masterson <dmaster at synopsys.com> wrote:

>> Your (extended) program appears to be no better than the previous
>> one I looked at in that it doesn't appear to do anything useful.
>> My memory of AREXX is ~10 years old, so some things in your program
>> are not obvious (like the PARSE command).  Overall, though, it
>> appears to merely do some convoluted printouts that I can't make
>> heads or tails of.

> Programming one step at a time. This step is just the main parser.

> Certainly a Software engineer such as yourself knows this to such a
> degree that it's obvious to you. And as far as arexx goes....well
> Like I said, it doesn't go thru the complete framework, But it
> doesn't mean there is not a framework spelled out in english.

Of course I can recognize this as a (simple) parser.  That much was
obvious sometime back.  A simple Lex/YACC program what I saw there.

What is not obvious is what all the variations of the "expected" input
for the parser will be, what the program is supposed to do with the
parsed input, and what the "expected" output of the program
(ie. V.I.C.) is supposed to be for a given input.

> We both know it can be done, and in more than one way. At this stage of
> development, that is all that is needed. Once the tool is built then we
> can focus on getting the tool to output what we want from the input we
> provide it with.

Given a clear definition of the three key things required in
programming (input, program, output), we can give you lots of
different ideas in lots of different computer languages on how to
create the program.

> In either case, more information is needed and that's what we work on
> after the tool is created. 

That is putting the cart in front of the horse.  We cannot create a
tool to solve a problem until we know what the problem is.

> There is only the creation of a configuration of very common code
> functionality, carried out to it's natural conclusion in support of
> versatility.

That has already been done.  It's been done over and over for the last
50 years of computer programming.  Without a clear definition of what
you mean by "common code functionality" to differentiate your approach
versus what's already out there, I see nothing worthwhile in your
project.

> The parse framework is the place to start in creating the whole
> VIC. And at some point we will be able to integrate What was done in
> the standalone IQ program. The PK multi-deminsional array is the
> main data collection that gets manipulated.

> Handle the parse routine and then fill in one by one that functions the
> parse routine points to given selected input.

Again, this is putting the cart before the horse.

> A great deal of thought has gone into this already, alot more has been
> thoughtout and defined than this parse routine framework. Enough to know
> doing the parse routine is no waste of effort, but something that needs to
> be done.

Unproven statement...

> <shrug>

<quizzocal look>

-- 
David Masterson                dmaster AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA