--vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
On Tue, Aug 26, 2003 at 02:30:57PM -0500, Ron Johnson wrote: > On Tue, 2003-08-26 at 13:29, David Turetsky wrote: > > > On Tue, 2003-08-26 at 10:05, Kirk Strauser wrote: > > > From: Ron Johnson [mailto:[EMAIL PROTECTED] > > > For example, COBOL has intrinsic constructs for easily handling > > > ISAM files in a variety of manners. Likewise, there is a very=20 > > > powerful intrinsic SORT verb. > > >=20 > >=20 > > Yes, but how does that compare with similarly powerful features in Perl? >=20 > I *knew* someone would ask about the Programmable Extraction and > Reporting Language... >=20 > Please don't think that I am implying that Perl or C are bad languages. > I certainly wouldn't write a logfile analyzer in COBOL. >=20 > For my knowledge, how would Perl sort the contents of a file, > allowing the programmer to use a complex algorithm as an > input filter, and then take the output stream, processing it > 1 record at a time, without needing to write to and then read > from temporary files with all of the extra SLOC that that entails? 1) Read from records from file into an array. 2) Order them with any perl code you want and store them in an array. 3) Use a nice foreach loop to process them. --- Outline of Perl code --- #!/usr/bin/perl @records =3D read_records_function("records.txt"); #either @sorted =3D sort @records; #to put things in alphabetical order #or=20 @sorted =3D sort function @records; #to sort using a function # or even @sorted =3D sort {sort-function-code} @records; #to have it in-line foreach $record (@sorted) { # code to process records } >=20 > One thing that I don't think that any of the "modern" languages > do, without extra libraries and function calls, is BCD arithmatic. That's true. You could overload the arithmetic operators in perl to get this. But it would be using function calls behind your back. > Here's a simplistic example of how COBOL is specialized: > Say we have 2 record definitions: > 01 A-SMALL-REC. > 05 FIRST-NAME PIC X(15). > 05 LAST-NAME PIC X(15). > 01 A-LARGE-REC. > 05 HONORIFIC PIC X(5). > 05 FIRST-NAME PIC X(15). > 05 MIDDLE-I PIC X. > 05 LAST-NAME PIC X(15). > 05 MODIFIER PIC X(5). >=20 > MOVE 'JOHN' TO A-SMALL-REC.FIRST-NAME. > MOVE 'DOE' TO A-SMALL-REC.LAST-NAME. > MOVE SPACES TO A-LARGE-REC. >=20 > MOVE CORRESPONDING A-SMALL-REC TO A-LARGE-REC. >=20 > Here, A-SMALL-REC.FIRST-NAME and A-SMALL-REC.LAST-NAME will be > moved to the corresponding fields in A-LARGE-REC. > In such a trivial example, so what? If, however, there are many > fields in A-SMALL-REC, then MOVE CORRESPONDING is a big coding > time-saver, and ensures that if the records definitions ever > change, the code will still work. That is cool for fixed records. But perl is big on dynamic stuff. In perl you use hashes (associative arrays) for things like that. so: %small =3D ( first_name =3D> "John", last_name =3D> "Doe", ); foreach $key (keys %small) { $large{$key} =3D $small{$key}; } Note: I'm not a Perl expert so the examples may be ugly (and might not even be functional). Bijan --=20 Bijan Soleymani <[EMAIL PROTECTED]> http://www.crasseux.com --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/S+vaUof+95vTyAwRAp00AKCHBRkIuwZHJGbSxrgj5mJiEqJS2gCfdd7A V52+XggV9eHDjb1uuRFqVsY= =EaQO -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]