Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!mcsun!ukc!stl!tom
From: tom@stl.stc.co.uk (Tom Thomson)
Newsgroups: comp.theory
Subject: Re: Why not multiple out parameters? [again]
Message-ID: <3352@stl.stc.co.uk>
Date: 5 Sep 90 14:35:30 GMT
References: <1990Aug28.203643.11214@zaphod.mps.ohio-state.edu> <4019@rex.cs.tulane.edu> <2501@l.cc.purdue.edu> <4060@rex.cs.tulane.edu>
Sender: news@stl.stc.co.uk
Reply-To: "Tom Thomson" <tom@stl.stc.co.uk>
Organization: STC Technology Limited, London Road, Harlow, Essex, UK
Lines: 32

In article <4060@rex.cs.tulane.edu> fs@rex.cs.tulane.edu (Frank Silbermann) writes:
>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.
>
I think records are a red herring here.

We may well want to introduce a record type into the language, just so that
we can 
       (i) have a label for the type of a function with multiple results
      (ii) pretend those multiple results are really all one thing 
 
There is no need to introduce any objects of these types, though.
 
If I write something like
 
declare decompose:real -> bool * int * int;
  ........
let (sign, expt, mant) = f(r) .....
 
then I have provided the call to f with three output parameters (named sign,
expt, mant) as required by Rubin while using the structuring concept suggested
by FS.
 
But I hope my system never constructs a record at run time.
 
Tom