Alternative syntax for method update

Currently, we can define a function using

def update(k1: K1, k2: K2, ... kn: KN, v: V) = ...

Then we can use this as

this(k1, k2, …, kn) = v

as a syntactic sugar.

However, for some type (e.g. NdArray: n-dimensional arrays), the number of keys is not a constant number: it may be changed. I propose that we add the following declaration:

def update(ks: K*)(v: V) = ...

And if an update method with such shape is declared, the syntactic sugar

this(k1, k2, k3, ...) = v

is also allowed.

You could just use a tuple…

I agree, for an N-dimensional array, the “key” would just be a tuple of arity N.

“just”? It’s true N-dimensional arrays take N keys. But this looks like you could “just” use shapeless to deal with arity-polymorphic tuples (not sure how hard, I confess I never learned to use shapeless)? I agree it might often be worth it, but I’m not sure why update should be restricted for using varargs—it seems irregular. I don’t implement every day weakly-typed tuple spaces (hello, Jini, been long dead?), far from it, but why the restriction?

Who said anything about shapeless? Are you abstracting over arities?

It might be easier to discuss with a more concrete use case.

Talking about N-dimensional arrays abstracts over N, hence the arity of array indexing. Maybe then the OP writes NdArray1, NdArray2, and so on, but to me the whole OP hints at one class for all N, sth. like:

class NdArray[K, V](n: Int) {
  def apply(ks: K*): V = ... // this already works
  def update(ks: K*)(v: V) = ... // this doesn't yet
}
1 Like

yeah that’s exactly my use case.

If we could write NdArray[N <: Int] with some typelevel tricks it’ll also be ok.

It does seem odd that you can’t use an arbitrary argument list there. I would expect this(...) = foo to correspond to this.update(...)(foo) no matter what the arguments are.

2 Likes