Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!uokmax!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: <5116@uqcspe.cs.uq.oz.au>
Date: 5 Oct 90 00:47:09 GMT
References: <5088@uqcspe.cs.uq.oz.au> <64898@lanl.gov>
Sender: news@uqcspe.cs.uq.oz.au
Reply-To: brendan@batserver.cs.uq.oz.au
Lines: 61


Me:

-> [...]                                           The percieved need for
-> side-effects in terms is merely a by-product of the poor state of language
-> design, and would not be missed at all in better languages.

jlg@lanl.gov (Jim Giles) writes:

>This, however, is not clear.  Mathematical notation for random variates
>existed before computing languages.  The variates were always of the same
>form as ordinary variables.

	I can't remember my prob theory too well. Is it true that no
	distinction is made between integer variables and integer random
	variables? I have a vague feeling that random variables
	represented sequences of values, you could talk about the
	average of a random variable and that sort of thing?
	
	Perhaps what is required is a more sophisticated data structure?
	How about a non-deterministic choose operator? Use a special
	notation in the special case, don't force people to have to
	worry about non-determinism all the time!
	Possible suggestion, declare a random variable

		r : seq of (1..10) | "normally distributed"
	
	now when you want a random number use "choose(r)".

>In fact, that is what I think the use of
>random generators should look like.  What you are suggesting is that
>the programmer should alter his notation to suit the language, not
>the other way around.  I think that it is the language that should
>cater to the desires of the programmer.

	Look the programmer is not the only person who has to cope with
	the code the is written. The programmer may well be the person
	who spends the least amount of time trying to understand the
	stuff. The idea should be to produce code that is easily
	comprehensible, rather than easily written. Included in that
	criteria should be the ability to easily reason about the
	behaviour of the code. I would agrue against global variables in
	both procedures and functions on the grounds of
	comprehensibility. Procedures have the mediating factor that
	their syntactic intent is to change program state. Side effects
	in terms deny the syntactic intent of terms, which is to define
	a value.

	The rest of your article gives a reasonable way of formalising
	the action of side effects. The general gist of it seems to be
	that to understand the "meaning" of a term with side effects you
	must break its evaluation down to a set of state changes, and
	determine the sequence of this actions. If this activity is
	required to make the code readable it should be reflected in the
	code.

--
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.