Le 15-12-15 13:18, clipka a écrit :
> 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.
>
>

Maybe have some mandatory specific/unique prefix for an IDENTIFIER, and 
not for an expression.
Maybe one of those: _ @ $ % could be used as an IDENTIFIER prefix.
The IDENTIFIER may be enclosed in a prefix/postfix pair: @Outer@ or #Outer#

Post a reply to this message