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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: Text_IO for other standard types Date: 1998/01/19 Message-ID: <98011912191173@psavax.pwfl.com> X-Deja-AN: 317419143 Sender: Ada programming language Comments: To: rosen.adalog@wanadoo.fr X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" X-VMS-Cc: SMTP%"rosen.adalog@WANADOO.FR",CONDIC,CONDIC Newsgroups: comp.lang.ada Date: 1998-01-19T00:00:00+00:00 List-Id: Jean-Pierre Rosen 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 =============================================================================