Re: Grouping data from different modules together

[firth@sei.cmu.edu (Robert Firth)]

In article <1993Mar1.171045.17020@wdl.loral.com> mab@wdl1.wdl.loral.com (Mark A Biggar) writes:

>There is a standard way to do this in all the above languages. It is called
>the record stucture.  It is the standard way to group related data items
>together.  This deos require that all the related data items be defined
>in the same file, but if they are related enough to be grouped together, then
>they are related enough to be defined together.

I'm sorry, but I don't believe that.  Let me give a simple example from
the ugly past, which I'm quite prepared to believe applies also to the
ugly present.

The program was a transaction-processing executive, whose purpose was to
allow multiple "simultaneous" transactions, with different priorities, to
be processed by a single application.  This was before the days of re-entrant
code, and of course you couldn't run an application end-to-end without
frequent pauses to poll for interrupts, acknowledge high-priority events,
and so on.

The application was therefore structured as a sequence of small serially
reusable procedures, and the executive, or "driver" had this basic structure

	for i over fragment do
	    execute(fragment[i])
	    poll for anything urgent
	end

The table of code fragments had to be linear in memory, and of course was
constructed by the linker.  After all, when we were maintaining the
application - several hundred KLOC, a lotta code in those days - and we
changed a fragment, and it now ran for too long, we broke it in half, and
surely did *not* want to have to recompile the world after such a change.

It seems to me that this is close to the problem the original poster had,
and I for one don't think that fragment array is a global data structure
visible at the source language level.  And no, I don't know of any modern
high-level language that lets you do this - certainly not Ada, which can't
even build a table of procedure addresses at all, global or otherwise.