|
boldt@ca.ibm.com wrote: > Well, a month ago, I would have given the "X-Spec" 50-50 odds of > making it into our next release. Here's an update: It's now > called the "CF-Spec" or "Free-form Calculation Specification" > and it's currently working in the lab! Most of the code is > already in place in the compiler. Believe it or not, this > enhancement turned out to be rather easy to code. I want this. And I want it _badly_. Since it is: 1) "rather easy to code" (your words), and 2) "Most of the code is already in place in the compiler" (your words), and 3) no one would be _forced_ to use it if made available, then I can't imagine a good reason why IBM would withhold it. > The general idea is to code F in position 7, blank in position 8, > and the free-form statement in positions 9-80. Start with the > opcode and extenders, followed either by the free-form expression > (for the current expression calcs) or by the Factor 1, Factor 2. > and Result Field operands (for the current fixed-form opcodes). > Everything is free-form within pos 9-80. There are no control > level indicators or conditioning indicators - use IF instead. > There are no resulting indicators - use BIFs %FOUND, %ERROR, etc. > instead. No definition of fields on calcs - use D-Specs for that. > CF specs may be intermixed with normal C specs, but we would > expect that programmers would likely keep the two styles separate. All of that makes sense to me. I still use level breaks on report programs and all I'd have to do is code: CL1 Exsr BlahBlah (spacing not correct) and then put all the actual calcs in a subroutine. BTW, what would a free form "begin subroutine" look like? > I would like to ask those interested to offer opinions on the > following design question: To what extent should the fixed-form > opcodes participate in the new scheme? > > 1) IFxx, DOWxx, etc. There are currently expression alternatives > for these, so why bother carrying these forward in the new > scheme. Do we support these in the CF-Spec? ie. Do we allow > code like: " CF ifeq counter 17 "? No, don't support in free form. > 2) String ops: SCAN, SUBST, XLATE, etc. There are expression > or BIF alternatives (or will be) for most (possibly all) of > these. Do we support these opcodes in the CF-Spec? Don't support if there is a BIF alternative. > 3) Move ops: MOVE, MOVEL. You could code EVAL/EVALR for many > moves, but not all MOVEs are easily convertible to the EVAL > statement. Do we support MOVEs in the CF-Spec? (If not, we > would have to add additional new BIFs, which still wouldn't > cover all of MOVE semantics.) Don't support if there is a BIF alternative (or will be). You're right that there are some MOVEs stuff that won't work correctly with EVAL, but I'll be darned if I can think if the examples right now. But, since we can intermingle fixed and free format, if there is one of those weird places where one needs a MOVE, just code a fixed format MOVE until the BIF is available. > 4) Arithmetic ops: ADD, SUB, etc. As many have already > discovered, arithmetic in expressions is not totally > compatible with arithmetic in the fixed opcodes. Do we > support these in the CF-Spec? ie. Do we allow code > like: " CF add 1 counter "? Don't support if there is a BIF alternative (or will be). There are some places where I use ADD, SUB, etc. because I am expecting a truncation. I'm still on V3R2 (for probably 10-12 mos yet), but I know there are some V4 BIFs that help with this situation. > (This list isn't complete, but is representative enough for the > purpose of helping us decide the issue.) > > So, the general issue is how much of the "old" stuff do we carry > forward in the CF-Spec and how much can we leave behind? Leave it all behind. As I said, if there is something weird, and we can mix in fixed format C specs, I'll just stick one in in the rare case I need one. Please tell me this will see the light of day! -- -Jeff jlcrosby@fwi.com +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.