From octave-maintainers-request at bevo dot che dot wisc dot edu Tue May  7 12:45:20 2002
Subject: Re: Cell array changes for Octave
From: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>,    A Scottedward Hodel <a.s.hodel@eng.auburn.edu>
Cc: Cai Jianming <caijianming at yahoo dot co dot uk>,    octave-maintainers mailing list <octave-maintainers@bevo.che.wisc.edu>
Date: Tue, 7 May 2002 13:44:51 -0400

On Tue, May 07, 2002 at 11:09:19AM -0500, John W. Eaton wrote:
> On  7-May-2002, A Scottedward Hodel <a dot s dot hodel at eng dot auburn dot edu> wrote:
> 
> | lists are used in my octave "legacy" code.  Sure, I could rewrite it, but
> | backward compatibility would be a nice feature to keep, if at all possible.
> 
> I agree that breaking backward compatibility is not the best thing,
> but I'd also prefer to avoid having a lot of redundant code in Octave
> that is there just to support some old way of doing things.
> 
> In this particular case, I think all the list functions (list, nth,
> append, reverse, and splice) can be rewritten as M-files that use
> cell arrays.

Agreed.  However you will run into a problem is with x(i) = k where x is a
list, as in:

	x = list(1,2,3);
	x(2) = list('a')

which in octave produces:

x =
(
  [1] = 1
  [2] =
  (
    [1] = a
  )
  [3] = 3
)

but cell-array equivalent:

	x = { 1,2,3 };
	x(2) = { 'a' }

for compatibility should produce:

x = 

    [1]    'a'    [3]

So either we break backward compatibility or
matlab compatibility (or both ;-), or we suffer
under a flood of cruft.

If lists are made a separately installable type then the
cruft is more manageable, at least within the core octave.

Paul Kienzle
pkienzle at users dot sf dot net