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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 15/12/2015 18:13, Dick Balaska a écrit :
> In article <5670382d$1@news.povray.org>, sco### [at] scottcom says...
>> 
>> Is developing an editor within the scope of POV4 too then?
> 
> 
> I think leveraging eclipse as an IDE would be the way to go. 
> They've already solved the problems you mentioned and presented it
> in a plugin enhancable package. Like this one: 
> http://povclipse.sourceforge.net/ (I haven't used povclipse yet.)
> 
I did.. it was tied to 3.6, and it did not evolve (when I looked at
it, 2 or 3 years ago) with eclipse... which means it is hard to have
it working for something else.

If you understand it, maybe you can fix & update it for modern eclipse
and povray.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlZwad8ACgkQhKAm8mTpkW2vTgP+KPsJ6A6BMZdY3ffSM+c+XYDj
jRFWEe/aXn0MzMiU2pS6vQLfumOTOK/zsEA0iFCdm0CYIxHC97Jy7V5cY1rXDKmP
BVJKuDSdJ0/yAZpArhXnBcdmPJbyPqx+EpJ0xz82fuw8QU3ymHsLeCbROBh2+3ez
3b7a14QFGCq6g60hejo=
=+bPk
-----END PGP SIGNATURE-----

Post a reply to this message

If you make substantial changes in the SDL, while still trying to keep
compatibility with the "old" SDL, a
#version XY;
will from then be necessary. And if its missing ... its by default the new SDL.

Ok, so if thats also "whats your wish" Post,

From my standpoint i would like to see more structures like procedures and
subprogrammes with local variables.

The possibility to make "Libraries" of include files with local variables and
local procedures.

Possibility of coordinates, Textures as well as Objects as parameter for input
and output.

Inside the procedure all Object/Texture attributes can then be altered.

And if we talk about meshes ... its also an object that could be altered inside
a procedure.

This way you can define Libraries that that will "deform" an "input-Object" and
return it as an Object, or as an mesh.

And if we have that its not a large step to allow "Collections of Objects" as
variable and as Parameter. Because this is just a List and a Loop around the the
Single Object.

Then you can pass a whole scene to a library for transformation.

Post a reply to this message

On 1/20/2016 11:50 AM, Theogott wrote:
> If you make substantial changes in the SDL, while still trying to keep
> compatibility with the "old" SDL, a
> #version XY;
> will from then be necessary. And if its missing ... its by default the new SDL.
>
> Ok, so if thats also "whats your wish" Post,
>
>  From my standpoint i would like to see more structures like procedures and
> subprogrammes with local variables.
>
> The possibility to make "Libraries" of include files with local variables and
> local procedures.
>
> Possibility of coordinates, Textures as well as Objects as parameter for input
> and output.
>
> Inside the procedure all Object/Texture attributes can then be altered.
>
> And if we talk about meshes ... its also an object that could be altered inside
> a procedure.
>
> This way you can define Libraries that that will "deform" an "input-Object" and
> return it as an Object, or as an mesh.
>
> And if we have that its not a large step to allow "Collections of Objects" as
> variable and as Parameter. Because this is just a List and a Loop around the the
> Single Object.
>
> Then you can pass a whole scene to a library for transformation.
>

If we have deformable meshes, then maybe we can have character 
animations with bones and rigging.


Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:

> If we have deformable meshes, then maybe we can have character
> animations with bones and rigging.

Yes, I do concede that posable meshes would be cool.

It most likely won't be supported natively, but my hope is to get a language
that is powerful and fast enough to reasonably add such support by means of
include files. (And yes, having deformable meshes implemented natively would
seem to be a prerequisite for that.)

Post a reply to this message