John Gilmore wrote:
It is possible, but I do not recommend that you attempt to construct
an OPTIONS(MAIN) procedure that has multiple entry points.
You may, however, construct a multiple entry-point subroutine easily,
and some of these entries may be functions. Consider the skeletal
multiple-stack manager
skadmin: /* stack manager */
skactiv: procedure(paq, saq) /* activate, create a stack */
recursive
reorder
returns(pointer) ;
. . .
return(new_skp) ;
skpush: entry(skp, elemp) ; /* add an element to a stack */
. . .
return ;
skpop: entry(skp, elemp) /* remove an element if there is one */
returns(aligned bit) ;
. . .
return(success) ;
sksize: entry(skp) returns(signed binary fixed(31,0)) ; /* get stack's size */
. . .
return(in_stack_count) ;
skdeact: entry(skp) ; /*deactivate, destroy a stack */
. . .
return ;
end skadmin ; /* procedure ends */
This scheme makes C-like packages unnecessary. The recursive
attribute specified in the procedure statement is necessary only if
one of the entries calls itself or another.
Worth noting is that there is no fall-through in this procedure. Each
entry has its own RETURN or RETURN(<some value>) statement. To share
code, one entry may invoke another in trivially recursive fashion.
John Gilmore, Ashland, MA 01721 - USA
I'm afraid I don't see the comparison with C here...
What I understand you have defined is one PROCEDURE with
two names, "SKADMIN" and "SKACTIV". This one PROCEDURE also
has 4 other ENTRYs.
You mention that there is no "fall-through" - so, effectively,
each of these alternate ENTRYs into the one procedure is its own
individual PROCEDURE (each defines a beginning location, with
parameters and each returns.)
How would that be "meaningfully" different from this C equivalent:
void *
SKACTIV(paq, saq) /* activate, create a stack */
/* don't know the types of 'paq' and/or 'saq' since they weren't */
/* provided in the PL/I code. */
{
...
return new_skp;
}
void
SKPUSH(skp, elemp) /* add an element to a stack */
{
...
return;
}
int
SKPOP(skp, elemp) /* remove an element if there is one */
{
...
return (success);
}
int
SKSIZE(skp) /* get stack's size */
{
...
return (in_stack_count);
}
void
SKDEACT(skp) /* deactivate, destroy a stack */
{
...
return;
}
Now - perhaps there is some data-definition hiding going on? Presumably
'skp' is the address of "stack" being managed, and it has some DECL
that's missing
from the PL/I example. And, that declaration may be scoped only within the
SKACTIV PROC? But, I would contend that declaring that within the C source
file makes it just as private...
So - I'm wondering what you mean by "C-like packages"... seems pretty much
the same thing to me... Is there some other benefit conferred by the PL/I
approach?
One thing the C approach doesn't allow is two names on the same function,
since you have two names, SKADMIN and SKACTIV on the same PL/I PROC, you
would need to do something like:
void *
SKADMIN(paq, saq) /* ALIASof SKACTIV */
{
return SKACTIV(paq,saw);
}
in ANSI conforming C code, but most implementations have extensions that
would allow this ALIAS (Systems/C does via #pragma specifications.)
This is not to say that I don't see potential advantages to PL/I data hiding
with it's ability to have inner function scopes, etc... I just don't
see it with
this particular example... so, I'm wondering if I'm missing something...
It was my thought that the use of multiple ENTRY points was not as
common as it
might have once been... for some reason. But - I suppose this might be
better
discussed in comp.lang.pli...
- Dave Rivers -
--
[email protected] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
