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