Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!usenet From: vidynath@function.mps.ohio-state.edu (Vidhyanath K. Rao) Newsgroups: comp.theory Subject: Why not multiple out parameters? [again] Summary: I still don't the answer. But I have a clarification: out parameters ARE NOT var parameters. Keywords: out parameters, VAR parameters Message-ID: <1990Aug28.203643.11214@zaphod.mps.ohio-state.edu> Date: 28 Aug 90 20:36:43 GMT Sender: usenet@zaphod.mps.ohio-state.edu Organization: Me? Organized? Lines: 98 [Here kitty kitty] A while back I posted an article asking "Why are multiple out paramters bad?". A disk crash in my home computer together with down time on the mail server has delayed posting a summary of the responses I got. Most of the responses I got kept refering to "VAR" parameters leading to aliases. To me this a totally different problem: "VAR" parameters are implemented using pointers and pointers lead to aliases. Using "copy out" and "copy in, copy out" parameters should avoid aliasing. The only "better known" language [that I also know] that does this, albeit only for simple types, is Ada. I do not have access to Ada compliers or the lastest documentation. But Ada-80 reference manual confirms my statement above. Let me elaborate a little on kind of things one does with functions in mathematics but require contortions in Modula-2 or C: I can form functions $$f: D_1 \times \cdots \times D_n \to C_1 \times \cdots \times C_m$$ and compose with "meta-functions": projections, "concantations" [products in the sense of category theory] and permutations [and I don't have to invent a special unique name for each codomain I use]. Thus one would have a construct of the form: DECLARE PROC f( p_1, ..., p_n; RETURNS r_1, ..., r_m); Space for the r_i's would be allocated on the stack. After the called procedure returns, these would be >*COPIED*< to the actual out paramters. Projections can be accommadated by allowing the omission of one or more of the result parameters in the call. Permutations and concantanations would require list processing at least at compile time; one can do without them if the compiler used does reasonable optimization and allows arbitarily long [and multi-line] macros and, of course, variable declarations at the start of any block. Given only this much functionality, aliases cannot occur. [Of course you can use the same variable for two of the result paramters. But the callee would not go haywire; you would be doing a projection in an implementation dependent manner :-)] Of course some extensions may be desirable for efficiency: InOut parameters [using copy in, copy out] for parameters that are modified, passing pointers to arrays and large structures rather than copying etc. [In this case, every one would know that pointers are being used instead of the safer alternatives, and be on guard for problems.] The forgoing discussion should make it clear that aliasing is due to the use of pointers in the guise of "VAR" parameters, and has nothing to do with having multiple out parameters. So the question still remains unanswered: Why are multiple out parameters bad? Most of the responses referred to aliasing when passing pointers. I will omit them. There were two other respones worthy of note: Frank Silbermann : [To my question, by E-Mail, on why returning a record of a named type, declared just for this purpose is ok, but not multiple out parameters?] This has nothing to do with returning a record or other complex complex object. He is talking about functions with side effects, e.g. more than one VAR parameter. i.e. more than one "thing" gets changed. A record counts as one "thing" because it can be referenced by a single name. To me this smacks of name magic. And in any case, out parameters need not be initiliazied beforehand. They are in fact being initiazied, NOT BEING CHANGED. It looks that way simply becuase of lacunae in certain languages. mark@parc.xerox.com (Mark Weiser) writes: [in response to some follow-up article posted to the board] Modula-(2 and 3), Cedar, Mesa, lots of others have record returns. I truly don't understand the comment about a record being inadequate because of the drastically different types--a record is that data structure one uses when one has drastically different types. C requires that to return a record one must separately define it. Cedar (e.g.) has the convention that the procedure declaration defines an implicit record type to be the return value... I am not familiar with Cedar [or Mesa]. I would appreciate a list of easily available references to such languages. IMHO, just grafting implicit record types to Modula-2 or C will not allow efficient ways of doing projections, concantanations and permutations. 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. And a parting, jocular shot: [Mark again, refering to another posting which I lost. I am very likely quoting out of context. Apologies, but I couldn't resist.] Reading the code at the point of the call there is no syntactic evidence about which parameters are which. When huge semantic differences are hidden by identical syntax, that is a bad thing. I agree:-^. VAR parameters are used for (1) out parameters, (2) in-out parameters, and (3) passing pointers to save space. Let us outlaw VAR parameters, and make programmers say which of the three they are really doing. -- Vidhyanth Rao It is the man, not the method, that solves function.mps.ohio-state.edu the problem. - Henri Poincare (614)-366-9341 [as paraphrased by E. T. Bell]