hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/23/20 2:25 PM, Bald Eagle wrote:
> >
> ...
> First, reminding everyone 'povr' is not POV-Ray. I'm combining my
> responses and when I start to think about major revisions to POV-Ray's
> SDL, I begin to think seriously about bindings to lua, tcl and python.

so, it is late and I had too much coffee, probably..  :-)

how about replacing the SDL, wholesale?!

not knowing the codebase[*], but if the "SDL" was simply a (Tcl) "safe
interpreter", with all the SDL language constructs as commands, then we could
write something like:

set version 3.8

array set global_settings {
  assumed_gamma 1
}

light_source {-1 0 -1 10e5} {color {1 1 1} parallel}


:-)

[*] assuming that the source except 'frontend' and 'parser' stuff would be
(relatively) unaffected.

added, potential, incentives: storing the distribution .inc files,
pre-processed, in a Sqlite db; using a zip VFS for managing/distributing
projects with many files; "reflected channel" to read compressed .inc files (for
large meshes, or Hilbert curves :-)).

flights of fancy..

> ...
> (1) ... if we had the list support.

would be built in.  ;-)

> ...
> (3) - Most namespace languages to which I've been exposed support a
> 'using <namespace>::min' sort of declaration. These often get used -
> because people don't like to type - but, allowing the shorthand can
> weaken the namespace protections.

a typical "Problem Exists Between Chair And Keyboard" problem.

> --- On jr's point about no type checking. I think we are not too
> exposed. While there is no strict up front type checking, it looks to me
> like the parser tracks the current id types so you cannot incorrectly
> use the wrong type due a bad/unfortunate assignment somewhere.

sure, I just think that, just like for regular arrays, when an identifier has
been "cast" to type A, a subsequent assigning of type B should output a warning
(preferably cause an error).  because, in all likelihood, it'll be a typo or
logic error.

> ...
> --- On eval_pigment / Eval_Pigment (and alias capability). I've never
> liked eval_pigment! It's not inbuilt, but we talk about it like it is.

naive question.  calling the macro returns the colour in pigment at given point.
 but what good is that information, given that lighting is not part of the
process?


regards, jr.

Post a reply to this message