# List operations

(anomaly@u.washington.edu)
Wed, 16 Aug 1995 11:27:59 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >>One thing I would like to see, in regular MOO (and so it's a suggestion for
    >>LPMOO as well) are the range constructions:
    >>
    >>                [..n] and [n..]
    >>
    >>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.

    It's true it wouldn't be a big time savings because length() executes in
    constant time; nevertheless, as Stephen Szabo already noted, it would save
    some time, because rather than have the MOO perform

      PUSH list
      NUM n
      PUSH list
    * MAKE_SINGLETON_LIST
    * CALL_FUNC length
    * RANGE

    it could do something more like

      PUSH list
      NUM n
    * RANGE

    saving three operations to evaluate a value I don't really need.  Probably
    the MOO server code involved would still have to evaluate the length of the
    list anyway (I don't pretend to know about that), but at least it wouldn't
    waste time passing the value back into the db; it can do that evaluation
    behind the scenes, and save a (small) fraction of a second.

    And in any case, it's true, it would save me the trouble of typing it :)

    As you also noted, an expression like

    return {@foo,@bar,@baz}[3..];

    is much better than

    temp={@foo, @bar, @baz};
    return temp[3..length(temp)];

    and represents additional savings beyond the savings involved in not having
    to evaluate the length(temp) expression.

    While we're revising ranges for lists and strings, we might as well revise
    the ranges in for-loops as well, as suggested by someone (sorry, forgot who)
    in a previous post:

    for each in [#0..max_obj()]   and  for each in ["a".."z"]

    should be just as legal as for each in [1..5], and would save one the
    trouble of doing

    for each in [0..tonum(max_obj())]
      temp=toobj(each);
    ...

    or

    alphabet="abcdefghijklmnopqrstuvwxyz";
    for each in [1..26]
      temp=alphabet[each];

    respectively; however, this might require differentiating between for-loop
    ranges and list/string indexing ranges...

    michael
    anomaly@u.washington.edu