Re: Text_IO for other standard types

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

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