> It's easier to s/one/two/, but if you are doing anything more complex, you'd still build a logical representation in memory that is non-textual (hello, AST).

> It's easier to s/one/two/, but if you are doing anything more complex, you'd still build a logical representation in memory that is non-textual (hello, AST). From there, emitting binary output isn't more complex. Needless to say, there is already a large ecosystem around SPIR-V, which can be targeted from other SLs like HLSL and GLSL, and even output directly from Rust. The in-memory representation in any interesting compiler for some source language that is neither HLSL nor SPIR-V is unlikely to be either HLSL or SPIR-V. It’s going to be something that requires some effort to convert to whatever shader format the browser injests. I’m saying that it’s easier to write a converter to text because you don’t need any special tooling to get started. > In binary, you'd just say here come 32bits denoting IEEE 754 float (basically, piggy back on the existing spec). In text you need to say what symbols are accepted (exponent form, dot-based form, sign, how many digits are allowed, etc), which doesn't appear simpler to me. Programs are about a lot more than floating point literals. The parts that cause friction are control flow structure, variable scoping rules, etc. WHLSL goes with conservative choices that are easy to describe to anyone familiar with C. This makes it easy to understand both for folks who just want to use the thing without other tooling and for folks who want to build tooling. If it was the case that the dominant part (in terms of execution time, memory, security, or any other metric) of a shader compiler was parsing the text then it would be interesting to look at binary as an alternative. I just don’t think that’s the case: - most of the time and memory footprint of compilation is the backend so binary input is not better. - binary parsers have no security advantages. I would guess that they tend to have more bugs because they tend to have to use integers in the input as indices in lookup tables. - I haven’t seen data to suggest that binary parsers are less complicated, though I’ve heard folks express that as a feeling. For sure, parsing of full C is harder than parsing most other formats regardless of whether they are text or binary. But WHLSL is not full C. I don’t think it’s any harder to parse than SPIR-V.