Hacker News new | ask | show | jobs
by almostgotcaught 265 days ago
> 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).
1 comments

If I understand correctly,

  cols (replicate 0 "x")
would not typecheck, so I'm not sure I understand your example; could you clarify?
okay i guess you're right since

   def cols [n] [m] 't (x: [n][m]t) : i64 = m
but that doesn't affect my point: cols has to know "something" about the name `replicate` more than just the types. why? because suppose i defined a function

   def replicate5 n x = replicate 5 x
then

   cols (replicate5 0 (replicate5 3 0)) == 5
that "something" is a shape function and now each data function must also correspond to a shape function. but that shape function doesn't magically have more info about its params than cols does about its params so you haven't solved any problem, you've just multiplied it.

spoiler alert every single tensor/array/matrix/ML/AI compiler runs into this same problem. there is only one solution: a fixed op set with a fixed number of corresponding shape functions. and then your compiler tries to perform shape inference/propagation. sometimes it works and you can specialize for fixed sizes and sometimes it fails and you get "dynamic" or "unknown" dims in your shapes and you can't do anything. oh well that's life in a universe where the halting problem exists.

It is basically dependent types, but there is a specific and intentional omission (no true dependent products) that interacts with another feature (the ability to hide sizes) that ultimately causes the mess. I elaborated on it here: https://futhark-lang.org/blog/2025-09-26-the-biggest-semanti...