Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!rex!fs
From: fs@rex.cs.tulane.edu (Frank Silbermann)
Newsgroups: comp.theory
Subject: Re: Why not multiple out parameters? [again]
Message-ID: <4060@rex.cs.tulane.edu>
Date: 4 Sep 90 01:48:46 GMT
References: <1990Aug28.203643.11214@zaphod.mps.ohio-state.edu> <4019@rex.cs.tulane.edu> <2501@l.cc.purdue.edu>
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Lines: 50


David C. DiNucci:		dinucci@ogicse.ogi.edu <11831@ogicse.ogi.edu>
>| >	... at higher "system" levels
>| >	modules are being composed which each do a fair amount of work,
>| >	and thus are likely to return many different kinds of results.
>| >	Plugging these results into a record structure
>| >	just so they can be pulled back apart again is nonproductive.

Frank Silbermann:	fs@rex.cs.tulane.edu <4019@rex.cs.tulane.edu>,
>> Every module should perform a single conceptual operation
>> i.e. produce a single conceptual result,
>> and should be treated as a unit within the program
>> (i.e. as a record).  If a module's different kinds of results
>> do _not_ form a conceptual unit, then the design is a kludge.
 
In article <2501@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>	All of these are natural and useful multiple outputs:
>	...a result and a domain indicator, e.g. the truth of a condition.
>	...an integer quotient and a floating remainder.
>	...a short integer exponent and a mantissa.
>	...the decomposition of a word into fields -- one a sign,
>	   another an integer, and the rest a floating point.

(And each combination can be viewed as a single object.  So...?)

>	Putting these into a record to extract later
>	is very definitely non-productive,
>	like encoding multiplication as repeated addition.

The time loss due to encoding multiplication
as repeated addition is O(n).  Grouping atomic information
into records hurts efficiency by at most a constant factor
(and an optimizing compiler might eliminate even that).

A better analogy would the claim that
"storing a register into memory, only to later load it back,
is definitely non-productive, and therefore its is better
to program in assembler language."  (Such claims have in fact been made.)

The real question is where a program ought to lie
on the machine-oriented/human-oriented continuum.
This is an economic($$) decision, with no universal answer.
For most applications, however, the economics
are shifting to favor more human-oriented programming,
and this includes the clumping of detail into fewer,
but larger and more meaningful, concepts.
That's what records are for.

Frank Silbermann	fs@rex.cs.tulane.edu
Tulane University	New Orleans, Louisianna  USA