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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!amstel.llnl.gov!WILSON
From: WILSON@amstel.llnl.gov (One Heppy Heppy 'Ket')
Newsgroups: comp.lang.ada
Subject: Ethernet I/O package
Message-ID: <9003220347.AA01921@ajpo.sei.cmu.edu>
Date: 22 Mar 90 01:50:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

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