Re: [GNU-COBOL] GNU-COBOL design concepts: zPROCs and TLP

[Randall Bart <Barticus@att.net>]

At 12:02 AM 10/28/99 , RKRayhawk@aol.com wrote:

>So, staring at this, ... there will be a lexer, a parser, a symbol table
>(SYMT), and a first intermediate form (FIF). That much implies a
>FIF-processor that inputs the FIF and outputs either other intermediates or
>the GCC code.
>
>There is certainly also a preprocessor and an error processor.

I agree with you except for the term FIF.  If Tim's preprocessor produces 
the zeroth intermediate form, there still could be more intermediates 
before your FIF.  It could be the forth or fifth intermediate form.

Traditionally, Cobol is parsed with hand written parsers that have been 
built by trial and error.  The parsers built with modern tools need to do a 
lot of fix up work, to the extent that many say it's better the 
old-fashioned way.  I am beginning to like the idea of parsing in 
stages.  If one pass does a partial parsing, later passes could use 
different tool.  Perhaps the DATA and PROCEDURE DIVISIONs could be parsed 
by different tools.  This is subject to an obscure REPORT SECTION anomaly, 
but it can be handled.

COBOL-20XX has done away with margin B, so all recognition of headers is 
driven on separator-periods alone.  The ZIF should be parsed into a next 
intermediate form (NIF)  period delimited sentences.  Then the next 
intermediate form is to parse this into programs, divisions, sections, and 
paragraphs.  This form would identify the nesting of programs so we call 
this the nested intermediate form (NIF).

>If it is advisable that these things not be done in isolation, then it is
>probably advisable that we not isolate ourselves from UNIX fundamentals. UNIX
>is a multi-tasking operating system.

The SYMT only needs to correctly handle nested environments, and these are 
issues are the same in a single threaded world.  Multi-tasking is strictly 
a back-end issue.

>The preprocessor could, for all intents and purposes, emit four files, one
>for each DIVISION.

You're ignoring nested programs.

>Alternatively with multiple
>files, If the DATA DIVISION file is closed early, then the DATA zPROC could
>be spawned early.

Owaitaminute, you really are trying to multi-task the compiler itself.  I 
advise against.

>This landscape suggest a critical question: can we imagine the FIF (first
>intermediate form) in a manner that permits the PROCEDURE zPROC to commence
>before the DATA zPROC terminates.

No but once the outermost DATA zPROC has finished, the outermost PROCEDURE 
zPROC could commence in parallel with the DATA zPROCs of the nested 
programs.  I advise against.

>Speaking of parallelism, I can image numerous FIF invocations per PROCEDURE
>DIVISION. Perhaps for each paragraph. ((here too we would need a way to
>eliminate file contention)).

I advise against.

--
RB |\  Randall Bart
aa |/  Barticus@usa.net 818-985-3259 Barticus@att.net
nr |\  8321 Burnet Av #1, North Hills, CA 91343
dt ||\
a   |/ Y2K website:    http://users.aol.com/PanicYr00
l   |\
l   |/ DOT-HS-808-065     I Love You    MS^7=6/28/107


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