Rudisin@TL-20B.ARPA (Jerry Rudisin) (09/17/85)
Something that has always struck me as incredibly inconvenient about Ada IO is the fact that it does not offer the convenience and simplicity of things like C's printf or the richer IO facilities in PL/1 and FORTRAN. Formatting a page of output, or even printing a series of variables and descriptive information for debugging purposes is a real pain in Ada because of the need to use numerous simple calls. Unfortunately there is no easy way to get around this limitation. Within limits you can synthesize a printf type mechanism by defining a bunch of overloaded IO routines with different combinations of argument types. However, one quickly reaches a combinatorial explosion in trying to build a really useful facility (i.e., to handle arbitrary combinations of (exactly) 10 parameters of 4 different base types requires 4 ** 10 overloaded declarations). Likewise, you could build an IO package using "union types" synthesized out of variant records and unchecked conversion, but this is dangerous and inconvenient for a user. So, we are pretty much stuck with a cumbersome IO mechanism. I am not proposing any changes to the language to address this, since there are good reasons for the limitation. Though well defined in the ARM, the IO packages are not really part of the language in the sense that they are packages like any other, not to be implemented by special features such as routines with variable numbers of parameters. For a variety of good reasons, variable number of parameters are not permitted. This comment is simply to express my own annoyance at this unpleasant feature of Ada IO, since the subject has been raised, and to ask Ada users familiar with other languages if this bothers them as well. I have had surprisingly strong negative reactions to this aspect of Ada when I describe it to novice Ada programmers. Jerry Rudisin Tartan Laboratories -------
CHRIS@engvax.UUCP (09/18/85)
[ Go ahead bug, make my day. ]
I have not been bothered by Ada IO, but then, whenever I want to do
anything fancy I immediately switch to a screen management package like the SMG$
(VMS 4.x) routines or curses (Unix). I realize that this makes these programs
relatively unportable, but I'd rather deal with non-portability than not be able
to do fancy screen IO easily.
I would normally switch to a screen management package when trying to do
any fancy screen IO from any language, but perhaps there should be an attempt to
write a screen management package for Ada. This means either adapting one of
the current group of screen management routines (there are probably at least as
many as there operating systems) or writing a whole new package specifically for
Ada programs. Perhaps this could be part of the APSE? Of course, this then
means that one has to figure out which screen management package one should
adapt or what the specs for the new package should be... (I have the feeling
that people feel about IO the same way that they feel about editors, languages,
operating systems, etc.)
I have never attempted any sort of file IO with Ada yet, but if indead
Text_IO will only deal with printable ASCII characters, then that makes Text_IO
more limited than I like. It also makes Text_IO useless as a building block for
the above mentioned screen management package, since many terminals require
escape sequences for various character graphics.
-- Chris Yoder
UUCP --- {allegra|ihnp4}!scgvaxd!engvax!chris
ARPA --- engvax!chris@cit-vax.ARPApeter@graffiti.UUCP (Peter da Silva) (09/23/85)
> I am not proposing any changes to the language to address this, since > there are good reasons for the limitation. Though well defined in the ARM, > the IO packages are not really part of the language in the sense that they are > packages like any other, not to be implemented by special features such as > routines with variable numbers of parameters. For a variety of good reasons, > variable number of parameters are not permitted. What is wrong with a well-defined varargs interface? It doesn't have to be efficient: if you want efficient I/O you're going to be packing stuff into buffers and feeding them out through direct writes. Maybe an array of structs like so (ADA ref manual not here, so I'll do it in Pascal, yet another language I'm no longer familiar with): type arg: record case tag: integer in 0: int: integer; 1: flt: real; 2: chr: character; 3: str: string; end end; It would also be useful for symbol tables & the like.