|
> From: Buck Calabro > > Joe, you're being a naughty boy. Oh, as if THAT'S unusual. But come to think of it, I now recall something the %kds syntax in particular and wondering about it. Didn't like it at the time, don't like it now. <grin> > I can think of one: A BIF that supports a /free enhanced opcode. An example > of this is %KDS which can hold the keylist for the /free CHAIN. I'm going to go with you on this one for a second, but bear with me. >> As to new opcodes, I'd have to see them, but I'm again >> of the mind that anything that can fit into free-form >> can fit into an RPG IV expression. > The enhanced CHAIN is an example. Factor one in columnar format isn't large > enough to specify a list of fields, but in /free form there is. Why can't there be a version of CHAIN (perhaps with an extender, such as CHAIN(x) for "extended") that fits into the extended C-spec syntax? The rest of the free-form line can fit into the extended Factor 2. Tell me what the difficulty is there, since all the parsing is already written for the free form code. And isn't reuse the word of the day? Because if you do that, then your earlier argument doesn't hold, does it? On the other hand, if you don't extend the syntax, this becomes the classic case of building an argument on a shaky foundation. Rather than addressing the underlying issue and fixing it (by making any freeform statement fit into a fixed-format extended C-spec), you end up with a rickety dual-version structure of the language. How rude! Joe
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.