Am 14.12.2015 um 13:54 schrieb William F Pokorny:

> Is it an aim for the new inbuilt SDL to be a language easier for those
> with no programming experience to use?

My goal is for the new language to be /at least/ as easy to learn as the
current one; if it's possible to make it even easier without sacrificing
anything fundamental, then that's pretty cool, too.

It is also my goal for the new language to be much more consistent,
which in and of itself may already have the side effect of making the
language easier to learn.


> I see the primary aim as cleaning up the SDL internal and external to
> POV-RAY for current use and extension. I tripped again the other day
> trying:
> 
> #declare WarpSevenScotty = warp {...}
> ....
>     warp { WarpSevenScotty }
> ....
>     warp { WarpSevenScotty }
> 
> which I believe should work if behavior was consistent in the current
> SDL, but it doesn't. A reused macro with the common warp is my work around.

That's one of the inconsistencies in the current SDL.

In the current SDL, warps can only be specified "inline". The fact that
such "inline-only" constructs are even possible is a side effect of the
syntax including dedicated language constructs for each and every type
of data element that is part of a scene's hierarchy. This way, the
"warp" construct can be implemented in a manner that it cannot be stored
in a variable.

In the new SDL, there would be no language construct "warp"; instead,
there would be a more generic language construct "scene element", or
maybe even more generic, "typed data aggregate": An arbitrary thing that
has a fixed set of mandatory and optional properties and possibly a list
of children (depending on the exact type of the thing).

With this property of the language, it will actually take some effort to
exclude "warp" from the set of assignable things -- and if the parser is
written properly, there will be no reason for such a deliberate exclusion.


>>    #if (CONDITION)
>>      STATEMENT ;
>>    #elif (CONDITION)
>>      STATEMENT ;
>>    #else
>>      STATEMENT ;
>>
>>    #loop (IDENTIFIER)
>>      STATEMENT ;
>>
>>    #break (IDENTIFIER) ;
>>
>>    #continue (IDENTIFIER) ;
> 
> Is the IDENTIFIER the loop variable and optional ?

No, in the above construct, IDENTIFIER just identifies a particular
loop; this allows you to break out of nested loops, as in:

    X = 0;
    #loop (Outer) {
      Y = 0;
      #loop (Inner) {
        #if (...) #break (Outer);
        Y = Y + 1;
      }
      X = X + 1;
    }

The identifier should be optional, though I'll have to think about how
the parser knows whether a "(" following the "#loop" introduces a loop
identifier or a "dropped" expression.


>>    foo = box { ... }
>>    union
>>    {
>>      sphere { ... }
>>      sphere { ... }
>>      box { ... }
>>      foo ;
>>      ...
>>    }
>>
>> Note how, in contrast to the current SDL, the object expression isn't
>> wrapped into "object { ... }".
> 
> Simpler for direct use, but supposing it could be wrapped in object { }
> if we say wanted to translate it inside the union ?

Sounds like a reasonable suggestion.


BTW, for the sake of avoiding misunderstanding, I'd actually like to
avoid "object", as it has acquired special meaning in the world of
modern programming languages. Maybe "shape" would be a suitable replacement.

Post a reply to this message