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

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

"Tarjei T. Jensen" <tarjei@ONLINE.NO> writes:
>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.
>
    An admirable goal. I'm not sure that the facilities aren't already
    available in Text_IO to write a transparent text editor (Please
    make it look like TPU!) but it may be lack of consistent
    implementation that kills you. You can do cursor motion now by
    outputting escape sequences - except that you are then dependent
    on some specific terminal standard (VT100, usually). There is a
    "Get_Immediate" call which will let you read a keystroke at a
    time, but my experience is that it's implementation is a little
    inconsistent/buggy/slow. (Does it require echoing of the
    character? Shouldn't it not require a CR before reading the
    keystroke? What about "special" keys, like F-keys, arrows, ctrl,
    alt, etc?) Again, your code is likely to get hung up on a specific
    keyboard standard as well.
>
>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).
>
    Don't forget that there is, in fact support for streams and
    Stream_IO, the goal of which was to give you exactly the ability
    you are talking about. Of course there are always limitations on
    this sort of thing because it becomes very hardware/os dependent.

    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]

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: Text_IO for other standard types

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

Jean-Pierre Rosen <rosen.adalog@WANADOO.FR> writes:
>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.
>
    I afraid I would have to respectfully disagree for a couple of
    different reasons.

    1) You already have *some* predefined types which pretty much get
    used the same way that predefined types in other languages are
    used. I need to get some relatively simple job done with no great
    concern for portability, etc., so I declare something to be of
    standard type Float or Integer. So what's wrong with a predefined
    Modular type or two which correspond in size to the predefined
    Integer types?

    2) While I would agree that the concept of data types and specific
    types for specific purposes (apples & oranges, as you say) is, in
    general, A Good Idea, there is such a thing as taking something
    too far. Not all programs are million line behemoths which will be
    maintained for dozens of years. Some are quite simple or may be
    just a training exercise where the concept might be to show how to
    build code to solve some equation where having to stop to explain
    the whole business of data type definitions might only distract
    you from the problem at hand.

    3) Not all students are CS majors who need to be steeped in the
    theoretical culture because they will be designing the future. In
    my particular case here at Pratt, I was busy trying to get a bunch
    of mechanical & electrical engineers up to some passing familiarity
    with Ada so that when they saw it they would have some
    understanding of it. These engineers have had some moderate level
    of exposure to programming with FORTRAN or Basic and might need to
    occasionally hack together a few lines of code to execute some
    control module or some other light duty job that must be done in
    an Ada environment. I need to communicate to these engineers that
    anything they can do in FORTRAN is just as easy and just as simple
    in Ada. These guys are just barely accepting of the notion that
    they should have to declare a variable before they use it. Forcing
    them to define the type in the interest of theoretical purity is
    only going to frustrate them more.

    (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! They generally instantly
    hate Text_IO because it isn't as simple as what they are used to
    and they really can't cope with generic instantiations of
    Float_IO, etc. The instantaneous reaction is: "All I wanted was a
    simple little program to compute 'Y := M * X + B" and print the
    result. Why do I need all this junk getting in my way?!?!?!" You
    don't win if you turn them off from wanting to have anything to do
    with the language.)

    4) Even with someone who is going to be a CS major, there is still
    a point where they are just starting out and getting them
    comfortable with the notion of a "variable" as a simple box in
    which to keep data, predefined types are very useful. Getting them
    familiar with Modular or Decimal arithmetic without involving type
    definitions can also be helpful because you are free to talk about
    how modular math works and not confuse things with how type
    definitions work or why you need them.

    So I guess that while I can agree with your opinion about type
    definitions being a very important concept, I'd have to disagree
    that every kind of student or every kind of application should be
    forced into doing this right from the get-go. Hence, this is why I
    would like to see more predefined types and predefined
    instantiations of the I/O routines. It's not hard to implement,
    other languages provide it, it isn't inconsistent with what has
    gone before and there are legitimate uses for it.

    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

[Nick Roberts]

You may well have already thought of or used this, but might I suggest that
you cobble together your own little package Handy (suggestion below), and
then your recalcitrant engineers need only 'with Handy' to get the stuff
they need.

   with Ada.Text_IO
   package Handy is
      type Handy_Modular is mod 2**32;
      package Handy_Modular_IO is new Ada.Text_IO(Handy_Modular);
      use Handy_Modular_IO;
      -- and so on ...
   end Handy;

I would add, however, that this ploy in no way detracts from your argument,
which I think has some merit.  What argument can there be for not providing
a predefined modular type, partner to the predefined integer type Integer? 
I think it has to be conceded that a predefined fixed-point type would not
be sensible.  One of the annexes does actually specify a predefined decimal
type, doesn't it?
-- 

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


Marin David Condic wrote at length about the difficulty of convincing
programmers used to more pragmatic languages to adopt Ada.

Re: Text_IO for other standard types

[Robert Dewar]

Marin says

<<    (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! They generally instantly
    hate Text_IO because it isn't as simple as what they are used to
    and they really can't cope with generic instantiations of
    Float_IO, etc. The instantaneous reaction is: "All I wanted was a
    simple little program to compute 'Y := M * X + B" and print the
    result. Why do I need all this junk getting in my way?!?!?!" You
    don't win if you turn them off from wanting to have anything to do
    with the language.)
>>

ALl these arguments miss the point entirely. Yes, it is a good idea to
have a few very standard predefined types, for all the reasons you
mention (that is why incidentally we have packages like 
Ada.Integer_Text_IO, to avoid the scenario in your point above.

But JPR's points are spot on when it comes to adding *more* standard
types. The standard predefined types are just fine for the purposes
of teaching etc. Certainly I think most people teaching Ada have found
them useful as a starting point. But the idea that it would be easier
to teach Ada if it had predefined modular types seems pretty bogus to
me. Modular types belong quite far along in the treatment, and by that
time you should certainly have introduced the notions of type abstraction!

Robert Dewar

Re: Text_IO for other standard types

[Robert Dewar]

Marin says

<<    1) You already have *some* predefined types which pretty much get
    used the same way that predefined types in other languages are
    used. I need to get some relatively simple job done with no great
    concern for portability, etc., so I declare something to be of
    standard type Float or Integer. So what's wrong with a predefined
    Modular type or two which correspond in size to the predefined
    Integer types?
>>

What is wrong with the predefined modular types that are in the language
now (see Interfaces). I assume it is clear why you would just as soon
not have these types in Standard!

Re: Text_IO for other standard types

[Nick Roberts]

I think the answer may be that the modular types defined in the Interfaces
package do not tell anyone which type corresponds to the most natural
modular type for the target machine (e.g. because of the machine's bus
width or CPU register size), as the type Integer is assumed to do for
integer types.

There are occasions when knowing such a 'natural' modular type would be
helpful (e.g. programming 'bignums'); the provision of an appropriate
predefined modular type would therefore be genuinely helpful.

-- 

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


Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.884903275@merv>...
> What is wrong with the predefined modular types that are in the language
> now (see Interfaces). I assume it is clear why you would just as soon
> not have these types in Standard!

Re: Text_IO for other standard types

[Robert Dewar]

Nick Roberts said

<<There are occasions when knowing such a 'natural' modular type would be
helpful (e.g. programming 'bignums'); the provision of an appropriate
predefined modular type would therefore be genuinely helpful.
>>

But surely this is a perfect example where you do NOT want predefined
types to be used at all.

Certainly a reasonable declaration in this case would be:

   type x is mod 2 ** Integer'Size;

but I would oppose adding this to the language.

P.S> if you really, really want these predefined types, and are using
GNAT, have a looik at System.Unsigned_Types. Of course you are not supposed
to use these secret implementatoin packages :-)

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: 4626 bytes --]


Marin David Condic, 561.796.8997, M/S 731-96 a �crit dans le message
<98011512220569@psavax.pwfl.com>...
>    I afraid I would have to respectfully disagree for a couple of
>    different reasons.

>
I would respectfully continue to agree with myself :-).
I think this discussion rises from a much deeper issue. From what you wrote,
it appears that you consider predefined types as the "normal" types, and
that user defined types are just an extra burden (or luxury) which i only
cost effective for high security, long-lived, etc. projects. I do not share
that view.

To me, data design is an important part of any design, like algorithmic
design. Any type you use has constraints, and you should choose a data type
that matches the requirements. Note that you *may* choose a predefined type,
provided it's a design decision, if your requirements are:
  - No big constraints on range (or accuracy for floating-point types)
  - You are actually happy that the type changes depending on how powerful
the machine is (big ranges on big machines, small ranges on small machines)
  - You want your type to match closely the hardware (for efficiency or
interfacing reasons).
Note that the types defined in System.Interfaces might be a better match
than the predefined types in this case.

In the general case however, you have some clear constraints on the type,
and these must be translated into the code. The trouble is that too often,
people think of "Integer" as the mathematical integer. Of course, they know
that it is limited, but they tend to think "well it's an integer"
(mathematically) and implement it as an Integer (predefined type). In
general it works, because Integer is "big enough" (until it bombs), but
wastes space. How many people use 32 bits to count 0 to 10! (I know, we have
lots of memory, but...). The big issue here is that it is actually an
implicit design choice, i.e. one that does not result from a design
decision, but simply from not considering alternatives.

In most other languages, predefined types are the only basic types
available. It is an important benefit of Ada that data analysis can be
applied also to basic types, and from a pedagogical point of view, it is
important to teach that right from the start. From my experience in teaching
Ada (and I gave my first Ada course in 1979 !), if you start teaching with
predefined types, people stick to them, even if you teach them more evolved
types later. Actually, I found it a very bad teaching practice to introduce
something, and later say that it should not be used. Therefore, I always
start by teaching user defined types, and just mention later: "oh, by the
way, for some special purposes (like indexing string), you have a predefined
integer type named Integer"

Are user defined types such a burden ? I think not. During the first
exercise session, people complain about those declarations and type
incompatibilities that keep preventing their program from compiling.
Typically, they need 2 to 3 hours to get their first succesful compilation.
At that point, they usually turn to me and say "now, we'll have to debug
that thing". And guess what ? In approximately 90% of the cases it works at
first run. And then, the student turns to me and tells me: "well, maybe all
those controls were really useful after all".

In short:
YES, I would declare:
   type Counter is range 0..10;
even in a 10 lines program. And there is a good reason for this (also an
important teaching subject!): If your mind is really quality-oriented, you
don't wonder whether it's worth doing things cleanly; you *always* do it
this way. And from my programming experience, I have a collection of
memories where I later regretted to have not done things properly right from
the start. I have *no* memories of regretting having done things properly.

>    3) Not all students are CS majors who need to be steeped in the
>    theoretical culture because they will be designing the future.

Once again, I found user defined types extremely *easy* to understand by
beginners. It's rather those with CS majors who have troubles getting rid of
them...
>
>    (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.

Re: Text_IO for other standard types

[Geert Bosch]

Nick Roberts wrote:
 ``There are occasions when knowing such a 'natural' modular type would be
   helpful (e.g. programming 'bignums'); the provision of an appropriate
   predefined modular type would therefore be genuinely helpful.''

Robert Dewar replied:
 ``P.S> if you really, really want these predefined types, and are using
   GNAT, have a looik at System.Unsigned_Types. Of course you are not supposed
   to use these secret implementatoin packages :-)''

When I would need to program "bignums", I would just write a nice
package spec and then use the Uintp package in the body.  I would
rate this GNAT package as top-secret and re-using it is ethically
questional and borders on the obscene when you are supposed to be
a programmer. :-) ;-) :-)

Regards,
   Geert

Re: Text_IO for other standard types

[Robert Dewar]

JPR says

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

Fortunately, there is a perfectly comfortable way to deal with this, which
is to use the Image attribute, so people can write

	My_Type'Image (val)

Sure, you don't get nice formatting that way, but you can leave nice
formatting for later.

Note that the extension of Image to cover floating-point types is a nice
improvement for this style of teaching.

This is certainly not a big deal, but I see no reason for introducing
magic cookbook formulae when it is unnecessary.

Re: Text_IO for other standard types

[Robert Dewar]

Geert says

<<When I would need to program "bignums", I would just write a nice
package spec and then use the Uintp package in the body.  I would
rate this GNAT package as top-secret and re-using it is ethically
questional and borders on the obscene when you are supposed to be
a programmer. :-) ;-) :-)
>>

Actually uintp is not that efficient, and is not architecture tuned. 
It is very hard to write efficient multiple precision arithmetic
in Ada or most other high level languages, because of not having access
to double length operations and the carry flag.

However, it certainly would be handy to have a version of Uintp suitable
for use by general applicatoin programs (one for the to-do list :-)

Re: Text_IO for other standard types

[Michael F Brenner]

>>    (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 :)

Re: Text_IO for other standard types

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

Jean-Pierre Rosen <rosen.adalog@WANADOO.FR> writes:
>I would respectfully continue to agree with myself :-).
>I think this discussion rises from a much deeper issue. From what you wrote,
>it appears that you consider predefined types as the "normal" types, and
>that user defined types are just an extra burden (or luxury) which i only
>cost effective for high security, long-lived, etc. projects. I do not share
>that view.
>
    Well, I'm not sure that's where I was heading. I agree that user
    defined types for a wide range of situations makes sense. In most
    situations where software is beyond trivial or throw-away or
    purely illustrative, it pays to explicitly define the required
    accuracy, range, etc. and to avoid mixing things that shouldn't be
    mixed. (Although I've seen this taken to extremes: "type
    Miles_Type... type Hours_Type..." And why imply that you don't
    want to compute Miles/Hour?)

    What I'm saying is that the predefined types do in fact have
    legitimate use - especially when trying to teach raw beginners. If
    they had no legitimate use, then I'd have to presume you would
    argue that Ada should eliminate the types Integer, Float, etc. and
    all programs everywhere should be required to define every data
    type they require. This of course would only end up creating the
    situation where every programmer would have a package defined
    called "package My_Standard is..." that they would always with/use
    and circumvent the intent. I've seen exactly this done in
    beginning-student-level Ada books where the author will develop
    something like "package Easy_Text_IO is" and provide
    instantiations, etc. in order to avoid having to talk about the
    complex issues until after the students have gotten past the
    simplest stuff.
>
>To me, data design is an important part of any design, like algorithmic
>design. Any type you use has constraints, and you should choose a data type
>that matches the requirements. Note that you *may* choose a predefined type,
>provided it's a design decision, if your requirements are:
>  - No big constraints on range (or accuracy for floating-point types)
>  - You are actually happy that the type changes depending on how powerful
>the machine is (big ranges on big machines, small ranges on small machines)
>  - You want your type to match closely the hardware (for efficiency or
>interfacing reasons).
>Note that the types defined in System.Interfaces might be a better match
>than the predefined types in this case.
>
    Yeah. Sure. I agree here. Except that not everything needs to be
    "designed". Occasionally (and I'd think rather rarely) things can
    be organically grown. I've often hacked tiny pieces of code where
    the whole intent was simply to build a driver to test something
    else or to check out how some specific language feature actually
    worked, etc. The code simply needs to be built quickly, executed
    and then discarded. Here, predefined types are handy. As they
    might be in some other cases - including educational settings.

    I think you meant to type "Interfaces" - not "System.Interfaces"
    since the scope is Standard. Yes, you get some useful predefined
    types there - but I still think there ought to be a few more
    "intrinsic" types (scope Standard, so that you don't have to do a
    with/use and needn't explain it to the beginner) and corresponding
    pre-instantiations of the appropriate Text_IO packages. It's a
    convenience feature like power windows on a car: You don't really
    need it, eventually they will break down, but in the mean time
    they keep the kids amused.

>>
>>    (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.
>
    Been there. Done that. Got the T-Shirt. The engineers are seldom
    happy with "Don't try to understand it - just put this into the
    code and everything will be O.K." Audiences can vary considerably
    in what they will accept without question.

    I guess my point is that while you can't argue that Ada lacks
    enough features to program anything you want, a case can be made
    that some "convenience" features might make it a little more "user
    friendly" in some domains.

    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
=============================================================================
    "A verbal contract isn't worth the paper it's written on."
        --  Samuel Goldwyn
=============================================================================

Re: Text_IO for other standard types

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

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>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.
>
    When the students in question are a) engineers and/or b) have
    experience with some other language (usually Fortran or Basic, in
    my venue) they typically won't sit still for "just use this and
    don't question it." Hence you look for ways of avoiding discussing
    generic instantiation until you've gotten them comfortable with
    the basics.

>Fortunately, there is a perfectly comfortable way to deal with this, which
>is to use the Image attribute, so people can write
>
>        My_Type'Image (val)
>
>Sure, you don't get nice formatting that way, but you can leave nice
>formatting for later.

    I've used this approach for the really introductory part of my
    course. You don't have to explain anything more serious than "with
    Text_IO/use Test_IO" and the associated Get_Line/Put_Line calls.
    It seems to be acceptable and you can show your garden variety
    engineer how to code up a little program to compute Y = M * X + B
    and it is only slightly more complicated than a Fortran
    equivalent. Maybe less so since you've got to deal with Fortran's
    I/O and that isn't a whole lot simpler than Get/Put with 'Image
    and 'Value. In any case the attributes are a big help in getting
    the students familiar with the basics.

>
>Note that the extension of Image to cover floating-point types is a nice
>improvement for this style of teaching.
>
    Yeah Verrily and Forsooth! I am eternally grateful for getting the
    'Image attribute on floating-point types. I'd like to see it
    available for just about any type but I have no notion as to how
    tough it would be to implement for compound types. (This would be
    useful for quick&dirty data dumps when debugging or producing
    throwaway hacks)

>This is certainly not a big deal, but I see no reason for introducing
>magic cookbook formulae when it is unnecessary.
>
    I like using the attributes to get around cookbook rituals, but I
    still have a problem when I eventually have to get to explaining
    Text_IO. The usual reaction is that Text_IO is painful. (I won't
    argue technical merit - that's just the standard issue response:
    "Why does this have to hurt so bad?") What I would *like* to do is
    be able to explain Text_IO without having to simultaneously
    explain generic instantiation. So if you had a useful set of
    predefined types and predefined instantiations of the generic I/O
    packages for all the predefined types and this was standard Ada
    (to avoid "this only works in my class because I gave you some
    code") it would be a lot easier to explain. I could approach it
    from the standpoint of: with/use the appropriate packages for the data
    types in question and you will get the following I/O procedures
    available...

    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
=============================================================================
    "A verbal contract isn't worth the paper it's written on."
        --  Samuel Goldwyn
=============================================================================

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: 1866 bytes --]


Marin David Condic, 561.796.8997, M/S 731-96 a �crit dans le message
<98012009510954@psavax.pwfl.com>...
>Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>>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.
>>
>    When the students in question are a) engineers and/or b) have
>    experience with some other language (usually Fortran or Basic, in
>    my venue) they typically won't sit still for "just use this and
>    don't question it." Hence you look for ways of avoiding discussing
>    generic instantiation until you've gotten them comfortable with
>    the basics.
Of course, it may depend on the kind of students you have. Mine are
engineers in a short (6 days) course. So "you'll see that later" really
means "you'll see that tomorrow", something that is (in my experience)
easily accepted.

I won't discuss every point in this thread because it is getting quite long,
however I think there is an interesting issue, from a pedagogical point of
view. Personnally, I use 'image with caution, because I think that it is
much better to use the true IO packages. Some of the reasons for that are:
1) IO packages have more evolved formatting capabilities.
2) 'image may have unfortunate effects if your line length is bounded (a
value can be wrapped around an end of line)
3) IO packages have the interesting property that if you write data with a
given loop, you can copy the loop and change every "put" into a "get" to
read the data back.

So, the pedagogical issue boils down to whether it is better to tell "do it
this way, you'll understand later why", or "do it this way" and later tell
"don't do it the way I mentionned before". Personnally, I prefer the first
approach.