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,45abc3b718b20aa3 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Two ideas for the next Ada standard Date: 1996/08/30 Message-ID: X-Deja-AN: 177488934 references: <5009h5$ir4@netline-fddi.jpl.nasa.gov> <506ceh$25o4@info4.rus.uni-stuttgart.de> <506svr$h1v@linus.mitre.org> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-08-30T00:00:00+00:00 List-Id: In article <506svr$h1v@linus.mitre.org>, Michael F Brenner wrote: >In additions to these two ideas, we should consider two more: > >(1) Efficiencies required for systems programming: >(1a) Permit placing a variable at an absolute physical machine >address (as opposed to a gnat virtual address). This seems like an implementation issue. On systems where physical addresses make sense, an Ada implementation is free to support them. I don't see any advantage in saying something about it in the language standard, since it's highly nonportable anyway. >(1b) Correct the language design error that CHECKED conversion >between signed and unsigned integers may overflow or raise constraint_error. I'm not so sure this is a design error. Anyway, why do you call this an "efficiency" issue? >(1c) Add logical operations (AND, OR, etc.) on signed numbers. Why? >(1d) Make software reuse through generics efficient by REQUIRING >all expressions that would have been static in a non-generic package >to remain static when the package is made generic. In Ada-95, >you lose staticness all over, and, consequently, you lose compile >time computation of most expressions, when you make a package generic. This is confused. Losing staticness does not imply losing compile-time evaluation. Any compiler that uses the macro-expension model of generics will do what you ask here. And of course if you're sharing code, you can't do it, in general. >(1e) Mandate a compiler-independent way to identify a procedure as the >interrupt handler for a given interrupt number. Please explain why the protected-procedures-as-handlers model is insufficient. >(1f) Mandate a standardized way to identify that an INTERFACE >parameter is to be passed by reference. Sounds useful, but you can always use an access type. >(1g) Legalize a compiler-independent way to overlay two variables. Using address clauses to achieve overlays was erroneous in Ada 83, but the Ada 95 RM no longer says that. Nonetheless, you have to make sure your addresses are valid, and that is somewhat implementation dependent. I think you very badly want it that way, since otherwise the compiler would have to generate *very* poor code. >This could be accomplished without offending non-system-programming >purists, who are rightfully concerned with the safety violation >implied by overlaid variables in two steps as follows. First, mandate >that unchecked_conversions generate no code, ... This makes no sense to me. The RM has no notion of "generate code", so how can it possibly say anything about it? How could you test a compiler to see if it obeyed? I don't know of any language definition that tries to address that sort of issue (except for assembly languages). E.g., the C standard doesn't prevent a cast from generating code. Generating code is a compiler issue -- if you think the compiler is generating too much code, complain to the compiler writer. I agree that unchecked conversions between like-sized things should not generate code. And Ada 95 facilitates that by making various things erroneous, and by allowing by-reference return (13.9(12)). But anything beyond that seems like a quality-of-implementation issue. >...and recommend that >they be optimized away whenever the compiler detects the possibility >of doing so. I'm not sure what you mean. What's the difference between "generate no code" and "optimize away"? And why is one mandated and the other recommended? In any case, this sort of recommendation is silly -- compiler writers *know* they should eliminate unnecessary code when they can make the compiler detect that possibility. Shall we also recommend that assignment not use an exponential algorithm? >... Second, in the tradition of searchable keywords like >SYSTEM, CLASS, and UNCHECKED_DEALLOCATION, use pragma OVERLAID to >document the fact that a variable MUST be optimized away. Alternately, >just change the wording of the manual from making overlaid variables >erroneous to making them a safety concern that must be tested carefully. I think the RM95 *did* do just that. But you really have to know what you're doing to take advantage of it. >(1h) A FAST, mandatory, standarized way to put a stream of bytes out to >a file, with no intermediate packages or code between the >Ada call and the underlying file system WRITE and READ commands, >giving random access to standard_input and the same I/O speed as >competing languages, which now requires compiler dependent code. A fair comment. >(2) Make packages into second-class objects; currently they are >third-class objects, forbidding arrays of packages and forbidding >passing packages as generic parameters; a second-class package >would permit passing non-generic packages as generic parameters, which >permit an easy-to-read, easy-to-implement, very efficient method of >creating iterators with a single level of generics across a wide >set of data structures. This would not be easy to do. For example, you have to define what it means to have two copies of the "same" type. Please show an example of what you mean about iterators. >(3) I suggest calling the next version 2kX, in honor of the year 2000 problem >which will be biting CALENDAR software whose date limitations arise in the >neighborhood of 1999 plus or minus a hundred year sliding window. I don't see a smily there... Do you think Ada will still be around in 2099? - Bob