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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Xref: utzoo alt.cobol:129 comp.lang.ada:3546 comp.infosystems:86
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!samsung!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: alt.cobol,comp.lang.ada,comp.infosystems
Subject: Re: What's really wrong with COBOL?
Message-ID: <1990Mar25.221939.15380@world.std.com>
Date: 25 Mar 90 22:19:39 GMT
References: <1990Mar24.154331.3328@world.std.com> <8483@hubcap.clemson.edu>
Organization: Saber Software
List-Id: <comp.lang.ada>

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas
Wolfe, 2847) writes:

>   Please explicitly point out what specific statements you considered
>   inaccurate, if any.

Earlier he had written:

>  There is also tremendous difficulty when one tries to describe what
>  is known as an "abstract data type" in COBOL.  This is a style by
>  which one identifies and characterizes a real-world object through
>  a description of the operations which can be done with that object,
>  such that a guarantee exists that nobody can do anything with the
>  object without making use of the predefined operations available 
>  for it

You are defining "abstract data type" incorrectly; I would call it
"any data type which does not exist by default in the language
specification".  What you are describing is a little more complex than
an abstract data type, yes?

Happy hacking,

jim frost
saber software
jimf@saber.com