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,4b862d91ff93feff
X-Google-Attributes: gid103376,public
From: mfb@mbunix.mitre.org (Michael F Brenner)
Subject: Re: Text_IO for other standard types
Date: 1998/01/18
Message-ID: <69t2fe$m51@top.mitre.org>#1/1
X-Deja-AN: 317069433
References: <98011512220569@psavax.pwfl.com>
 <69q6k3$8fk$1@peuplier.wanadoo.fr> <dewar.885058658@merv>
Organization: The MITRE Corporation, Bedford Mass.
Newsgroups: comp.lang.ada
Date: 1998-01-18T00:00:00+00:00
List-Id: <comp.lang.ada>



>>    (And, P.S.: Try explaining generic instantiation to a room full of
>>    non-programming engineers just so you can do simple I/O exercises
>>    with them and see how difficult this is!
 >It's not. Just give it as a "cooking recipe". The first day, I explain that
 >to get IO's on type Counter, they have to use the magic formula:
 >   package Counter_IO is new Integer_IO (Counter);
 >and that they will later discover why (I don't even tell it's a generic
  instanciation). People accept it without problems.
>> I strongly dislike the magic cooking recipe approach. Yes, you can get
>>students to accept it, but in my opinion damage is done since you
>>compromise the critical principle that people should understand what
>> they are doing.


 I agree with Robert that something as complicated as generic
 intantiation of text_io should be done FIRST as an cook-book
 example. Later, it will be fully explained and understood,
 but the example is essential In The Beginning.

 The FORTRAN instructor had to code your first FORMAT statement for 
 you and it was quite a few minutes into the course that you could understand that first FORMAT statement.


>>> ...use the Image attribute

 This is usually better.

 I agree that the image attribute should be used when possible,
 and is preferable to using text_io in the beginning as well
 as in actual applications. When it is not possible to use
 the image attribute, it is often possible to program your 
 own IMAGE Function. This leaves your ADT packages PURE.

 Still another alternative would be to program some kind of 
 output procedures called, perhaps, TELL, DUMP, TRACE, PUT,
 or whatever you would prefer. However, this would take a
 PURE ADT package and degrade it all the way down to 
 ELABORATE_BODY, losing the optimizations as well as the
 simplicity, and the elaboration-error-less-ness of the PURE
 package. 

 But sometimes it seems that you have to have a TELL, when 
 the data objects of that class are so long that returning
 the full IMAGE as a string would be notoriously inefficient.
 For example, when it comes time for the annual comprehensive
 report, no matter how consistent it is with this scheme, 
 one probably should not write:

    text_io.put_line (image (sort (whole_database)));

 unless you have enough RAM left over, say, to store
 your years in 4-digit format :)