"Can you tell me how much work it would require to add object typing to povray's
sdl?  For instance, determining if something is a scalar, text, vector, or
something else (object)?"

Copilot said:


Reasoned for 1s

Planning types integration for SDL
Below is a practical engineering assessment of the work needed to add object

query at parse time whether an identifier/expression is a scalar, string (text),
vector/color, or an object (mesh, CSG, camera, etc.), and to branch/validate
accordingly.


→ parser → symbol table → function VM) and the public
docs/source so you can see exactly what must change.
hws
+1


Today, SDL is dynamically typed and contextual: the parser decides what an




(type_of(X) = vector) out of the box. Adding this requires:

A stable type taxonomy visible to users (e.g., scalar, vector, color, string,

Parser & symbol table changes so each value/expression has an associated runtime
type tag.
Built‑ins to query or test types (e.g., typeof(expr) returning an
integer/enum; predicates like is_scalar(expr)), and possibly typecase helpers in
SDL.
Diagnostics & compatibility so older scenes still parse identically.
The current pipeline (scanner/tokenizer, parser, symbol table, function VM) is a
good foundation: types can be added with minimal disruption if you keep
evaluation semantics unchanged and only enrich metadata.
programmersought
+2

Where the changes would go
1) Symbol table & value representation
Add a TypeTag to the core value/variant used for identifiers and expression
results. If values are currently represented as a tagged union in the parser
front‑end (e.g., float / string / vector / color / object pointers),
formalize the tag and propagate it everywhere an expression result is produced
or consumed.
Ensure arrays and macros carry either an element type (arrays) or signature

This is a contained but pervasive change (read: mechanical edits), because every
path that constructs a value must set the tag, and every path that consumes a
value can optionally use it for richer error messages. The Parser System and
symbol table are the touch points.
hws

2) Parser / expression typing
Extend expression nodes so each AST node carries a TypeTag after semantic


overloaded contexts (e.g., color vectors), keep compatibility but store the more
specific tag (color vs. vector) when known.
For object blocks (e.g., sphere{} / union{} / isosurface{}), mark the node with
type=object. This code lives in parser.cpp and specialized parsers (materials,
strings, etc.).
mankier
3) Built‑ins & directives

TYPE_SCALAR=1, TYPE_VECTOR=2, TYPE_STRING=3, TYPE_OBJECT=100, etc.
(Version‑gate it under #version 3.8/3.9 to avoid conflicts).
Convenience predicates: is_scalar(x), is_string(x), is_vector(x), is_object(x),

Optional: a #switch(type_of(expr)) pattern in docs as a recommended idiom; the
directive itself already exists (#switch/#case/#end), so users can branch
without new syntax.
These hooks sit naturally alongside existing language directives & functions,



4) Function VM interop
If you keep typeof() and the predicates entirely parse‑time, you can
resolve them in the parser/evaluator without touching the function VM.
If you want typeof() inside function bodies executed by the VM, add a tiny VM

model can pass vectors/strings/objects through as argument types). The VM
currently focuses on numeric functions; any vector/string support you add here
should be consistent with prior plans (e.g., vector VM work).
mankier
5) Diagnostics & tooling


scanning/tokenization already records position info; keep passing it through.
programmersought
Proposed user‑visible API
Minimal, compatible set:




Plain Text


// constants (documented values)
#declare TYPE_SCALAR = 1;
#declare TYPE_VECTOR = 2;
#declare TYPE_STRING = 3;
#declare TYPE_COLOR  = 4;
#declare TYPE_OBJECT = 100;

// built-ins
#declare T = typeof(MyValue);     // returns one of the TYPE_* codes
#declare OK = is_vector(MyValue); // predicate shortcuts
No syntax changes are required; the new functions are enough. (They plug into
existing #if/#switch.)

Effort estimate (with breakdown)
Assumes 1 experienced contributor who has already built POV‑Ray locally.


Work item Files / areas Est. effort

days
Value/Tag plumbing: add TypeTag to value/variant, set on literal creation,

days
Expression typing: annotate AST; flow types through operators & function calls;

Built‑ins: implement typeof() + is_*(); integrate into parser/evaluator;


Tests: unit tests (expressions, arrays, macros, object blocks); golden scenes

Docs: manual page updates & examples docs tree 2 days

full‑time).

Why this is plausible: the parser/tokenizer architecture is already modular and

built‑ins rather than re‑architecting the pipeline. The large file
is parser.cpp (~10k lines), but changes are local and mechanical.
mankier

Compatibility strategy
No behavior change unless users call the new built‑ins.
Guard constants and functions behind #version (or the INI Version= option) so
legacy scenes are unaffected. (POV‑Ray already uses version gating for
parsing semantics.)
stackoverflow

TYPE_COLOR so authors can distinguish if they want to.
Risks / tricky corners
Array/macro typing: You can either give arrays a declared element type (if
known) or return TYPE_ARRAY/TYPE_MACRO and let users decide. Starting with a

Implicit promotions: SDL permits convenient promotions (e.g., color ↔
vector). Be careful not to change evaluation; tags should inform diagnostics and
introspection, not alter coercions.
VM scope: Only needed if you promise typeof() inside VM‑executed user

mankier
Suggested phased approach
Phase 1 (lowest risk): implement TypeTag in parser values, typeof() + is_*() at
parse‑time only; improved error text.
Phase 2: document public constants and add tests across common constructs
(objects, textures, transforms, colors).
Phase 3 (optional): enable typeof() inside function VM bodies with a simple

vectors.
Phase 4 (optional): expose tags for additional categories
(texture/pigment/finish, transformation matrices).
Each phase is independently useful and shippable.

Sources & where to look in code
Parser system overview (scanner → tokenizer → parser → symbol

hws
Core parser files: parser.cpp, parser_expressions.cpp, parser_functions*.cpp,
symboltable.*; tokenizer & reserved words: parser_tokenizer.cpp,

built‑ins, and diagnostics.
mankier
+2

documenting behavior alongside existing directives and functions.

behavior today.
stackoverflow
Bottom line
Adding runtime type introspection to SDL is a small‑to‑medium
enhancement: mostly systematic parser/symbol‑table work plus a couple of

clean, low‑risk improvement that makes macro libraries safer and more

Post a reply to this message