POV-Ray : Newsgroups : povray.general : #ifdef using a string expression? : Re: #ifdef using a string expression? Server Time
28 Mar 2024 20:09:36 EDT (-0400)
  Re: #ifdef using a string expression?  
From: Bald Eagle
Date: 19 Mar 2023 17:55:00
Message: <web.6417846d98df09c91f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> The few 'keywords' I've tested these generate a warning in at least some
> versions of POV-Ray. But it's weird, keywords NOT returning immediate
> numbers or strings are also considered 'defined' in these versions
> though they are in fact arbitrary SDL keywords.

I think you're going to run into the same hamstringing that an over-concern
about backwards compatibility inevitably results in.  If any of this stuff is
going to be fixed, there needs to be a clean break, and a sane, logical,
rational, basis for moving forward.

> Even this worked in the pre-backed off v3.8 release parser:
> #ifdef(#declare V=99;#undef V)
> Though without some other mistake it would usually die with a later
> unmatched something parsing fail.

That looks fine - given someone may have some reason to do that.  Some sort of
quick bypass workaround.


> I will always die if somebody tries use the undef'd V.

Yes.  Because V is for Victory, and undefining it results in Failure.  :P

> So, much more was being supported as testing true in povr/v4.0, but
> still not some things like raw vectors. Though things like x,y,z are OK.

.....

> Further, the extra now being
> changed currently in the v3.8 code is not consistent with respect to
> things like pi - which to the parser is an immediate value of pi. And
> datetime would be an example of an immediate string which would test
> true, you'd think, if "string" does.
>
> What to do... I could spend a lot of time trying to figure out the
> history here, but I think the current state not completely tenable since
> 2015...
>
> We need functionality which deals only with IDs.
>
> We, perhaps, need some sort of what is in the parenthesis is 'defined'
> functionality too, but the generic sort being allowed or not seems
> questionable to me. Are people already using this functionality?

I use and abuse whatever I can find as a workaround for lack of functionality.
I absolutely don't mind rewriting code to perform with a new and better version.

Currently trying to implement some geometric testing code, it's becoming
increasingly clear that we have plenty of raytracing capability, and missing
programming code to make coding the scenes easier and more capable.

Example:
I'm testing for an intersection.  What do I do in SDL if there's a) none, or b)
more than 1?   Or if I'm looking at parallel or skew lines.  Or the user or the
circumstances require the endpoints of a line to be the same (a point)?

I'm dreaming up workarounds like mixed arrays with succeed/fail flags followed
by the variable number of results (line/line | line/circle | circle/circle).
For data type cast, I'm thinking I need a 2D mixed array with the [0] holding
the data type as a string, and the actual data in the 1[].

It would be so much easier to code these things (and faster) if we had some
tools to deal with variable results.

null, NaN, variable type detection, error trapping, etc.
It would make testing with #ifdef a little more sane if #ifdef (keyword)
returned a versatile value that I could make use of in a broad number of
circumstances.

First - I think POV-Ray needs to sort out keywords vs values, scalars vs
vectors, vs parse/render/function space variable names.  It's confusing, and is
contributing directly to the mess you're trying to sort out. You can't.  It's
all inextricably mixed.  clipka correctly pointed out that all of this stuff
needs to get disentangled in the parser.

So, I would say that "if" should return a value that denotes keyword,
whereas "pi" should return a value that denotes a reserved value.  "CONST", or
whatever that compiler one is.  "PRAGMA"

It's "nice" that I can swizzle things all over the place between vectors and
colors, etc.  But it makes for lazy / bad programming practices.  Better the
ability to recast a value from a scalar to a vector to a color, etc.

It would probably take me a month, tops, to adapt to the new requirements, and
I'd be able to write better, shorter, more easily understood and maintained
code.  Further, if there were sufficient programmatic capability, "fixes" for
old scenes could be coded, much like TOK and I code custom functions and macros
to handle pow (0, 0), factorial, N choose M, mod () crossing the origin, etc.
Just change the keyword in the old scene to a capitalized version ("We love you,
jr!") and boom - you have a macro that could possibly handle a lot of the
backward compatibility with a simple find/replace on the old scene file.

The first rule of holes is: when you find yourself in one, stop digging.
The second is: climb out.

I'd rather suffer now, and profit later.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.