Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ogicse!dinucci
From: dinucci@ogicse.ogi.edu (David C. DiNucci)
Newsgroups: comp.theory
Subject: Re: Why not multiple out parameters? [again]
Message-ID: <11831@ogicse.ogi.edu>
Date: 31 Aug 90 08:27:33 GMT
References: <1990Aug28.203643.11214@zaphod.mps.ohio-state.edu> <DWIGGINS.90Aug30195906@atsun.a-t.com>
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
Lines: 51

In article <DWIGGINS.90Aug30195906@atsun.a-t.com> dwiggins@atsun.a-t.com (Don Dwiggins) writes:
>In article <1990Aug28.203643.11214@zaphod.mps.ohio-state.edu> vidynath@function.mps.ohio-state.edu (Vidhyanath K. Rao) writes:
>
>   Incidentally, every single language I know of does use implicit records:
>   For domains of procedures. As a mathematician, I find the asymmetry between
>   the treatments of domain and codomain bizarre.
>
>You'd probably like logic programming then.  Not only can there easily be
>multiple out parameters, a parameter can be out in one call and in in
>another.  I don't know what Dijkstra thinks of Prolog, but this symmetry
>occurs naturally and is often a useful conceptual and practical tool.

Prolog likely suffers from exactly the kind of complexity in
data flow that the original attribution to Dijkstra seems to have
warned about.  Strand (a parallel processing variant) at least
partially addresses this by identifying parameters as either in or out
when a procedure (clause, process) is defined.

Large-Grain Data Flow 2 (aka F-Nets) takes the approach that the
single out restriction is fine for much of the low-level implementation
of any large system, and that traditional imperative textual sequential
languages are well suited to express such computation.  But at
higher "system" levels, modules which each do a fair amount of work,
and thus are likely to return many different kinds of results, are
being composed.  Plugging these results into a record structure just
so they can be pulled back apart again is nonproductive, but allowing
multiple out parameters in a textual syntax complicates the tracing of
data (and in LGDF2's case, control) flow in just the way Dijkstra
claims.  The problem here is not *multiple out parameters*, but
*textual syntax*.  A graphical syntax clears those problems up rather
nicely, and as stated, is only proposed for the high-level module
composition.  A module is a function where each argument is identified
as in, out, inout, or neither (control flow only), and the graphical
syntax shows the data flow clearly with arrows on one, both, or neither
end of each arc representing an argument.  The symmetry between domain
and codomain is preserved.

This approach was borrowed directly (by Babb) from DeMarco-style
Structured Analysis data flow diagrams, as an attempt to forego the
intermediate step of translating the diagram to a structure chart before
implementation.  The current aim of the model, other than the
software-engineering aims expressed above, is to provide an
architecture-independent model for parallel processing.

-Dave

-- 
David C. DiNucci                             Oregon Graduate Institute
                                             (Formerly Oregon Graduate Center)
CSNET: dinucci@cse.ogi.edu                   19600 N.W. Von Neumann Dr.
UUCP:  ..ucbvax!tektronix!ogicse!dinucci     Beaverton, Oregon  97006