WILSON@amstel.llnl.gov (One Heppy Heppy 'Ket') (03/22/90)
Terry J. Westley writes, discussing his generic ethernet I/O package, based on SEQUENTIAL_IO. His first stated goal is to "preserve strong typing." He doesn't want to use an array of bytes, and then do UNCHECKED_CONVERSION. In VAX Ada, there's a note in ARM section 14.2.2 stating that VAX Ada "does not perform the check that raises DATA_ERROR," with reference to the READ procedure. I don't know how many compilers do this check, and at what cost. Another way to read data in Ada under VMS is via the QIO system service. This service takes a buffer address and loads the data, returning the number of bytes transfered. Ada certainly doesn't do type checking in this case! I imaging there's a similar problem on other systems using low-level I/O services. This leads me to believe that there's no good way of doing low-level I/O like this and retaining run-time "strong typing," unless you actually use SEQUENTIAL_IO and your compiler performs the DATA_ERROR check. However, you CAN benefit from compile-time "strong typing." Unfortunately, this is sometimes a problem as well. I think if your elements 1, 2, and 3 were all in the same program, you'd find that the type rules would force you to use a variant record containing all your message types. Having these elements on different nodes, or even in different programs, gives you an out, but it's inherently adding risk, by removing certain compile-time checks. I'd suggest writing separate variant records for each element. You can either maintain a single enumerated type for your discriminant, referenced by all variants, with the unused parts set to "null," or use separate enumerations for each element. The latter is nicer in the sense that you keep the visibility of the message types down, but it requires that you rep spec all the enumerations, and the compiler won't check for duplication of the internal values from one enumeration to the other. The former gives all programs visibility of all message categories, but the details of each message defnintion is scoped well. We have a similar problem with our system event logger. We maintain a file of all system events, which are drawn together in one large two-level variant record. The top level is discriminated by the event "class," and each class has its own variant record definition discriminated by detailed sub-classes. Now, if each program which wanted to log an event had to write to the event log file directly, each program would be dependent on all packages used to define any of the event types. However, we have one process which actually writes to the files, and which maintains network links to each of the programs which wish to log events. Across these network links, only the "class" variant records are sent, so the various programs logging events are only dependent on their own class's event type specification. The process which actually writes to the file is dependent on all "the world," and since we don't have a process dedicated to retrieving events from the file, so are each of our report writers, but we have far fewer report writer programs than event logging programs (surprise!), so this works out well. This is another example of using network communications to loosen Ada's strong typing. We still have everything compiled from the same package specifications, but we're taking over the job of ensuring that a certain assignment statement (i.e., the network send/receive) has the proper parameter types. If your system will provide the run-time DATA_ERROR check, so much the better; ours doesn't, but we haven't had any problems because of that yet. --- Rick Wilson Lawrence Livermore National Laboratory