The Biggest Semantic Mess in Futhark
Key topics
The author discusses a complex issue in the Futhark programming language related to type constructors and dependent typing, sparking a discussion about the challenges of designing programming languages and the trade-offs between denotational and operational semantics.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
37m
Peak period
7
0-6h
Avg / period
4
Key moments
- 01Story posted
Oct 1, 2025 at 8:38 PM EDT
3 months ago
Step 01 - 02First comment
Oct 1, 2025 at 9:15 PM EDT
37m after posting
Step 02 - 03Peak activity
7 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 5, 2025 at 11:40 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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
returns zero, but as described here 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).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.
C++ has a couzy group of friends among mainstream languages, that share similar age.
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.