Christian Soeller wrote:
> Jeremy Howard wrote:
>
> > Basically, I want to be able to create a list ref of list refs, specify
a
> > data type (eg 'int') and attributes of ':compact' or ':sparse', and have
the
>
> As Dan Sugalski suggested it seems not a good idea to bring in the list
> of list ref into the proposal. Why does it have to talk about the
> implementation? The list of list refs should be optimized away by the
> ':compact' attribute, for example. Or am I missing something?
>
I don't think you're missing something--I think I failed to explain
something properly! The list ref of list refs (which from now on I'll call
'list ref trees' or 'LRTs' to avoid typing) idea is not a suggestion on
implementation, but a suggestion on syntax.

The idea is that we don't create a new data type at all, but instead add
some magic to LRTs. The magic I think we need is:
 - When a type is given to the LRT elements, and the ':compact' attribute
provided, it is stored as a contiguous block of memory
 - Standard list ref operators continue to work as per usual
 - n-dim indexing operators (syntax to be defined) work as well.

For n-dim indexing, I'm wondering about using a list of list refs:

  $a = [[0,1,2]
        [3,4,5]];
  @b = @$a[[0,1], [1,2]];   # @b == (1, 5)

The dereferencing is a bit annoying--maybe we can make that optional.


Reply via email to