Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!unicads!les
From: les@unicads.UUCP (Les Milash)
Newsgroups: comp.sys.transputer
Subject: Re: Occam, C and everything.
Message-ID: <595@unicads.UUCP>
Date: 15 Aug 89 15:56:01 GMT
References: <8908031551.AA12160@uk.ac.ox.prg>
Reply-To: les@unicads.UUCP (Les Milash)
Organization: Unicad  Boulder, CO
Lines: 24

In article <8908031551.AA12160@uk.ac.ox.prg> HALLAM@vax1.physics.oxford.ac.uk ("P.M. Hallam-Baker") writes:
>
>The problem as I see it is how do you implement a memory allocation system
>on a linear memory machine, which will cope with a highly parallel 
>language without spending all your run-time doing garbage collection ? If
>someone could sort this one out then we could implement Occam properly.
i think i know how to do this.  i'd be happy to talk to you or whoever at 
whatever length you like about my idea.  i can't see how occam or C require
GC at all; data objs have unambiguous and finite lifetimes.  ya just gotta
get away from that stack, its top is a damned scarce resource.

i agree with those that bitch about C's defectiveness, and those that bitch
about Occam's uselessness as a HLL.  i tend to think of "occam" as meaning
"everthing occam could be, even if i have to do it myself".

>P.S. Disclaimer : Almost no-one else in this department would agree with a
>     single word of this - but they all use FORTRAN.

PPS disclaimer:  probably no-one else in this company would agree with a word
	of this either; they're happy to manually wrestle with unspecified
	ordering of side-effects (it's called "C/UNIX machismo").

just another naive hothead
Led Z. Milash