On 6/27/24 18:47, Cousin Ricky wrote:
> On 2024-06-27 11:44 (-4), William F Pokorny wrote:
>> Release R15 of the yuqk fork has an implementation supporting constant
>> identifiers / macro parameters. They are indicated by using a leading
>> '_' character in the name.
> 
> I also agree with Ingo: a keyword or directive would be better, such as:
> 
>    #const MagicNumber = 12345;
> 
> I'm thinking a keyword modifier would be more flexible than a directive,
> for example:
> 
>    #declare const GlobalVal = 12345;
>    #local const LocalVal = 54321;
> 

Thanks, everyone, for the feedback & thinking toward v4.0.

The yuqk fork is intended to be a playpen for features like this. 
Nothing about any given change or feature is set in stone. It might be 
the current implementation for read only variables gets dumped in part 
or in total after using it for while. I think it a decent approach, but 
I've not used it nearly enough myself to know. It is, likely, the only 
sort of global-ish thing doable with respect to identifier constant-ness 
given the state of our current Scene Description Language (SDL).

With our SDL and parser, we don't have a cleanly scoped and typed 
'variable' declaration system which allows more naturally for the 
propagation and maintenance of constant information. (Any v4.0 SDL 
re-work should probably treat scene identifiers complete apart from the 
language variables)

My initial runs at some constant identifier support started with the 
idea of all macro parameters being considered constant. However, I ran 
across cases where users had macros which used the pass by reference and 
change behavior.

I then started to look at a new 'const' keyword only with macro 
parameters while thinking about how I might extend its usage before 
concluding. There are a great many complications due how our language 
and parser work which drive the need for language refinement or ugly, 
complicated code infrastructure. I dropped the whole idea for years.

With yuqk, I've been forced to create prefixed language SDL keywords to 
fix bugs and enable features. Over time, I started to see it's more or 
less the same kind of weak scoping of functionality in our SDL. Where I 
adopted prefixed keywords the source code too became more understandable 
and manageable. I now plan, over time, to broadly adopt SDL keyword 
prefixes. With this next R15 yuqk release I'll have three in keyword 
prefixes in play with ii_ (input image), ip_ (internal 
pattern/perturbation) and it_ (internal turbulence).

One day, not long ago, it hit me that maybe identifier prefixes would be 
a way we could implement reasonably broad, useful constant-ness - though 
not completely robust, constant-ness. When I started to really look at 
implementing the idea, it turned out it was an amount of code work I 
could manage.

While working in yuqk, the features implemented are often not exactly 
what I'd wish for in v4.0! They are what I can manage and/or am forced 
to do in the context of the yuqk/POV-Ray implementation as it is.


---
(BW) > Is that a scene-wide global thing?

Currently, it's always on and acts depending on context and what's 
defined in each context. There isn't yet a way to configure with the 
feature off as there is with no lower case identifier checking - which 
is on by default in yuqk.

I think you're right, I need to go work on that configuration option 
before releasing R15. We should be able to create executable(s) with the 
checking off.

As for users switching the checking on and off on the fly... I think, 
such control runs counter to the aim of the constant-ness feature itself.

---
(ingo, jr, et al)

I realize there is a fair bit of _xyz parameter and identifier usage. 
It's in a lot of my own stuff too. Much of that will break - sometimes 
while pointing out existing exposures too. I haven't played enough to 
have a feel for the level of pain.

Given I'm going to delay to implement a build configuration option for 
this feature, do you think some other prefix would be better? ('_r', 
'ro_', 'r_', ?)

---
(jr)

Remember yuqk reduced the functionality of the 'optional' keyword to 
just macro parameters due bugs and that when I really looked at broader 
use, I found a new world space for confusing, extremely difficult to 
debug, SDL bugs.

---

The larger view is the yuqk fork is breaking compatibility with official 
POV-Ray releases.

I don't do it lightly because I want to be able to run scenes aimed at 
official releases too, but breakage is unavoidable given I want to 
address certain bugs, features and deficiencies.

Bill P.


Aside 1: I have still bugs and issues with the current global / local 
dictionary behavior in v3.8+ to sort... Our implementation doesn't match 
our documentation and we probably need a #top (or #upid (upvar n)) 
directive alongside #directive and #local.

Post a reply to this message