From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,30df5a909ff1af4
X-Google-Attributes: gid103376,public
From: Brian Rogoff <bpr@shell5.ba.best.com>
Subject: Re: Answering an Ada/COBOL Question
Date: 1999/11/13
Message-ID: <Pine.BSF.4.10.9911131710530.16406-100000@shell5.ba.best.com>#1/1
X-Deja-AN: 548310407
References: <80hr16$5q2$1@nntp5.atl.mindspring.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: nntp1.ba.best.com 942543201 241 bpr@206.184.139.136
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-11-13T00:00:00+00:00
List-Id: <comp.lang.ada>

On Fri, 12 Nov 1999, Richard D Riehle wrote:
> David Glessner wrote:
> 
> Richard D Riehle wrote:
> > Yes, indeed. The COBOL version of a case statement is still the
> > most elegant design of multiway selection I have seen in any
> > language.  Also, COBOL has adopted some ideas from Ada, although
> > the COBOL users don' realize it.
> 
> Care to elaborate for us non-COBOL-aware folks?
> 
> As briefly as possible, here goes:
> 
> COBOL uses the word "Evaluate" instead of "case".  There are several
> variations in syntax.  I will not cover all of them.  Instead, the one
> that is interesting to me is the "decision table" version.  Also, I will
> code this in a format that does not include some of COBOL's syntactic
> sugar so it is easy to read.
> 
>       Evaluate A also B also C
>          when True also True also True
>               Perform ... end-perform
>          when True also True also False
>               Perform ... end-perform
>          when False also True also False
>               Perform ... end-perform
>          when others
>               Perform ... end-perform
>       End-Evaluate

I don't want to rain on your parade, but how is this nicer than the
pattern matching capability that all modern functional programming 
languages have? Not only can they match on product types, like your 
bool * bool * bool tuple, but they can match on lists, records, 
and sum types. That seems far more elegant than the COBOL snippet above.
Am I missing something?

> Note the ease with which one can map a decision table directly to
> the code.  One can argue that this _can_ be expressed just as well
> in some other language, perhaps Ada.  However, the question is never
> "Is it _expressible_ ?" The real issue is whether how well it can be
> expressed.  It is _expressiveness_ rather than _expressibility_.   

match(a,b,c) with 
  (true,true,true)  -> foo
| (true,true,false) -> bar
| (true,false,false) -> baz
| (_,_,_)            -> default

seems perfect to me, but I don't know COBOL. Is there some other aspect of 
COBOL's conditional that gives it more expressiveness than what you've 
shown?

-- Brian (OCaml fan, and Ada fan too ;-)