Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!hudson@yough.cs.umass.edu
From: hudson@yough.cs.umass.edu (Rick Hudson)
Newsgroups: comp.lang.modula3
Subject: LOCATION
Message-ID: <9104161446.AA15493@yough.ucc.umass.edu>
Date: 16 Apr 91 14:46:56 GMT
Reply-To: hudson@vax1.cs.umass.edu
Lines: 30
To: buschman@tubsibr.pa.dec.com
Cc: m3

buschman@tubsibr writes:
> Hi!
> > >       For my interpreter I created a procedural operator LOCATION:
> > >  
> > >  	LOCATION (VAR x: Any) : REF Any
> > >  
> > >       How is this supposed to go in the new standard?
> > 
> > I don't understand.  Are you proposing that LOCATION be added to the
> > language?  If so, you should post a full explanation of the proposal
> > and its impact.  For instance, it appears to me that LOCATION would
> > place great constraints on the possible allocator/collector implementations.
> > Since I can use LOCATION to create a REF to an arbitrary field in an
> > arbitrary record, the collector cannot assume that type tags are near by?
> > 
> >   - Bill Kalsow
> 
> no, I am not sure about proposing this to be added to the language. At
> this moment it is a local hack of mine, which doesn't interfere with
> my heap storage implementation (I am using bitmaps to keep track of
> which storage is still in use). What I want to know is: how do I get
> the same effect, with legal actions defined in Modula3.

Module-3 the language has outlawed such actions. Bill Kalsow has indicated a
one of the reasons. When I implement list manipulating routines I tend to do
it recursively. If I am concerned about efficiency, I restrict my recursion to
be tail recursion. Any reasonable compiler will optimize away the tail
recursion leaving me with readable and efficient code :-).

- Rick