Re: List operations (Was: More LPMOO stuff)

• Date: Sat, 19 Aug 1995 16:41:30 PDT
• From:
  Kai Storbeck <kais@dds.nl>
• cc: moo-cows@parc.xerox.com
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-To: <9508191814.AA04133@avon.declab.usu.edu>

On Sat, 19 Aug 1995, 869683 Gillespie Brandon James wrote:

> Ben Jackson drew these hieroglyphs:
> <> > Hence list[n..] would be equivalent to list[n..length(list)], except it
> <> > should save the extra time of evaluating length(list).
> <> 
> <> It would save you the extra time of *typing* length(list).  The length
> <> will still have to be evaluated.  In either case it's O(1), since list[0]
> <> contains the length (it's inaccessible from MOOcode).  I don't think you
> <> can argue that this would be a performance improvement.
> <
> < well, it'd shave off a few steps, not having to deal with an explicit
> < builtin call, but that already got covered.  just want get my opinion
> < out:
> <
> < the syntax kind of bugs me.  i can see where it comes from, but it
> < does look like a typo.  my preference would be for foo[1..$] as is
> < specified in the "to-do" list for the LamdaMOO server.

Why not imediate make the variable RANGE possible, so you can put a range 
in a variable and use it:

some = [1..($/2)];
secondsome = [($/2)..$];

And then do operAtions on both lists...
Till now there is no possibility to put a range in a variable or property.

	Kai

                                   |||||
                                  / 0 0 \
                ================oo0=(_)=0oo==================
                |\------------DRIVE DEFENSIVE--------------/|
                |/--------------BUY A TANK-----------------\|

• Re: List operations (Was: More LPMOO stuff)
• From: COLIN@uncvx1.oit.unc.edu

• Re: List operations (Was: More LPMOO stuff)
• From: 869683 Gillespie Brandon James <brandon@avon.declab.usu.edu>

• Prev: Re: List operations (Was: More LPMOO stuff)
• Next: Re: List operations (Was: More LPMOO stuff)
• Index: MOO-cows
• Thread: MOO-cows