Text_IO for other standard types

Text_IO for other standard types

[Marin David Condic, 561.796.8997, M/S 731-96]

    So we have a standard type Integer and a corresponding package
    Ada.Integer_Text_IO. We have a standard type Float and a
    corresponding package Ada.Float_Text_IO. We have a standard type
    Boolean but no corresponding package Ada.Boolean_Text_IO? Or for
    that matter, the standard type Duration and no
    Ada.Duration_Text_IO.

    Oh sure, I can make my own declarations for these things and its
    pretty trivial. But it seems like it would be good to have all
    this stuff in one place - under the parent package Ada. (I don't
    believe it is legal for the end user to extend the package Ada.
    GNAT chokes on attempts to do so...) Would it be a bad idea to
    require a Ada.xxx_Text_IO package for any predefined elementary
    type xxx? I think it would make life easier and would simplify
    things for a student just starting out learning the language.

    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.

    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?

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "I filled out an application that said, 'In Case Of Emergency
    Notify'. I wrote 'Doctor'... What's my mother going to do?"
        --  Steven Wright
=============================================================================

Re: Text_IO for other standard types

[Tarjei T. Jensen]

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!

Re: Text_IO for other standard types

[Nick Roberts]

Perhaps what would be handy would be for Universities etc, to get together
and agree upon a standard packages (or suite of packages) to support
teaching the language in stages. I feel sure there will, in the future, be
a significant requirement for programmers who have knowledge of only a
subset of the language; such a package or suite would then be invaluable.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***

Re: Text_IO for other standard types

[Robert Dewar]

Tarjei said

<<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.
>>

I have no idea what buffering means semantically, other than the
language allowing buffering (clearly Ada does which is why there
is a flush operation), but you cannot somehow insist on buffering,
what on earth would be the point. A language standard is not in the
business of providing possibly faulty advice on how to implement
things efficiently (buffering can slow things down on some systems
by introducing an extra level of unneceessary copying).

As for Ada I/O being slower than C I/O, how about a very specific
example of what you are talking about. Usually when we look at exact
code, we find the situation is not at all what it sounded like from
a rough general description of this kind.

Re: Text_IO for other standard types

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]


Marin David Condic, 561.796.8997, M/S 731-96 a �crit dans le message
<98010912585349@psavax.pwfl.com>...
>    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.
NO, NO, NO, NEVER.
One of the most important things in Ada teaching is to train people to
design types according to the problem domain, and forget about predefined
types. Forcing people to forget about Integer is in my experience one of the
most difficult things.
OTOH, teaching a total newcomer about type definitions, and about the fact
that you cannot add apples and oranges is easy, easier than to an
experienced programmer.

More predefined types would be a help only if you teach Ada the same way
that you teach other languages, and (IMHO) that's the last thing to do.

Re: Text_IO for other standard types

[Tarjei T. Jensen]

Robert Dewar wrote:
> 
> Tarjei said
> 
> <<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.
> >>
> 
> I have no idea what buffering means semantically, other than the
> language allowing buffering (clearly Ada does which is why there
> is a flush operation), but you cannot somehow insist on buffering,
> what on earth would be the point. A language standard is not in the
> business of providing possibly faulty advice on how to implement
> things efficiently (buffering can slow things down on some systems
> by introducing an extra level of unneceessary copying).

Which system will not benefit from doing fewer, but larger writes or
reads when doing general I/O such as screen writes and reading and
writing to files?

As the buffering have few if any "user servicable parts" it would be
perfectly reasonable to ignore some of the buffering requests and
perhaps even raise exceptions on others.

This is the usual case of someone somewhere MIGHT not benefit, so
therefore nobody can have it. Despite the obvious advantages.

> As for Ada I/O being slower than C I/O, how about a very specific
> example of what you are talking about. Usually when we look at exact
> code, we find the situation is not at all what it sounded like from
> a rough general description of this kind.

Which translated should mean "No, we don't do any buffering". That is a
pity, because it would be a morale boost for many newbees that their Ada
programs were as fast on I/O as anybody elses C or C++ programs without
having to do any tweaking.

I think that the spitbol pattern matching library and I/O buffering
could have been a powerful combination. Assuming of course that the
library has a sensible interface.


Greetings,

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

Re: Text_IO for other standard types

[Robert Dewar]

Tarjei said

<<Which system will not benefit from doing fewer, but larger writes or
reads when doing general I/O such as screen writes and reading and
writing to files?

As the buffering have few if any "user servicable parts" it would be
perfectly reasonable to ignore some of the buffering requests and
perhaps even raise exceptions on others.

This is the usual case of someone somewhere MIGHT not benefit, so
therefore nobody can have it. Despite the obvious advantages.
>>


You still miss the point. Buffering is not a language feature except
to the extent that you could imagine defining the language in a way
that made it impossible to buffer, but Ada clearly allows buffering
(that is why there is a flush operator).

In GNAT, our normal approach is to buffer files except in the case
where the output is to standard output *and* the output is directed
to a non-regular file (typically the terminal). Certainly users,
*especially* beginners, find it easier if terminal output is not
buffered by default.

The GNAT manual also outlines how to control buffering if you don't
like the default.

Tarjei, this really seems like a tempest in a teapot! You are foucussing
here on buffering, but I think you should be focussing on efficiency.
What would be helpful is to write a program in C and Ada that shows
up the efficiency differences you are talking about, and then analyze
them. Most likely, to the extent such efficiency differences exist, they
have little to do with buffering, but are rather the effect of a much
higher level semantics on the Ada side, e.g. line/page counting. Actually
Stream_IO is a much better semantic level match to ordinary C stream
I/O and that is part of the reason it was put into the language.

Re: Text_IO for other standard types

[Robert Dewar]

Tarjei said

<<Which translated should mean "No, we don't do any buffering". That is a
pity, because it would be a morale boost for many newbees that their Ada
programs were as fast on I/O as anybody elses C or C++ programs without
having to do any tweaking.

I think that the spitbol pattern matching library and I/O buffering
could have been a powerful combination. Assuming of course that the
library has a sensible interface.
>>

I guess there is a language problem here. I said no such thing, and if
you read the GNAT manual, you will find a perfectly clear statement on
the situation in GNAT (which is that regular files are by default
buffered). So this "powerful combination" is there to use (assuming
you think the interface is sensible :-)

Re: Text_IO for other standard types

[Tarjei T. Jensen]

Robert Dewar wrote:
> In GNAT, our normal approach is to buffer files except in the case
> where the output is to standard output *and* the output is directed
> to a non-regular file (typically the terminal). Certainly users,
> *especially* beginners, find it easier if terminal output is not
> buffered by default.

This sounds eminently sensible. When I program in C I try to remember to
first flush stdout then print the error message and finally flush stderr
before exiting on error conditions. However as also noted below, this is
of little value for those distributing code unless the other vendors
does the same.

> 
> The GNAT manual also outlines how to control buffering if you don't
> like the default.

I still think it should be an official way of manhandling buffering. In
many applications there is a marked improvement in performance when
using largish buffers.

> 
> Tarjei, this really seems like a tempest in a teapot! You are foucussing
> here on buffering, but I think you should be focussing on efficiency.
> What would be helpful is to write a program in C and Ada that shows
> up the efficiency differences you are talking about, and then analyze
> them. Most likely, to the extent such efficiency differences exist, they
> have little to do with buffering, but are rather the effect of a much
> higher level semantics on the Ada side, e.g. line/page counting. Actually
> Stream_IO is a much better semantic level match to ordinary C stream
> I/O and that is part of the reason it was put into the language.

I'm focusing on buffering because it would be the easiest one to fix.
And since I have been around for a while I think I have noticed the
effect on languages which did not support buffering. Apparantly you have
fixed it in your implementation, but have the other vendors done
likewise? If not we end up programming in GNAT Ada, Aonix Ada,
Intermetrics Ada, etc.


Greetings,

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

Re: Text_IO for other standard types

[Robert Dewar]

Tarjei said

The page/line stuff is not exactly nonsense, but a very strange priority
of allocating resources. It is almost exclusively useful for generating
reports. It's about as useful as the bit_order attribute - if my
interpretation of 13.5.3 matches reality.

   Your interpretation may be wrong, this attribute is quite useful

Isn't it usually the I/O time that is dominant in situations like this?
BTW. I have yet to inspect the actual code.

   Not at all, it is much more likely that such an application is CPU bound
   (one that does formatted IO)

Re: Text_IO for other standard types

[Dale Stanbrough]

Robert Dewar writes:

[...but are rather the effect of a much
 higher level semantics on the Ada side, e.g. line/page counting."

Having looked at the body of Text_IO once I have often thought
that a 

	Pragma No_Stupid_Text_IO_Stuff;

or perhaps more sensibly...

	Pragma Restriction (Simple_Text_IO);


which would enforce no page/line counting in your code, would
be a much welcome addition to the language. This allows people
to maintain old code, but lets us throw away all that unneeded
baggage (did anyone every actually use line/page counting enough
to make it worthwhile?)


Dale

Re: Text_IO for other standard types

[Robert Dewar]

Dale said

<<Having looked at the body of Text_IO once I have often thought
that a

        Pragma No_Stupid_Text_IO_Stuff;

or perhaps more sensibly...

        Pragma Restriction (Simple_Text_IO);


which would enforce no page/line counting in your code, would
be a much welcome addition to the language. This allows people
to maintain old code, but lets us throw away all that unneeded
baggage (did anyone every actually use line/page counting enough
to make it worthwhile?)
>>

It would make a nice student project to redesign the interface to remove
the page/line nonsense, then recode the body (it is more than jsut
removing code, you can in some cases do things multiple characters at
a time which are now done one character at a time because of the page/line
stuff, you can also remove a lot of junk used to support strange cases.

Then the project would measure the speed gain. I share Dale's suspicion
that it would be substantial. 

Re: Text_IO for other standard types

[Tarjei T. Jensen]

Robert Dewar wrote:
> 
> It would make a nice student project to redesign the interface to remove
> the page/line nonsense, then recode the body (it is more than jsut
> removing code, you can in some cases do things multiple characters at
> a time which are now done one character at a time because of the page/line
> stuff, you can also remove a lot of junk used to support strange cases.

I second this. It would be a welcome addition.

The page/line stuff is not exactly nonsense, but a very strange priority
of allocating resources. It is almost exclusively useful for generating
reports. It's about as useful as the bit_order attribute - if my
interpretation of 13.5.3 matches reality.


> Then the project would measure the speed gain. I share Dale's suspicion
> that it would be substantial.


Isn't it usually the I/O time that is dominant in situations like this?
BTW. I have yet to inspect the actual code.

Greetings,

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

Re: Speeding up Text_IO

[Nick Roberts]

I wonder if it might be an idea to slightly redefine the behaviour of
Get_Immediate, so that it does not do any line or page counting, and also
so that it specifically does not interpret end-of-line or anything else. 
Maybe a Put_Immediate could be provided for the equivalent simplicity of
output?

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***

Re: Speeding up Text_IO

[Robert Dewar]

Nick said

<<I wonder if it might be an idea to slightly redefine the behaviour of
Get_Immediate, so that it does not do any line or page counting, and also
so that it specifically does not interpret end-of-line or anything else.
Maybe a Put_Immediate could be provided for the equivalent simplicity of
output?
>>

I wonder if it might be an idea to slightly read the existing RM :-)

9   procedure Get_Immediate(File : in  File_Type;
                            Item : out Character);
    procedure Get_Immediate(Item : out Character);

        10   Reads the next character, either control or graphic, from the
        specified File or the default input file.  Mode_Error is propagated
        if the mode of the file is not In_File.  End_Error is propagated if
        at the end of the file.  The current column, line and page numbers
        for the file are not affected.


As for Put_Immediate, stream output to standard output has the effect
you want, I see no reason to decorate Text_IO with more stuff!