Home > Archive > Cobol > May 2006 > Combined Abbreviated contidionts (was: PIC P put to real use
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Combined Abbreviated contidionts (was: PIC P put to real use
|
|
| William M. Klein 2006-05-26, 6:55 pm |
| Frank and Chuck
(As Roger - and other implementors may want to tell you), I think the
"oddest" (least desirable?) thing was that when EVALUATE was extended in the '02
Standard to allow "partial expressions" (in the WHEN clause) that there was no
decision to PROHIBIT combined abbreviated conditions in this NEW syntax.
I suppose that I understand (and might even have agreed) with NOT having
different rules for conditional expressions in EVALUATE and IF - on the other
hand, this would have been a "nice" to restrict such things as:
Evaluate Some-Field
When "A"
When Not < "B" or C-Field
When = "D" or E-field or X > "Y"
When >= "F" or G-Field or NOT Some-88-level
Oh well,
so many things could be done differently - if we were ONLY starting over <G>
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4dph9lF1apmv4U1@individual.net...
> Chuck Stevens<charles.stevens@unisys.com> 05/26/06 10:53 AM >>>
>
>
>
>
>
>
>
> I continue to use abbreviated conditions, and I continue to get bit by
> them!
> It's 40 years to late, most likely, it seems to me (and probably most?) that
> the following:
>
> 1) if result = 'a' or 'b' and something-is-true
> means
> 2) if (result = 'a' or result = 'b') and something-is-true
>
> when in fact in COBOL it really means
> 3) if result = 'a' or result = 'b' and something-is-true
> which of course means
> 4) if (result = 'a') or (result = 'b' and something-is-true)
>
> Ah well... I will most likely continue to use them and be bitten by them,
> simply because I like to code as few characters as possible. The use of
> 88-levels at least somewhat mitigates the problem, though. eg
> if good-result and something-is-true
> where 88 good-result value 'a' 'b'.
>
> That's probably the best. IMO. And it makes it fairly simple to add a new
> 'good result' if needed.
>
> Anyway, no, I don't expect COBOL to change this at this stage. Would break
> too many programs, though I do find it hard to imagine someone using example
> 1 and really expecting it to bind like example 3. Has anyone ever done this
> intentionally?
>
> Does anyone know of any other programming languages with abbreviated
> conditions? How do they handle them?
> (It's ironic that COBOL has them, as COBOL is generally known as being more
> verbose than most languages!)
>
> Frank
>
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
| |
| Roger While 2006-05-27, 3:55 am |
| Couldn't agree more, Bill.
I sent Bill some questionable syntax off-list some time ago.
I suppose the main question here is :
Are the EVALUATE/WHEN conditional (partial) expressions
directly (one-to-one) equivalent to the corresponding IF syntax.
(And one of the problems is when NOT immediately follows WHEN -
think about it)
Roger
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:fuMdg.90924$lk7.26702@fe04.news.easynews.com...
> Frank and Chuck
> (As Roger - and other implementors may want to tell you), I think the
> "oddest" (least desirable?) thing was that when EVALUATE was extended in
> the '02 Standard to allow "partial expressions" (in the WHEN clause) that
> there was no decision to PROHIBIT combined abbreviated conditions in this
> NEW syntax.
>
> I suppose that I understand (and might even have agreed) with NOT having
> different rules for conditional expressions in EVALUATE and IF - on the
> other hand, this would have been a "nice" to restrict such things as:
>
> Evaluate Some-Field
> When "A"
> When Not < "B" or C-Field
> When = "D" or E-field or X > "Y"
> When >= "F" or G-Field or NOT Some-88-level
>
> Oh well,
> so many things could be done differently - if we were ONLY starting over
> <G>
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:4dph9lF1apmv4U1@individual.net...
>
>
| |
| Frank Swarbrick 2006-05-27, 6:55 pm |
| William M. Klein<wmklein@nospam.netcom.com> 05/26/06 5:49 PM >>>
>Frank and Chuck
> (As Roger - and other implementors may want to tell you), I think the
>"oddest" (least desirable?) thing was that when EVALUATE was extended in
the '02
>Standard to allow "partial expressions" (in the WHEN clause) that there was
no
>decision to PROHIBIT combined abbreviated conditions in this NEW syntax.
>
>I suppose that I understand (and might even have agreed) with NOT having
>different rules for conditional expressions in EVALUATE and IF - on the
other
>hand, this would have been a "nice" to restrict such things as:
>
> Evaluate Some-Field
> When "A"
> When Not < "B" or C-Field
> When = "D" or E-field or X > "Y"
> When >= "F" or G-Field or NOT Some-88-level
>
>Oh well,
> so many things could be done differently - if we were ONLY starting over
<G>
Heh, I really like that!
I can't read it, but I like it.
:-)
Not.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
|
| In article <4drinuF1bm4qnU1@individual.net>,
Frank Swarbrick <Frank.Swarbrick@efirstbank.com> wrote:
>William M. Klein<wmklein@nospam.netcom.com> 05/26/06 5:49 PM >>>
[snip]
><G>
>
>Heh, I really like that!
From
<http://groups.google.com/group/comp...de=source&hl=en>
--begin quoted text
Attributed to Alfonso X (The Wise) of Spain: 'Had I bben present at the
creation I would have given some useful hints for the better ordering of
the universe.'
--end quoted text
DD
|
|
|
|
|