> if I had more experience implementing dependently typed languages, then perhaps I would not find it so weird, as it really just makes type constructors similar to functions, which they would be in a fully dependently typed language.

Yeah. I was screaming for most of this piece, because this all seems like standard dependently-typed stuff, and ironically enough implementing full dependent types would probably end up being easier than trying to handle this one feature as a special case.

> Yet an expression such as cols (replicate 0 (replicate 3 0)) should still work (and evaluate to 3)

Denotational or operational semantics: pick one for your programming language and stick to it. The author (who I generally think is very smart) here is striving for denotational semantics (type level data) and trying to torture the operations into supplying the appropriate result. Operationally `cols (replicate 0 (replicate 3 0))` is 0 not 3. So now you have to bend over backwards and implement custom shape functions that not only return weird answers but have to be special cased AND context sensitive - ie without trying the language I'm 100% sure that

    cols (replicate 0 "x") 

returns zero, but as described here

    cols (replicate 0 (replicate k "x"))

returns k. Ie cols has to introspect semantically into its argument. That's not just tedious, it's impossible unless you don't let people add names that can participate (ie arbitrary functions). Or you ask them to implement the same shape functions (which doesn't solve the problem because they'll be no more equipped than you are).

  cols (replicate 0 "x")

   def cols [n] [m] 't (x: [n][m]t) : i64 = m

   def replicate5 n x = replicate 5 x

   cols (replicate5 0 (replicate5 3 0)) == 5