Code Comments
Programming Forum and web based access to our favorite programming groups.FUNCTION TRIM (arg [LEADING/TRAILING]) Aaaagh, who thought that one up ? Optional syntax as part of the argument list ??!!! Roger
Post Follow-up to this messageRoger While<simrw@sim-basis.de> 05/23/06 3:08 AM >>> >FUNCTION TRIM (arg [LEADING/TRAILING]) > >Aaaagh, who thought that one up ? >Optional syntax as part of the argument list ??!!! Hmm, isn't it actually FUNCTION TRIM(arg [LEFT/RIGHT]) In any case, are you saying you'd prefer three separate functions, eg FUNCTION TRIM(arg) FUNCTION TRIM-LEFT(arg) FUNCTION TRIM-RIGHT(arg) Anyway, can't you just code it as cobc_intr_trim(unsigned char *arg, int type) Where type is, say, 0 for both, 1 for left and 2 for right? Not that I know anything about compiler building, but I have been looking through the source code. :-) Frank --- Frank Swarbrick Senior Developer/Analyst - Mainframe Applications FirstBank Data Corporation - Lakewood, CO USA
Post Follow-up to this messageRoger While wrote: > > FUNCTION TRIM (arg [LEADING/TRAILING]) > > Aaaagh, who thought that one up ? > Optional syntax as part of the argument list ??!!! > > Roger Nothing new about that. Depending on the way it's implemented, it's no problem flagging the last argument in some way so that the called routine can determine that important fact. In BAL, it used to be (and may well still be) that the arguments were passed on by a series of address constants,the last one of which had the high-order bit set on - whether the called routine needed it or not. Piece of cake. PL
Post Follow-up to this message"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> schrieb im Newsbeitrag news:4dgnakF1a7gajU2@individual.net... > Roger While<simrw@sim-basis.de> 05/23/06 3:08 AM >>> > > Hmm, isn't it actually > FUNCTION TRIM(arg [LEFT/RIGHT]) > Not according to the complete 2008 pdf mentioned in a post above - "Specifically, http://www.cobolportal.com/j4/files/std.zip" > In any case, are you saying you'd prefer three separate functions, eg > FUNCTION TRIM(arg) > FUNCTION TRIM-LEFT(arg) > FUNCTION TRIM-RIGHT(arg) > Yes. What on earth has the LEADING/TRAILING to do with the argument list ? Answer - Nothing, they do NOT belong in between the parentheses. Ridiculous. Does this read well ? -> FUNCTION TRIM (FUNCTION TRIM (FUNCTION REVERSE (fld) LEADING) TRAILING) > Anyway, can't you just code it as > > cobc_intr_trim(unsigned char *arg, int type) > > Where type is, say, 0 for both, 1 for left and 2 for right? > > Not that I know anything about compiler building, but I have been looking > through the source code. :-) > Oh, sure anything's doable. It's a question how. :-) Roger
Post Follow-up to this messageAs I recall, LEFT and RIGHT were disparaged on the grounds that they weren't well-defined in terms of a character string and the addressing of memory in a given platform. Note that TRIM(x) in WD 1.6 returns a string with BOTH the leading and trailing spaces removed; TRIM (x, LEADING) leaves trailing spaces intact, and TRIM(x, TRAILING) leaves leading spaces intact. Based on what I see in WD 1.5, I think there's a conflict between the syntax *diagram* and the syntax *rules* anyhow. My guess is that "LEFT" should have been underlined as well; the absence of the underlining implies that it represents the default and may be omitted, and the returned values rules don't reflect that. Optional arguments to procedures and functions are hardly new to computers; ALGOL's had them for a very, very long time. -Chuck Stevens <top post, no more below> "Roger While" <simrw@sim-basis.de> wrote in message news:e4vgul$veg$02$1@news.t-online.com... > > "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> schrieb im Newsbeitrag > news:4dgnakF1a7gajU2@individual.net... > > Not according to the complete 2008 pdf mentioned in a post above - > "Specifically, http://www.cobolportal.com/j4/files/std.zip" > > > > Yes. > What on earth has the LEADING/TRAILING to do with the argument list ? > Answer - Nothing, they do NOT belong in between the parentheses. > Ridiculous. Does this read well ? -> > FUNCTION TRIM (FUNCTION TRIM (FUNCTION REVERSE (fld) LEADING) TRAILING) > > > Oh, sure anything's doable. It's a question how. > :-) > > > Roger >
Post Follow-up to this messageAlso, TRIM is not the only intrinsic function with "optional arguments". The (older) RANDOM function could take ZERO or 1 argument NUMVAL-C in the 2002 Standard has both LOCALE and ANYCASE as (optional) keyw ords And LOWER-CASE and UPPER-CASE are also modified in the '08 draft to include the LOCALE keyword -- Bill Klein wmklein <at> ix.netcom.com "Chuck Stevens" <charles.stevens@unisys.com> wrote in message news:e4vidv$2mn4$1@si05.rsvl.unisys.com... > As I recall, LEFT and RIGHT were disparaged on the grounds that they weren 't > well-defined in terms of a character string and the addressing of memory i n a > given platform. > > Note that TRIM(x) in WD 1.6 returns a string with BOTH the leading and > trailing spaces removed; TRIM (x, LEADING) leaves trailing spaces intact, and > TRIM(x, TRAILING) leaves leading spaces intact. > > Based on what I see in WD 1.5, I think there's a conflict between the synt ax > *diagram* and the syntax *rules* anyhow. My guess is that "LEFT" should h ave > been underlined as well; the absence of the underlining implies that it > represents the default and may be omitted, and the returned values rules d on't > reflect that. > > Optional arguments to procedures and functions are hardly new to computers ; > ALGOL's had them for a very, very long time. > > -Chuck Stevens > > <top post, no more below> > > "Roger While" <simrw@sim-basis.de> wrote in message > news:e4vgul$veg$02$1@news.t-online.com... > >
Post Follow-up to this messagePeter Lacey<lacey@mts.net> 05/23/06 9:43 AM >>> >Roger While wrote: > >Nothing new about that. Depending on the way it's implemented, it's no >problem flagging the last argument in some way so that the called >routine can determine that important fact. In BAL, it used to be (and >may well still be) that the arguments were passed on by a series of >address constants,the last one of which had the high-order bit set on - >whether the called routine needed it or not. Piece of cake. If you mean z/Architecture Basic Assembly Language (and it's ancestors), that is still the case. COBOL (on z/Arch) follows this same standard. Now if only COBOL could check for that high-order bit being set to allow for easy 'variable argument' calls! :-) --- Frank Swarbrick Senior Developer/Analyst - Mainframe Applications FirstBank Data Corporation - Lakewood, CO USA
Post Follow-up to this messageI am NOT arguing optional and/or variable argument lists. That, of course, is perfectly OK. What I object to is having an attribute of the function itself as an argument. This really is not consistent. So there should be TRIM-LEADING, TRIM-TRAILING, LOCALE-NUMVAL-C, LOCALE-LOWER-CASE, LOCALE-UPPER-CASE etc. The current syntax is misleading in that it reads as though the "function atrribute" (eg. LEADING, LOCALE) applies to the argument to the function and not as a "directive" to the function. Roger "William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag news:24Mcg.14163$9j.11642@fe08.news.easynews.com... > Also, TRIM is not the only intrinsic function with "optional arguments". > > The (older) RANDOM function could take ZERO or 1 argument > > NUMVAL-C in the 2002 Standard has both LOCALE and ANYCASE as (optional) > keywords > > And LOWER-CASE and UPPER-CASE are also modified in the '08 draft to > include the LOCALE keyword > > -- > Bill Klein > wmklein <at> ix.netcom.com > "Chuck Stevens" <charles.stevens@unisys.com> wrote in message > news:e4vidv$2mn4$1@si05.rsvl.unisys.com... > >
Post Follow-up to this messageNotice that the Standards ('02 and draft '08) explicitly call these "keyword
arguments". Whether you like them or not, they do exist and I don't think t
here
is any real chance of changing this. You can, however, send in comments to
J4
or your "national body" for WG4. Make certain that you comment on it during
public review.
--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:e50s0r$27u$01$1@news.t-online.com...
>I am NOT arguing optional and/or variable argument lists.
> That, of course, is perfectly OK.
> What I object to is having an attribute of the function itself
> as an argument. This really is not consistent.
> So there should be
> TRIM-LEADING, TRIM-TRAILING, LOCALE-NUMVAL-C,
> LOCALE-LOWER-CASE, LOCALE-UPPER-CASE etc.
>
> The current syntax is misleading in that it reads as though the
> "function atrribute" (eg. LEADING, LOCALE) applies to the
> argument to the function and not as a "directive" to the function.
>
> Roger
>
> "William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
> news:24Mcg.14163$9j.11642@fe08.news.easynews.com...
>
>
Post Follow-up to this messageAs a slight aside, with the advent of FUNCTION-ID,
it "should" be possible to code FUNCTIONS as
Cobol coded FUNCTION-ID modules :-)
Of course, you can't as there is no definition for argument counts
and, even if, what do you do/pass with "keyword arguments" :-)
OpenCOBOL has NUMBER-OF-CALL-PARAMETERS :-)
Roger
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:EITcg.23859$p_1.11361@fe03.news.easynews.com...
> Notice that the Standards ('02 and draft '08) explicitly call these
> "keyword arguments". Whether you like them or not, they do exist and I
> don't think there is any real chance of changing this. You can, however,
> send in comments to J4 or your "national body" for WG4. Make certain that
> you comment on it during public review.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:e50s0r$27u$01$1@news.t-online.com...
>
>
Post Follow-up to this messagePowered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.