The line > Automatic, LIFO dynamic storage IS readily available in PL/I . . .
in my post is literal nonsense. It should be > Automatic, LIFO dynamic storage IS readily available in COBOL . . . David Crayford wrote: > I'm a rare bird in the z/OS sense in that I code in C++. I'm lucky enough to > have linked > lists, sets, trees, vectors, queues, stacks, hash tables - not to mention > algorithms as > part of the standard library. These C++ Standard-Library routines vary widely in quality, as do the [vanilla] C Standard-Library routines. Some are superb per se, and others are mediocre. They all have the defect of specialism. In working systems queues, say, are often imperfect examples of the ideal type 'queue'; one must occasionally, for example, perform operations more appropriate to a stack on them; and as soon as such requirements arise their defects become apparent and their virtues disappear. Reusability is desirable and possible, but C++ has not achieved it meaningfully. C++ programmers often accuse C (and other) programmers of writing things that are "too procedural"; and in my view C++ is "too declarative"; but discussions of this sort are seldom productive: they turn into religious warfare. All statement-level procedural languages share one generic defect: They embody a particular episteme, a world view that makes some questions meaningful and tractable and others, if not quite meaningless, intractable, hard to talk about, because no conceptual machinery for treating them is made available. This, finally, is the rationale for resorting to assembly language. It provides an escape from the parochial. The Scots poet Blair noted that archangelic visits to the earth, needed to keep things in order here below, were and by implication could be "short and far between"; and this is not a bad description of the rationale for assembly-language subroutines. Blair's line is usually mangled to come out "few and far between", which is repetitive or worse; and I imagine that what I have just written will be misrepresented too; but I expect that. John Gilmore, Ashland, MA 01721 - USA On 12/12/11, David Crayford <dcrayf...@gmail.com> wrote: > On 13/12/2011 6:48 AM, John Gilmore wrote: >> I was aware of the presence of ALLOCATE and FREE in the 'new' COBOL >> standard >> >> This thread has wandered far from its initial topic, and perhaps it is >> time to let it expire quietly. Frank likes variable-length tables. I >> agree that self-defining tables like those achievable with the >> ALLOCATE and REFER of PL/I are desirable, but linked lists are >> essential; and until COBOL can do them it will not, in my view, have >> any proper claim to be classified as an adult language: move-mode >> processing schemes are juvenilia at their best. > > There are examples in the LE manuals on how to process linked lists in > COBOL > http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ceea200/cobbls.htm. > If the language supports pointers and memory management then you can > have linked lists. > > I'm a rare bird in the z/OS sense in that I code in C++. I'm lucky > enough to have linked lists, sets, trees, vectors, queues, stacks, hash > tables - not to mention algorithms as part of the standard > library. And they have been implemented by experts with PHDs in computer > science (dinkumware). And I do trust them to implement top quality > libraries. > > Without COBOL the mainframe is essentially dead as we know it. MAINFRAME > = COBOL. > > >> Differences of this kind are one of the chief reasons why languages >> continue to get bigger and bigger. As Justice Holmes put it long ago, >> "If you like diamonds and I like rubies we have just three options: >> battle, compromise, or a jeweler who has both"; and the jeweler who >> has both is obviously the politic choice. >> >> --jg >> >> On 12/12/11, Frank Swarbrick<frank.swarbr...@yahoo.com> wrote: >>> ALLOCATE and FREE are part of the 2002 COBOL international standard >>> (ISO/IEC >>> 1989:2002); a standard which IBM has made no commitment to implement... >>> >>> While certainly useful if you would like to build linked lists, I >>> personally >>> would much prefer dynamic-length tables and dynamic-length "strings". >>> >>> Frank >>> >>> >>> >>> >>>> ________________________________ >>>> From: John Gilmore<johnwgilmore0...@gmail.com> >>>> To: IBM-MAIN@bama.ua.edu >>>> Sent: Monday, December 12, 2011 1:26 PM >>>> Subject: Re: Java apps have most flaws, Cobol is cleanest. >>>> >>>> Automatic, LIFO dynamic storage IS readily available in PL/I in the >>>> form of local storage. In my experience it is not much used because >>>> misunderstood: people who attempted, uninstructed, to use it early on >>>> were dismayed when they discovered that successive subroutine calls >>>> did not leave it in its last-used state. >>>> >>>> Based, non-LIFO dynamic storage that does persist in last-used state >>>> is available in COBOL only via LE calls. (As I mentioned in another >>>> post these services are easy to rename perspicuously.) >>>> >>>> This situation may change. IBM would object, strongly and correctly, >>>> to the notion that there is some sort of implicit promise embedded in >>>> its choices, but it is interesting to note that among the keywords not >>>> yet used in Enterprise COBOL but reserved for possible future use are >>>> two, >>>> >>>> ALLOCATE and FREE, >>>> >>>> that are suggestive, at least to anyone who knows PL/I. >>>> >>>> >>>> John Gilmore, Ashland, MA 01721 - USA >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >>>> Search the archives at http://bama.ua.edu/archives/ibm-main.html >>>> >>>> >>>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >>> Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
