Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!samsung!munnari.oz.au!brolga!uqcspe!batserver.cs.uq.oz.au!brendan
From: brendan@batserver.cs.uq.oz.au (Brendan Mahony)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <5006@uqcspe.cs.uq.oz.au>
Date: 26 Sep 90 01:08:37 GMT
References: <9009202236.AA21344@raven.pa.dec.com> <63647@lanl.gov>
Sender: news@uqcspe.cs.uq.oz.au
Reply-To: brendan@batserver.cs.uq.oz.au
Lines: 34

jlg@lanl.gov (Jim Giles) writes:

>Oh, well.  If it's a question of side-effects.  I oppose them outright.
>As a practical matter, you can convince most programmers that operators
>should not have side-effects.  But, when it comes to functions, they
>always demand to be allowed side-effects.

Do they really? Why in the world do they want to make their life so
difficult? I don't see what side-effects in functions can do that tuple
valued expressions can't do, execept make the code unreadable and
impossible to reason about. For example if

	f : int -> int;

	a := f(b);

also updates c and d what is wrong with using a tuple valued function,

	f : int x int x int -> int x int x int;

	(a,c,d) := f(b,c,d);

If that takes too much typing for you why not

	#define (A):=F(B) (A,c,d) := f(B,c,d)

Even allowing functions to look at global state variables leads to confusion,
letting them change them means you don't have a function and terms are
not terms. What is the point of such confusion?
--
Brendan Mahony                   | brendan@batserver.cs.uq.oz       
Department of Computer Science   | heretic: someone who disgrees with you
University of Queensland         | about something neither of you knows
Australia                        | anything about.