Short: Add. args to load_object(), clone_object(), allocate()
From: Alfe
Date: Wed, 16 Dec 1998 21:11:51 +0100 (MET)
Type: Feature
State: Done - allocate(size, init_value) implemented in 3.2.9-dev.270

ah, another thing: i'd like an optional second argument to allocate(),
which should be the value to initially fill the array with.  e.g.:
allocate(5,3.1) ==> ({ 3.1, 3.1, 3.1, 3.1, 3.1 }).

varargs mixed *allocate(int i,mixed m) {
  return (m?
          map_array(efun::allocate(i),lambda(0,({ #'return,m }))) :
          allocate(i));
}

Matthew Julius also writes:

> > mixed *allocate(int, closure|mixed)
> >   Same as allocate() but with additional argument to initialize values
> >   in the array.  If the argument is a closure it is funcall()'d with the
> >   index of the value and the returned value is inserted into the array
> >   at that position.  Otherwise, all values are initialized to the second
> >   argument.
>
> yes, nice.

Yeah, your last note about this convinced me.  It can be simulated but at
the cost of being very difficult to have symbols, quoted arrays, and unquoted
arrays.  For example,

#include <lpctypes.h>
varargs mixed *allocate(int i, mixed m) {
  if (m) {
    int type;
    type = get_type_info(m, 0);
    if (type == T_POINTER || type == T_SYMBOL || type == T_QUOTED_ARRAY)
     return map_array(efun::allocate(i), lambda(0, quote(m)));
    return map_array(efun::allocate(i), lambda(0, m));
  }
  return efun::allocate(i);
}

I'm still undecided on allocate(int, closure|mixed) or allocate(int, mixed).
If the second argument had the use I specified then you could not initialize
an array with a closure value.  Probably better not to have this double
meaning.  The usefulness of applying the closure to the index did seem useful
at the time though...


And Ralph Zitz suggests to be able to allocate multiple dimensions:

  allocate( ({ size1, size2 }) )

allocates a two-dimensional array.