 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/12/2015 20:30, clipka wrote:
> Am 14.12.2015 um 15:50 schrieb scott:
>>>> All object properties are set via identifier, rather than anonymlously
>>>> by position; for instance, instead of
>>>>
>>>> sphere { CENTER, RADIUS }
>>>>
>>>> it will be:
>>>>
>>>> sphere {
>>>> center: EXPRESSION ;
>>>> radius: EXPRESSION ;
>>>> }
>>>>
>>>
>>> I personally like this form though more verbose. Any syntax more
>>> explicit about what property is being set is much clearer to new users
>>> especially - expect many periodic users too.
>>
>> Why not allow both styles? Is there any benefit to forcing one way or
>> the other?
>
> Absolutely: Mandating that all properties be identified by name rather
> than position makes it much easier to split the language definition into
> a simple basic syntax on one hand and a data hierarchy model on the
> other hand.
Much easier for who? The users or the developers? Does the benefit for
the users outweigh the inconveniences of having to look-up/remember and
type out (or copy and paste) the parameter names every single time?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
> On 14/12/2015 20:30, clipka wrote:
> > Am 14.12.2015 um 15:50 schrieb scott:
> >>>> All object properties are set via identifier, rather than anonymlously
> >>>> by position; for instance, instead of
> >>>>
> >>>> sphere { CENTER, RADIUS }
> >>>>
> >>>> it will be:
> >>>>
> >>>> sphere {
> >>>> center: EXPRESSION ;
> >>>> radius: EXPRESSION ;
> >>>> }
> >>>>
> >>>
> >>> I personally like this form though more verbose. Any syntax more
> >>> explicit about what property is being set is much clearer to new users
> >>> especially - expect many periodic users too.
> >>
> >> Why not allow both styles? Is there any benefit to forcing one way or
> >> the other?
> >
> > Absolutely: Mandating that all properties be identified by name rather
> > than position makes it much easier to split the language definition into
> > a simple basic syntax on one hand and a data hierarchy model on the
> > other hand.
>
> Much easier for who? The users or the developers? Does the benefit for
> the users outweigh the inconveniences of having to look-up/remember and
> type out (or copy and paste) the parameter names every single time?
Let's put it this way: What good is a user-friendly syntax if no user ever gets
to use it, because its implementation is never finished?
Remember, your question was whether there is any benefit to forcing one way or
another; here is one. Development manpower is a limited resource, and while I do
want to take some time to design a reasonably usable language, I think the whole
matter of nameless properties is too controversial to make it onto the list of
mandatory features of the language.
Regardless of whether properties are identified by name or by position -- there
is always /something/ you will have to remember; and with that being the case,
I'd really love to avoid the added work attached.
Also, the simpler the language, the easier and faster the scene code may be
analyzed as the user is typing; I'd expect the language to be simple enough so
that the editor may assist the user on-the-fly in remembering the property names
by providing auto-completion.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Much easier for who? The users or the developers? Does the benefit for
>> the users outweigh the inconveniences of having to look-up/remember and
>> type out (or copy and paste) the parameter names every single time?
>
> Let's put it this way: What good is a user-friendly syntax if no user ever gets
> to use it, because its implementation is never finished?
>
> Remember, your question was whether there is any benefit to forcing one way or
> another; here is one. Development manpower is a limited resource, and while I do
> want to take some time to design a reasonably usable language, I think the whole
> matter of nameless properties is too controversial to make it onto the list of
> mandatory features of the language.
OK, well I guess I should have been clearer that I was talking about
user benefits. But yours is a valid point, there isn't unlimited
developer resource.
> Also, the simpler the language, the easier and faster the scene code may be
> analyzed as the user is typing; I'd expect the language to be simple enough so
> that the editor may assist the user on-the-fly in remembering the property names
> by providing auto-completion.
VS C# style auto-completion (and all the other pop-up helper things in
the editor) would be amazing for POV. I only realise how much all those
things help speed up development when I have to use another editor (even
the VS C++ editor is poor in comparison). Obviously if we can assume
there will be an editor with a half-decent auto-complete, the arguments
are different somewhat.
Is developing an editor within the scope of POV4 too then?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
