Re: Text_IO for other standard types

["Tarjei T. Jensen" <tarjei@online.no>]

Marin David Condic, 561.796.8997, M/S 731-96 wrote:
> And a related matter: Would it be difficult to implement an
> attribute 'Image for composite types? (At least arrays and records
> - pretty hard to figure out what this would mean for tasks and
> protected types.) The idea being if you want to implement some
> debug code or error handling code in which you want to output a
> message like: "Found a faulty input record: xxxxx" getting an
> ascii image for quick&dirty error checking would be pretty handy.
> Handy without dramatically altering the language or imposing undue
> burden on the compiler.

This would be useful for binary I/O.

> And while we're at it, would there be some food value in requiring
> a few extra predefined types? I'm thinking of predefined Modular
> types similar to predefined Integer types and possibly some
> convenient Decimal Fixed Point types (most commonly used for
> money, I suppose).
> 
> My reasoning for having these and their corresponding predefined
> I/O instantiations is that it would make the language easier to
> teach. Generics and even to some extent type declarations
> themselves can be inaccessible to the beginning programmer or a
> programmer familiar only with more primitive languages. Having
> predefined types for modular numbers would enable one to teach or
> discuss modular math & build simple programs to illustrate this
> without having to delve into the heavier concepts of type
> definition or generic instantiation.
> 
> It doesn't sound to me like this would be a difficult extension to
> Ada and the only potential problem I would anticipate would be the
> possibility of collisions with existing name usage. Any thoughts
> on this subject? Good idea? Bad idea? Hmmmm?

I think the first priority should be to repair the standard I/O library.
I think there is too much unsaid. E.g. Ada does not demand buffered I/O
therefor most vendors seems to think that they should not provide such a
facility. Result; even the most horrible C program outperforms almost
any Ada program. And Ada gets to be known as a sloooooow programming
language. 

Making the standard library buffered would be the single most cost
effective optimization one could do for I/O intensive programs.

The downside of this is that one will need to change the definition of
the standard library in order to be able to flush I/O (e.g. for
prompting), request changes in the size of buffers and the buffering
strategy.

Oh Horror! With these changes one could write a portable text editor in
Ada without any host specific code. Horrors of horrors; we would be able
to turn off input buffering and get access to each character as they are
typed. Transparantly.

Pascal (Pre Turbo Pascal) had the same problem in ancient times. There
was nothing that kept vendors from implementing buffering, but nobody (I
know of) did and the language suffered heavily because of that. Even
Turbo Pascal of today does not buffer I/O without programmer
intervention.

It would be very nice to have a stream base standard library. I assume
it would be easy to connect any stream to any sort of I/O (serial,
socket, text files, etc).


Greetings,

-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!