hey! indeed, it is a pattern more from Python/Kotlin/etc and on first sight it looks awful for those used to work in more lispy ways.
pngine is using a data language I made for fun with s-expressions and appropriately named "SJON". It is a data language (kinda like EDN, or er.. JSON) to declare things, not to run/interpret things, it has no reader macros, no quote/unquote, no eval, no cons or car/cdr or..., the only thing similar to Lisp is really the surface look, and on the surface triple quotes really feel like they don't belong in there.
But I need to paste WGSL into a config file and WGSL can be full of " and \, and I have no reader to extend.
In a way I'm glad you didn't spend a lot of time and got lost at the start ahah because if the triple quote bothered you the rest would too.
For instance, in SJON strings don't remember their quotes:
It is a data language, and one thing I wanted was for numbers to carry their units:
(camera :ortho :zoom 2 :fov 90deg :shutter 250ms :scale 50%)
; unit is a suffix glued to a number with no space
; oh! and dates and times are also token kinds: 2026-05-19 and 23:59:59.999 lex as values
; these don't get interpreted, just carried over and then the schema decides what is valid
yeah... there is a schema, which is written in SJON too, that is validated ahead of evaluation, and docs have a binary IR, so a tiny runtime can consume one without carrying a parser.
For instance, the SJON schema for the WebGPU spec was sketched from the spec API.
Sorry for the long answer, yeah, it is not Lisp, just S-expressions to leverage a small part of their amazing versatility.
ahah indeed! when I was young someone or something etched into my tiny brain that "thou shalt never abstract a DSL, it is wrong!".
I think I should have outgrown this by now, there is some truth to it but I feel it is certainly not absolute at all, and this is essentially a for fun project with no rules or greater intent beyond that.
You can try to make the WebGPU API more declarative, but the issue that you still run into is that individual draw calls and passes are a poor abstraction level to express modern rendering in.
To reach the quality of a modern PBR renderer with shadows, SSAO, temporal denoising and the like, you need to lower one conceptual draw into multiple concrete draws, sequenced in a particular way, to their own targets, and I haven't seen a lot of success in this space because the shaders need to become polymorphic.
these are very good points, with my attempt the only run-time polymorphism is a switch inside a shader. Maybe we can exploit the pipeline constants and then branch on them, still feels like a hack, but could work for a poor man approach.
I have never done advanced/modern rendering things, just 2D/vector/sdfs and hacks, but your comment is food for thought, in that in this level of abstraction these are somewhat open problems.
I am a big Lisper. You lost me at the triple quote.
hey! indeed, it is a pattern more from Python/Kotlin/etc and on first sight it looks awful for those used to work in more lispy ways.
pngine is using a data language I made for fun with s-expressions and appropriately named "SJON". It is a data language (kinda like EDN, or er.. JSON) to declare things, not to run/interpret things, it has no reader macros, no quote/unquote, no eval, no cons or car/cdr or..., the only thing similar to Lisp is really the surface look, and on the surface triple quotes really feel like they don't belong in there.
But I need to paste WGSL into a config file and WGSL can be full of " and \, and I have no reader to extend.
In a way I'm glad you didn't spend a lot of time and got lost at the start ahah because if the triple quote bothered you the rest would too.
For instance, in SJON strings don't remember their quotes:
It is a data language, and one thing I wanted was for numbers to carry their units: yeah... there is a schema, which is written in SJON too, that is validated ahead of evaluation, and docs have a binary IR, so a tiny runtime can consume one without carrying a parser.For instance, the SJON schema for the WebGPU spec was sketched from the spec API.
Sorry for the long answer, yeah, it is not Lisp, just S-expressions to leverage a small part of their amazing versatility.
Needs a Lisp Shading Language.
ahah indeed! when I was young someone or something etched into my tiny brain that "thou shalt never abstract a DSL, it is wrong!".
I think I should have outgrown this by now, there is some truth to it but I feel it is certainly not absolute at all, and this is essentially a for fun project with no rules or greater intent beyond that.
The triple quote screams scrambled eggs with bacon.
hahah loved this one! so true, can I have a bit of onion too?
Looks interesting but none of the examples worked on the latest iOS safari
I'm sorry they aren't working for you :(
I am running ios 26.6 in iphone mini. Do you know the version and device model where they are failing for you? (in Settings -> General -> Info)
They all worked for me in iOS safari..
You can try to make the WebGPU API more declarative, but the issue that you still run into is that individual draw calls and passes are a poor abstraction level to express modern rendering in.
To reach the quality of a modern PBR renderer with shadows, SSAO, temporal denoising and the like, you need to lower one conceptual draw into multiple concrete draws, sequenced in a particular way, to their own targets, and I haven't seen a lot of success in this space because the shaders need to become polymorphic.
Hi unconed!
these are very good points, with my attempt the only run-time polymorphism is a switch inside a shader. Maybe we can exploit the pipeline constants and then branch on them, still feels like a hack, but could work for a poor man approach.
I have never done advanced/modern rendering things, just 2D/vector/sdfs and hacks, but your comment is food for thought, in that in this level of abstraction these are somewhat open problems.