Re: Ada 95 LRM Error?

Re: Ada 95 LRM Error?

[Martin C. Carlisle]

In article <36AF6C22.896FC5B8@easystreet.com>,
Al Christians  <achrist@easystreet.com> wrote:
>I'm looking at the Ada 95 Reference Manual, B.4.106.  It shows
>a field: 
>
>	Name  : COBOL.Numeric(1..20);
>
>Later on,  in B.4.109, this gets assigned:
>
>	Name => "Johnson, John           ",
>
>This looks pretty obviously like an error, and I think it probably
>should be Alphanumeric instead of Numeric. However, Numeric is what
>it is, both in my printed version of the LRM and the online LRM
>that comes with the brand-new edition of AdaGide.

Actually, there is a newer version of the LRM that I believe is being
maintined by:

"J. David Bryan" <dbryan@bcpl.net>

but it didn't make GNAT 3.11p.  I don't recall where he kept it, but I have
a copy at:

ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/act/incoming/rm-winhelp.tar.gz

I agree with your assessment, although if you look at the definitions
of Alphanumeric and Numeric, they are the same.  So, it's merely a purist
sort of thing.

--Martin

-- 
Martin C. Carlisle, Asst Prof of Computer Science, US Air Force Academy
mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standards or 
policy of the US Air Force Academy or the United States Government.

Re: Ada 95 LRM Error?

[Al Christians]

Richard D Riehle wrote about Interfaces.Cobol:
> 
>  As it is, the package is defined so it conforms to the conventions of
>  typical COBOL programming.
> 

But if I put non-numeric data into a Numeric, it will flunk the
Valid() test, right?

Since you speak of 'typical COBOL programming', can you enlighten me a 
little about why this interface looks the way it does?  

For example, the To_Binary(Num, Binary_Format)  function returns a
Byte_Array and not a Binary, and there is no corresponding
To_Long_Binary.  It looks like To_Binary decides what length of
Byte_Array to give back based on the digits of Num. I suppose that
the compiler can figure this all out at compile time, since digits
is static, but it seems a little odd that the size of a Byte_Array is
never really set anywhere in the visible code, but the subtype returned 
from To_Binary depends on Num's digits. It's also a little confusing
that there are 2 binary types, ie Binary and Long_Binary, but that in
GNAT, for example, the return values from To_Binary, come in four
different sizes (I think).

That the Binary_Format doesn't specify the field size also makes it a
little hard to be consistent with the Cobol code I know about, which
allows a compile time switch to indicate whether or not a number with
fewer than 3 digits uses one or two bytes. Here Interfaces.Cobol decides
that for me behind the scenes.

Thanks for your assistance, Richard.

Al

Ada 95 LRM Error?

[Al Christians]

I'm looking at the Ada 95 Reference Manual, B.4.106.  It shows
a field: 

	Name  : COBOL.Numeric(1..20);

Later on,  in B.4.109, this gets assigned:

	Name => "Johnson, John           ",

This looks pretty obviously like an error, and I think it probably
should be Alphanumeric instead of Numeric. However, Numeric is what
it is, both in my printed version of the LRM and the online LRM
that comes with the brand-new edition of AdaGide.

Is 20 even going to work for a Numeric size on typical platforms? That's
more than 64 bits.

Am I wrong or is this in need of fixing?  How would that happen?


Al

Re: Ada 95 LRM Error?

[Richard D Riehle]

In article <36AF6C22.896FC5B8@easystreet.com>,
	Al Christians <achrist@easystreet.com> wrote:

>I'm looking at the Ada 95 Reference Manual, B.4.106.  It shows
>a field: 
>
>	Name  : COBOL.Numeric(1..20);
>
>Later on,  in B.4.109, this gets assigned:
>
>	Name => "Johnson, John           ",
>
>This looks pretty obviously like an error, and I think it probably
>should be Alphanumeric instead of Numeric. However, Numeric is what
>it is, both in my printed version of the LRM and the online LRM
>that comes with the brand-new edition of AdaGide.
>
>Is 20 even going to work for a Numeric size on typical platforms? That's
>more than 64 bits.
>
>Am I wrong or is this in need of fixing?  How would that happen?

 A look at the data types involved might be helpful.

 In the package Interfaces.COBOL there are several data types that
 seem to have the same set of values.

 Line 13:  type COBOL_Character is  implementation-defined character type;

 Line 16:  type Alphanumeric is array
           (Positive range <>) of COBOL_Character := implementation-defined;

 Line 20: type Numeric is array
           (Positive range <>) of COBOL_Character := implementation-defined;

 Line 56: type Alphanumeric corresponds to COBOL's alphanumeric
                 data category.

 Line 59: type Numeric corresponds to COBOL's numeric data category
                 with display usage.

 The key words in line 59 are "display usage" which imply that the
 underlying representation will be one byte per number.  Therefore,
 it is possible that the indicated statements will work in some 
 environments, even though it would have been more appropriate to 
 use alphanumeric.  An alphanumeric COBOL number, such as '6', 
              
              05 X PICTURE 9.

 can be assigned directly to a numeric data item,

              05 Y PICTURE X.

 in COBOL if both are USAGE DISPLAY.

 The Corresponding Ada types would also allow this if the assignment
 were between slices of the same component type.  If there is an 
 error, it may be that the Numeric data type was not more
 strictly defined to ensure that such assignments require a function
 call such as,

    function To_Alphanumeric(N : Numeric) return Alphanumeric;
    function To_Numeric (A : Alphanumeric) return Numeric;

 As it is, the package is defined so it conforms to the conventions of
 typical COBOL programming.  

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com

Re: Ada 95 LRM Error?

[robert_dewar]

In article <36AF6C22.896FC5B8@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> I'm looking at the Ada 95 Reference Manual, B.4.106.  It
> shows a field:
>
> 	Name  : COBOL.Numeric(1..20);
>
> Later on,  in B.4.109, this gets assigned:
>
> 	Name => "Johnson, John           ",
>
> This looks pretty obviously like an error, and I think it
> probably should be Alphanumeric instead of Numeric.

Well first, remember this is just an example, it is not
part of the standard, so an error in an example is not of
any real significance.

Second, oddly the example is indeed completely correct in
a formal sense, since the type Numeric is an array of
COBOL.Character without any restriction on what can be
there.

Nevertheless, this is pretty clearly confusing, and
examples are supposed to be enlightening, so I agree that
Alphanumeric should be used here.

Now the next step is to follow the procedure in
RM 1(59), and send a comment to the appropriate
address:

59   Informal comments on this International Standard may
be sent via e-mail to ada-comment@sei.cmu.edu.  If
appropriate, the Project Editor will initiate
a Technical Corrigendum to be issued for the standard.

ALso note the formatting requirements in subsequent
paragraphs when you send the comment.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada 95 LRM Error?

[robert_dewar]

In article <36AFC42A.57696F4D@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> That the Binary_Format doesn't specify the field size
> also makes it a little hard to be consistent with the
> Cobol code I know about, which allows a compile time
> switch to indicate whether or not a number with
> fewer than 3 digits uses one or two bytes.

I don't see anyway the interface can be compatible with
odd non-standard COBOL stuff like this!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada 95 LRM Error?

[J. David Bryan]

On 27 Jan 1999 23:23:20 GMT in article <78o758$8ob$1@cnn.Princeton.EDU>, 
mcc@entropy.cs.princeton.edu wrote...
>
>I don't recall where he kept it, but I have a copy at:
>
>ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/act/incoming/rm-winhelp.tar.gz

The "primary" copy is at the AdaIC at:

  http://www.adaic.org/

Follow the link to the Ada95 standards, then to the WinHelp version of the 
LRM.

I will always send updated versions there first, as I don't know in general 
who might be including it with their own distributions.
-- 
                                        -- Dave Bryan
 
NOTE: Due to unrelenting SPAM, I regret that I have been forced to post with
an encoded address.  Please ROT13 this message to obtain the reply address.
Address also available at http://www.bcpl.net/~dbryan/mailto.html
 
Cyrnfr ercyl gb guvf nqqerff:  wqoelna@nyhz.zvg.rqh

Re: Ada 95 LRM Error?

[Al Christians]

robert_dewar@my-dejanews.com wrote:
> 
> 
> I don't see anyway the interface can be compatible with
> odd non-standard COBOL stuff like this!
> 

There's also the issue of minimum and maximums within the
binary data types.  A cobol pic S9(9) comp will generally be
represented as 32-bit integer, and the corresponding Ada type 
will have digits 9. But the 32-bit integer can hold some 10-digit
values. IDK which Cobol compilers do how much to prevent these
from actually existing -- I suppose it depends on how much run-time
type checking is turned on in the programs. I assume that these 
values, if they exist, should cause an error of some kind if 
Interfaces.Cobol comes across them.   

Al

Interfaces.Cobol (Was LRM Error?)

[Al Christians]

Richard D Riehle wrote:

>          05 Some-Number     PICTURE  S99V99 USAGE DISPLAY.
>          05 Some-String     PICTURE  9(6).
>
> We may freely MOVE  (actually MOVE means "copy") the numeric data
> to the string data without regard to the typing.  On the other hand,
> we will get a compile time error if we try to do arithmetic on the
> string. 

A field that contains 9's only is numeric and can be used for arithmetic
even if it is named Some-String.  And USAGE DISPLAY just tells how the
data is to be stored, not how it is to be used. So, you can do math on
either of the two fields above. 

> 
>  The people who worked on this package had their work cut out for them.

I agree 100%.

>  They seem to have done it well, given the huge differences between the
>  COBOL language and Ada.

Anybody know how much use this package gets?  I'd be interested to
know how well it works in practice.  How many Ada compilers other than 
GNAT come with it?  Do vendors of compilers that don't provide it get
any requests for it?

Looking at the example in the LRM, I doubt that it gets heavy use as 
illustrated there.  The example shows creating instances of the generic 
conversion routines for each field to convert.  If generics eat up 
memory, this will be quite a pig to interface to a big Cobol system (say 
100's of files, many thousands of fields) -- I think we'd find another 
way to do it. 

One alternative is to use Cobol copybooks to generate a wrapper to 
Interfaces.Cobol for each Cobol copybook, but to only create one 
instance of the generic converter for each distinct set of Cobol 
attributes.  This would be pretty good, but for a system with many 
copybooks, you would also want have to avoid duplication between 
files.  But I'd guess that the number of distinct Cobol formats 
wouldn't go too far up into the hundreds often.

I think I'm going to just write a wrapper for Interfaces.Cobol that
uses one instance of each of three generics -- for numeric, binary, 
and packed data, and machine generate the get and set functions that 
invoke the wrapper.  Anyone else already cracked this nut or otherwise 
interested?

Al

Re: Ada 95 LRM Error?

[Richard D Riehle]

In article <36AFC42A.57696F4D@easystreet.com>,
	Al Christians <achrist@easystreet.com> wrote:

>Richard D Riehle wrote about Interfaces.Cobol:
>> 
>>  As it is, the package is defined so it conforms to the conventions of
>>  typical COBOL programming.
>> 
>
>But if I put non-numeric data into a Numeric, it will flunk the
>Valid() test, right?
>
>Since you speak of 'typical COBOL programming', can you enlighten me a 
>little about why this interface looks the way it does?  
>
 "Well, now, then, there ..."

 COBOL is not a strongly-typed language.  There are, of course, data
 types in the form of PICTURE characters, but a COBOL programmer has
 great latitude in performing operations that mix alphanumeric numbers
 and ordinary alphanumeric characters.

           05 Some-Number     PICTURE  S99V99 USAGE DISPLAY.
           05 Some-String     PICTURE  9(6).

 We may freely MOVE  (actually MOVE means "copy") the numeric data
 to the string data without regard to the typing.  On the other hand,
 we will get a compile time error if we try to do arithmetic on the
 string.  The rules for this kind of thing in COBOL are actually rather
 complex;  what is truncated, what is left justified or right justified,
 all kinds of interesting permutations.  

 If the data type corresponds to COBOL, USAGE DISPLAY, the example shown
 in the example will work.  This does not mean it is good style.  It
 isn't good Ada style, but this package is intended to assist in the
 interface between Ada and COBOL so a certain amount of flexibility
 is necessary.   

 As for the function, Interfaces.Cobol.Decimal_Conversions.Valid,
 invocation depends on the decimal type used for instantiation as
 well as the actual implementation of type Display_Format.  One 
 reason why this is unusual is COBOL's flexibility in where the
 sign is located in USAGE DISPLAY format. It could be a trailing or
 leading sign.  

 The people who worked on this package had their work cut out for them.
 They seem to have done it well, given the huge differences between the
 COBOL language and Ada.  

 On the positive side, COBOL was designed quite well in the time it was
 conceived.  Consider that it has been one of the most successful
 programming languages ever used.  It would be wonderful if Ada could
 be even a tenth as successful as COBOL.  

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com
 

Re: Ada 95 LRM Error?

[robert_dewar]

In article <78qsvv$pim@dfw-ixnews10.ix.netcom.com>,
  Richard D Riehle <LaoXhai@ix.netcom.com> wrote:

> COBOL is not a strongly-typed language.

Well ... We need to be careful in the Ada community to
distinguish between the notion of strong typing, and the
facilities for declaring types.

COBOL is definitely strongly typed, and the typing rules
will prevent (for example) doing arithmetic on
non-arithmetic items.

What Richard means is that the typing capabilities of COBOL
are weak in the ordinary English sense of the word, but
this is not the same as weak typing in the technical sense.

C is also a strongly typed language in this technical
sense, but again, the facilities for declaring types are
poor, and for example, C chooses to make int and char the
same type, just as Ada chooses to make natural and integer
the same type.

When people say that Ada is strongly typed, they mean two
things:

1. It has a semantic notion of typing at compile time, with
static type checking.

2. It has a well developed typing system, that allows the
programmer to easily create types that take advantage of 1.

It is actually 2 that is the really important issue in Ada,
and indeed I am happy for people to call that strong
typing, but it is important to realize that saying
"language X is not strongly typed" in language wars
discussions may cause confusion of the 1. vs 2. type above,
and it is good to understand this source of confusion, so
that discussions do not get confused.


> There are, of course, data types in the form of PICTURE
> characters, but a COBOL programmer has great latitude in
> performing operations that mix alphanumeric numbers
> and ordinary alphanumeric characters.
>
>     05 Some-Number     PICTURE  S99V99 USAGE DISPLAY.
>     05 Some-String     PICTURE  9(6).
>
>  We may freely MOVE  (actually MOVE means "copy") the
>  numeric data to the string data without regard to the
>  typing.

That's a bit misleading. Such a move is *only* valid if
the sending field contains only digits (this is for
instance clear from figure 49 of the ANSI 77 standard).
A move where other than digits are moved is what Ada
programmers would call erroneous.

Still, the point that Richard is making, which is that this
is not checked at compile time, is valid, and I think it
quite appropriate that the COBOL interface of Ada not try
to enforce compile time restrictions which would not exist
in a normal COBOL environment (there are plenty of
"erroneous" COBOL programs in the world :-)

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada 95 LRM Error?

[Keith Thompson]

robert_dewar@my-dejanews.com writes:
> C is also a strongly typed language in this technical
> sense, but again, the facilities for declaring types are
> poor, and for example, C chooses to make int and char the
> same type, just as Ada chooses to make natural and integer
> the same type.

The general point is correct, but the specific point is not; int and
char are definitely distinct types in C.

Note that there are several possible sources of confusion here.  The
types char and int are assignment compatible, character literals are
of type int, char objects are usually promoted to int in arithmetic
expressions, and char function arguments are promoted to int in the
absence of a prototype.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*>
Qualcomm, San Diego, California, USA  <http://www.qualcomm.com>
I must be a techno-geek.  My mouse is bigger than my phone.

Re: Types (was Ada 95 LRM Error?)

[Richard D Riehle]

In article <yecu2x715hb.fsf@king.cts.com>,
	Keith Thompson <kst@cts.com> wrote:

>The general point is correct, but the specific point is not; int and
>char are definitely distinct types in C.

 Semantics, again.  Yes, they seem to be "distinct types" (i.e.,
 have distinct names) but the next paragraph makes one wonder.

>Note that there are several possible sources of confusion here.  The
>types char and int are assignment compatible, character literals are
>of type int, char objects are usually promoted to int in arithmetic
>expressions, and char function arguments are promoted to int in the
>absence of a prototype.

 This reminds me of a card trick expert at some obligatory social
function.
 No matter what card I select, the card trickster will be able to find
 it through some illusory sleight of hand.  

 My understanding of type, in part, is that a type has,

    1) a name, in scope within some declarative region
    2) a defined set of operations for objects of the name
    3) a defined set of values for objects of the name
    4) a "wall" between objects of the named type and 
              objects with some other type name.

The last characteristic, a wall, is important for type to have any
real meaning.  Ada allows us to get beyond the "wall" through type
conversion, view conversion, and even unchecked conversion, but the 
wall is always there.  In C, there is no wall.  When considered this
way, int and char are not really distinct. C allows the dangerous 
illusion of distinct types, a source of many interesting defects 
in C and C++ software.  

The example of Integer, Natural, and Positive does not meet this test
because subtypes, in the reserved word sense, have no wall between them.
Perhaps int and char are more analogous to Ada entities we define using
the subtype reserved word. 
 
This thread began with a consideration of the type definitions in the
Interfaces.COBOL examples in the Annex B.  Robert Dewar has pointed
out that COBOL does, in fact, have types, abeit somewhat more flexible
types than we find in Ada.  Any attempt to interface between a strongly
typed language and one that is weakly-type, requires some concession
to the characteristics of the weakly-typed language. 

The ability to implicitly promote one type to another does not seem to
me to meet the standards I would expect for "distinct types."  

It is interesting that one can start with a strongly-type language, one
where the default is strong typing, and selectively relax the type model
for some targeted environment. It is harder to start with a weakly-typed
language and  make it strongly-typed.  This is one of the key problems
with C++.  The language starts with the weak typing of C and tries to
overlay a model for strong typing.  The result is a language that, like
the card trickster at the party, seduces the naive programmer into
believing in magic.  

Richard Riehle
http://www.adaworks.com

Re: Ada 95 LRM Error?

[robert_dewar]

In article <yecu2x715hb.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> robert_dewar@my-dejanews.com writes:
> The general point is correct, but the specific point is
> not; int and char are definitely distinct types in C.

Well I was using type and subtype in the Ada sense, which
I agree is a bit confusing, since the notion of type in
C subsumes both ideas. But the critical point of the
meaning of type in Ada is that different types are
not assignment compatible, so in Ada terms, int and char
cannot be considered different types.

The promotion you talk of in C, corresponds to the
conversion of subtypes to the base type in Ada or some
such. It is always difficult to compare languages at
this level of terminology when the terminologies differ.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own