[GNU-COBOL] Random followup to Tim's mail

["Chad Slaughter" <slaught@umr.edu>]

Hello,

This is a long email. Its not so much a reply to tim as a message to the
list in general. and me thinking out loud. Which as we all know is not
a good thing.[tm] =)

laura: There are some important things towards the end of this, go down
and read them, please.


Tim Josling wrote :>

>I have already gotten something big out of this - ExtremeProgramming. I am 
> totally
>sold and have redone all my work on COBOL so far to fit in with it. How 
> thoroughly
>do you do XP? Eg

Well, currently I would say that I am the only one that does it. But I do
encourage everyone to uses it. I am glad you  liked it.

>* Unit test cases all done before coding, nothing goes in until it passes 
> the test cases.
I am working on setting up automatic unit test and functional test runs
when ppl check stuff in to CVS>
>* Continuous refactoring
I encourage ppl to either fix any and all code  that is broke or buggy.

>* Massively parallel work. Everyone can work on any piece of code. No titles 
> like Architect/Designer (oops).

Dont confuse the fact we have "roles" with code ownership. Anyone and everyone
can fix any piece of code they want, as long as they test it and it doesnt
break anything. 
The roles help to clarify areas of responsibility.
Even in XP, certain ppl have certain roles, everyone cant do every job.
And dont think just because someone has a role you can contribute in that 
area. Its also a way to make sure that decisions get made in a timely manner
and arent argued to death. (ie design by committee) 

>Obviously some things are hard here:

>* User stories and priorities - where do they come from?

In our case user stories are kinda easy. They are simple Cobol programs
with expected inputs and outputs. Kinda makes the functional test writing
easier too. =) Also, the User stories come from the standard. Its sort of
our customer on this project.(ie what the std says goes) And where the std
doesnt answer questions we have to go to the Cobol programmer community.

>* Programming in pairs - I think most of you are near each other but even if
>geographically isolated you can do some workarounds.

This is the tough one. I wish there was better technology to allow us to
pair program over teh network..but it might be too slow to really work.
*shrugs* There are some tools, but I am not sure if they'd be any good.
So we have to relie on unit tests and maybe some informal code reviews...
but I dont like code reviews, so we might just have to wing this one.

>chance to see my work. I think I will finish the preprocessor and put that up 
> on
The preprocessor would be very cool. We only have a simple one implemented in
the phase one code. But it serves its purpose.

>the Web for you to see if you like it. At the same time if you have some 
> design
>concepts and particularly scope I am keen to hear about it. My planned scope 

I am working on writing up the design concepts for ppl to look at. =)

> for
>the preprocessor is:

>1. Handle COPY verb (with unlimited nested includes as an extension).

unlimited nesting is that legal?
*side note what shall be the short hand to mean the American Nation Standard
for Programming language COBOL ANSI X3.23-1985???* 
ANSI85 XII 2.3 (7)  says 
	A COPY statement may be specified in the source program 
	anywhere a character-string or a separator, other than
	the closing quotation mark, may occur except that a COPY 
	statement must not occur within a COPY statement.

Does this mean within the copy statement before or after its expanded?

hmmm.. I am just now reading section XII... i am thinking we might be
better off with YASU(yet another small utility) to handle just the copy 
and replace...as they have to occur prior to the other preprocessor
functions like debug and column checking, etc. hmmm
I am thinking out loud. dont mind me.

>2. Optionally Expand tabs per user specs.

As per how we did it in our first try, I'd encourage you to use
the unix util "expand" to do this instead of writing your own.

>3. Handle replace verb as per C85.

see above...

>4. Optionally handle EBCDIC to ASCII conversion and conversion of IBM 72 
> columns to
>variable format.

conversion of IBM 72 columns?? what is IBM 72 columns?

the ASCII to EBCDIC would be nice. and the reverse too. Perhaps a small 
utility ??? =)  do conversion based on executable name. =)

>5. Optionally Strip off sequence numbers
>6. Splice continuations. (not supporting X/Open & continuations at the 
> moment - is
>this important?).

yeah...we did it in the first preprocessor. its an easy layup, steal our code
if necessary. =)

>7. Optionally add extra spaces at end of lines so the full-stops are valid
>(standard insists they have a space after them).

??? sounds good. Not that I dont believe you, but I like to know
which parts of the std are covered by which code...

ok I am thinking out loud again... maybe all code should ref in the
header comment which parts of the std are relivent to what its doing??
good yes, no??

>All but 1 and 3 are going - and fully test-cased of course -  so far.

well well thats great. =)  dont sweat COPY and REPLACE just yet. 

>So the compiler will get a pretty clean and simple file (probably with #line
>directives in it like C preprocessor for better debug and listings).

*Laura read this part!* 
Ok, I dont like the idea of adding new tokens to the file.
And I dont like creating extra files..but to prevent me from going off on
my latest greatest idea(shameless stolen from others of course)
I'll just say this. I think the preprocessor might write out a file to
correspond the input source files(including copy/replace files) line numbers
with the preprocessor output/compiler input file line numbers.
Then we write a little function to do the look up on compiler errors
and print out the associated line number from this file.
good idea? bad idea? what?  might simplify the whole line numbering issues.
Then as I generate C code, I can use this function to output #line to the 
original files too.  =)

(The other idea involves use of structured storage and the software I want to
use isn't ready)

One thing which needs to be done is to correctly check the column A,B rules 
in fixed column format files. Its a bitch but it needs to be done eventually.

>My current theory is to use Flex/Bison and work around the limitations as they
>arise. I may have this very wrong.

Well we did the first preprocessor with flex and a little C, no problem.
The copy/replace and the A,B fixed format checking might need bison..but
the rest shouldn't.

>I am also interested in how we can achieve the 'bazaar' model of 
> development - ie

I think we can do this by practicing XP. =)

>avoiding bottlenecks - how do you partition a compiler.

good question. We've been fighting over this for awhile. 
The main systems as I see them are preprocessor, parser,code 
generator, runtime system. Each of these is rather large and has many pieces
how well we can break this up is another question. 

>Have you had a look at the Cobol 95 draft - lots of changes!

*twitch* No, and I'd rather not. =) at least not yet.


Chad

-- 
Chad Slaughter  -- slaught at umr.edu
<PGP public key available upon request>

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to gnu-cobol@acm.cs.umr.edu with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@acm.cs.umr.edu.