I'm interested in how easy it is to recompile a PL/I program for 64-bit when you have to explicitly specify bit widths on the types. That's trivial to do in C.
> On 19 Nov 2014, at 8:53 pm, John Gilmore <[email protected]> wrote: > > As I have had occasion to note here before, the traditions of C and > its sequelæ interest me chiefly as illustrations of one or another > pathology. > > The PL/I tradition provides better positive guidance. From the > beginning, with the PL/I F > compiler, such a construction as > > declare hashvcs entry(character(*) varying, binary fixed(15,0)) > returns(binary fixed(15,0)) ; > . . . > declare hashin character(*) varying, hashval binary fixed(15,0) ; > > hashval = hashvcs(hashin, 1101b) ; > > resulted in the creation of a halfword temporary initialized to have > the binary value 1101b (decimal 13). The address of that temporary, > not that of the (internal/converted) value of the literal 1101b, was > then made available to the entry hashvcs, which was free to mutilate > it without non-local effect. > > Today, one can make corresponding distinctions within a function like > hashvcs, as in > > hashvcs: procedure(vcs, modulus) > returns(signed binary fixed(15,0)) > reorder ; > > declare (vcs character(*) varying2, > modulus signed binary fixed(15,0)) > nonassignable parameter ; > > . . . > return(hashval) ; > > end hashvcs ; > > C and its sequelæ are and now seem likely to remain toys. They have > achieved all of the portability of assembly language without its > expressive power. > > John Gilmore, Ashland, MA 01721 - USA > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
