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