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,a9f89faeb8f41ad0 X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: ifdef replacement for GNAT Date: 1998/04/13 Message-ID: <6gt6ij$q6o@top.mitre.org> X-Deja-AN: 343594959 References: <352287EE.1CFB@tolstoy.mdc.com> <86g1jm2gcf.fsf@zappa> Organization: The MITRE Corporation, Bedford Mass. Newsgroups: comp.lang.ada Date: 1998-04-13T00:00:00+00:00 List-Id: Robert > The proper approach for achieving target dependence is > to follow two steps > (a) encapsulate the target dependence down to the minimum level > (b) Provide separate target dependent units for these > remaining functions > ... multiple implementations for different targets ... These are good steps. However, there still needs to be a need for conditional compilation for three reasons. First, multiple implentations (function bodies or package bodies, say) for different targets IS conditional compilation. Second, this kind of conditional compilation is not supported within the language, even though it is required for multiple targets. There is no question of whether conditional compilation is needed or used. The question is whether the conditional compilation that we have to do is standard across compilers and tools. Currently the required conditional compilation is not standardized, and each compiler does it its own way. This is a serious language issue that is easily and cheaply fixed. Third, there is a limit to step (a), encapsulation. The language permits an efficient IF FALSE or IF MACHINE=DOS or IF INTERRUPT_LEVELS=15 to be optimized away at runtime, but only in the executable portion of the code. In the declarations the following types of target dependent code cannot be handled within the language, but must resort to non-standard ways of managing the visible parts, not just the implementations: A. Different pragmas or pragma arguments B. Different representation specifications (bit lengths & starts) C. Different types (signed versus unsigned) D. Different implementations of points (integer versus record) E. Different interrupt locations for interrupt handlers F. Different ways of addressing virtual memory G. Different ways of addressing absolute memory H. Different data structures for accomplishing software interrupts I. Different memory-mapped locations for hardware devices J. Different ways of handling integers larger than integer'last K. Number of levels of pointers required to interface to C vs. Java L. Different elements in records for interface to different operating systems Other things like URL formats, bit ordering, filenames, end-of-line-string, end-of-file-string, maximum filename, temporary directory location, directory separator character, byte ordering, numerical and string constants, bit patterns for interrupts, etc., can be done with a configuration package. Looking over the code here written that requires conditional compilation, the following suggestion comes to mind for Ada 2005X: Add into the Ada language a package streaming_IO, which has nothing to do with stream_IO, but instead has the following characteristics. On INPUT Ada will set up reliable streams of bytes from the following sources: directories, virtual memory, absolute memory, serial ports, parallel ports, SCSI ports, key-down presses, key-up presses, mouse-down presses, mouse-up presses, mouse movements (sampled at a selectable rate), screen touches, keypad key-down presses, keypad key-up presses, analog audio input, MIDI, Ethernet packets, standard input, disk files, URLs on the Net, sense lights, tablet control stick, joystick, and so forth for all input ports on the computer. On OUTPUT Ada will set up reliable streams of bytes to the following sinks: directories, virtual memory, absolute memory, serial ports, parallel ports, SCSI ports, sense lights, screen text, screen pixels, speaker, sound boards, MIDI, Ethernet, standard output, disk files, URLs on the Net, lighting up a character of a given size in a given font at a given screen location, etc., for all output ports on the computer. These should be done in such a manner that the user can add additional device streaming_IO streams. The lack of this kind of reliable streaming is what caused the problems with windowing systems today: over-reliance on mouse movement and mouse icon selection, inversion of the main program so that the Windowing System call the program when it detects an input rather than the program taking from whatever stream it desires, and the difficulty of programming windowing systems because (in order to become the main program) the windowing system must restrict the application from doing most of the things it wants to do. There is a strong relationship between these two problems: the lack of conditional code in Ada and the need for device streaming. They are related because almost all of the conditional code is the result of programming reliable device drivers for device streams. The need for conditional compilation of any kind is reduced significantly when the user has direct access to the byte streams coming in from files, ports, directories, URLs, and keyboard interrupts, and can light up pixels on the screen in a portable manner. If Ada standardizes a realtime speed way of directly getting to the hardware, there would probably be no reason for desiring any conditional compilation (outside of the built-in generic instantiation for switching types and their representations), CASE statements and IF statements. The Unix, DOS, Windows 3.1, Windows 9x, Windows NT, Posix, Mac HFS, Solaris, VMS, etc., systems are close enough to permit these streams to be implemented in a standard manner with realtime response. VMS files would NOT go through the record manager, but would be channel programmed so they are given to the user as a stream of bytes, of course. And those operating systems with defects (for example, do not support key down-strokes) would simply never have any inputs on those streams. Defective hardware (for example, missing parallel port or those that use and ISP instead of being hot on the Net) would have an exception: raise missing_hardware. There are approximately 10,000 things that Ada has to do to support applications, divided into various device streams and various data structures. It should be our goal to have all these 10,000 things implemented as external packages by 2005, so that at that time, the revision of the language can concentrate on fixing the small number of efficiency bugs in the language design, eliminating the last of the rational reasons for avoiding the use of Ada.