www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Can opDollar support a jagged 2D array?

reply James Blachly <james.blachly gmail.com> writes:
Suppose I have a data structure encoding sequence lengths:

seq1: 0 1 2 ... N
seq2: 0 1 2 3 4 ... M
seq3: 0 1 ... P

I would like to write opIndex and opDollar to support the notation 
obj[seq, x .. $] to retrieve sequences.

However, given that opDollar is templated on dimension (always 1 in this 
example) and has no information calling function's context/dimension 0 
parameter, this seems impossible.

Am I missing an easy solution?

Kind regards
Oct 01 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/1/20 10:34 PM, James Blachly wrote:

 Suppose I have a data structure encoding sequence lengths:
 
 seq1: 0 1 2 ... N
 seq2: 0 1 2 3 4 ... M
 seq3: 0 1 ... P
 
 I would like to write opIndex and opDollar to support the notation 
 obj[seq, x .. $] to retrieve sequences.
 
 However, given that opDollar is templated on dimension (always 1 in this 
 example) and has no information calling function's context/dimension 0 
 parameter, this seems impossible.
 
 Am I missing an easy solution?


This seems like an oversight. But it's not impossible.

Just curry the information to the receiver. opDollar doesn't have to 
return a size_t.

Something like:

struct FromEnd
{
   ptrdiff_t offset;
   FromEnd opBinary(string s, T)(T val)
   {
       mixin("return FromEnd(offset " ~ s ~ " val);");
   }
}

struct MyStructure
{
    FromEnd opDollar(size_t col)() if(col == 1) { return FromEnd.init; }
}

And then inside your opIndex, you have to handle that type specially 
according to context.

The saving grace here is that opDollar doesn't exist except in an 
indexing operation, so you don't need to worry about it except in that 
context. opDollar is really kind of a hacky way to do this. It was added 
back when multi-dimensional indexing was not yet solid.

-Steve
Oct 02 2020
parent reply James Blachly <james.blachly gmail.com> writes:
On 10/2/20 9:32 AM, Steven Schveighoffer wrote:

 This seems like an oversight. But it's not impossible.


Thank you Steve. Is there any chance that this mechanism will ever be 
revised? Presumably it would require a DIP.


 Just curry the information to the receiver. opDollar doesn't have to 
 return a size_t.


This is indeed pretty clever; I would not have ever though to have 
opDollar return a non-integral value. This again suggests the whole 
thing needs to be revised, but this will work for now -- thanks again!
Oct 02 2020
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/2/20 1:24 PM, James Blachly wrote:

 On 10/2/20 9:32 AM, Steven Schveighoffer wrote:

 This seems like an oversight. But it's not impossible.


 
 Thank you Steve. Is there any chance that this mechanism will ever be 
 revised? Presumably it would require a DIP.


The problem is, how do you pass enough context to the opDollar? The nice 
thing about opDollar is it's a simple mechanism. But as a simple 
mechanism, it's hard to say how to give it enough context in this case. 
In this specific case, you would need to know the index of the first 
parameter. But what if the first parameter depended on the index of the 
second? Really, you need opIndex to get the whole expression, with the 
dollar sign being processed there. But that's really hard to do, because 
now you are delaying the expression evaluation until later.

What I meant by an oversight is, at one point, opDollar just was a 
single property. And opIndex did not take a slice parameter, but rather 
you just had opSlice(beg, end), which wasn't a template. The 
multi-parameter version of opIndex (and the column-specialized version 
of opSlice version) was added to aid in building the Mir library (I 
think), and I don't know if anyone brought up the possibility of a 
jagged array like this.


 

 Just curry the information to the receiver. opDollar doesn't have to 
 return a size_t.


 
 This is indeed pretty clever; I would not have ever though to have 
 opDollar return a non-integral value. This again suggests the whole 
 thing needs to be revised, but this will work for now -- thanks again!
 


I think this is probably the best solution you are going to get. Maybe 
someone already has done something like this and has a better answer? 
Maybe Mir does something like this too, I'd take a look at it if I were you.

Long ago, I used opDollar to return something other than a size_t for 
dcollections, which worked awesome. I had asked for an opCaret, so that 
you could use slicing from beginning when `0` isn't the first element.

Like imagine a RBTree, I might like to say "range of all elements up to 
key 5" like rbt[^ .. 5] instead of rbt[rbt.begin .. 5].

But opCaret was deemed to be not useful enough. Oh well.

-Steve
Oct 02 2020