On 2026-05-05 15:02, Bald Eagle wrote:
> Perhaps you could take a bit of time to explain how the parser gets handled.

When using Nim, as I do there are two and two halve options.

- Just use Nim as I have done now (could be cleaner), no need to write a 
parser as we use Nim's parser & compiler.

- A halve option adds a Domain Specific Language on top. That is created 
using Nim's macro system (AST rewriting at compile time). It is still 
pure Nim and the DSL could be done for scene description while using 
usual Nim code for the rest functions etc. Look at it as a syntax sugar 
layer:

scene:
   camera perspective:
     pos    = vec3(0, 1, 2)
     lookAt = vec3(0, 0, -3)
     fov    = 60

   sphere:
     center   = vec3(0, 0, -3)
     radius   = 1.0
     material = red

   pointLight:
     pos       = vec3(5, 8, 2)
     intensity = 100

Squiggels can probably be added to make it look more POV-Ray.

- A halve option would be to use Nim's scripting language. That would 
require no compilation but it does not (yet?) fully / seamlessly 
integrate with the compiled version. But it still looks and feels the 
same as Nim

- An option would be to write a full scene parser. I have not arrived at 
that stage, but feel it as "limiting".

Nim3 is in the making, a part of it is a Lisp like language that could 
bridge a parser and the Nim compiler. If I understand it all correctly.

https://github.com/nim-lang/nifspec/blob/master/README.md
https://github.com/nim-lang/nifspec/blob/master/doc/nif-spec.md

A front end parses and converts "POV-Ray SDL" and outputs:
(.nif27)
(.lang "raytracer")
(stmts
   (camera@2,1 (vec3 0.0 1.0 2.0) (vec3 0.0 0.0 -3.0) 60.0)
   (sphere@3,1 (vec3 0.0 0.0 -3.0) 1.0 (material :red.0.materials))
)
Nim parses it, compiles and renders.

But, what becomes clear in the discussion so far, we are trying to solve 
different problems.

ingo

Post a reply to this message