 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's another one.
This time I start out entirely differently: This language isn't based on
description of hierarchical data, salted with control statements.
This time statements are the one and only thing: A scene file is a list
of statements.
For the sake of preventing ambiguities, and for the sake of consistency,
all statements are terminated by a semicolon unless noted otherwise.
For the sake of continuity, I'll use "#" as first characters of my
control statements again, and for the sake of simplicity I'll stick to
the few ones defined in the last proposal:
#if (CONDITION)
STATEMENT ;
#elif (CONDITION)
STATEMENT ;
#else
STATEMENT ;
#loop (IDENTIFIER)
STATEMENT ;
#break (IDENTIFIER) ;
#continue (IDENTIFIER) ;
A statement may be a block:
{
STATEMENT ;
STATEMENT ;
STATEMENT ;
}
A statement block is the only statement /not/ terminated by a semicolon.
A statement may be an assignment:
IDENTIFIER = EXPRESSION ;
An expression may be a scene element, such as a geometric primitive, a
texture or the like. Such an expression is comprised of a /type/
identifier and a statement block.
sphere { ... }
texture { ... }
A statement may also be a sole expression; in this case, the result is
"dropped into" the block it resides in, as a /child/ of the block:
foo = box { ... }
union
{
sphere { ... }
sphere { ... }
box { ... }
foo ;
...
}
Note how, in contrast to the current SDL, the object expression isn't
wrapped into "object { ... }".
Besides child elements, scene elements also have properties. The
following statement sets a property of the current block:
IDENTIFIER: EXPRESSION ;
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 ;
}
Well, that's about as far as I've thougt this through for now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/13/2015 04:54 PM, clipka wrote:
> Here's another one.
>
Thanks for the earlier response on my comments on #1 - got it I think.
Disclaimer. I'm a hack programmer, not a professional one. While I am
offering opinions, keep in mind I might not know what I'm talking about.
Offering that up because to me your proposal below feels OK to me too.
Thinking a statements approach might be somewhat simpler initially for
users new to SDL.
Is it an aim for the new inbuilt SDL to be a language easier for those
with no programming experience to use?
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.
> This time I start out entirely differently: This language isn't based on
> description of hierarchical data, salted with control statements.
>
> This time statements are the one and only thing: A scene file is a list
> of statements.
>
> For the sake of preventing ambiguities, and for the sake of consistency,
> all statements are terminated by a semicolon unless noted otherwise.
>
> For the sake of continuity, I'll use "#" as first characters of my
> control statements again, and for the sake of simplicity I'll stick to
> the few ones defined in the last proposal:
>
> #if (CONDITION)
> STATEMENT ;
> #elif (CONDITION)
> STATEMENT ;
> #else
> STATEMENT ;
>
> #loop (IDENTIFIER)
> STATEMENT ;
>
> #break (IDENTIFIER) ;
>
> #continue (IDENTIFIER) ;
Is the IDENTIFIER the loop variable and optional ?
>
> A statement may be a block:
>
> {
> STATEMENT ;
> STATEMENT ;
> STATEMENT ;
> }
>
> A statement block is the only statement /not/ terminated by a semicolon.
>
> A statement may be an assignment:
>
> IDENTIFIER = EXPRESSION ;
>
> An expression may be a scene element, such as a geometric primitive, a
> texture or the like. Such an expression is comprised of a /type/
> identifier and a statement block.
>
> sphere { ... }
> texture { ... }
>
> A statement may also be a sole expression; in this case, the result is
> "dropped into" the block it resides in, as a /child/ of the block:
>
> 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 ?
>
> Besides child elements, scene elements also have properties. The
> following statement sets a property of the current block:
>
> IDENTIFIER: EXPRESSION ;
>
> 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.
Perhaps it is just my long term memory is less capable than others, but
after being away from POV-Ray for a time I always find myself again
looking up syntax for things. Why my own SDL generating code tends to
look like:
DefSphere MySphere -center <0,0,0> -radius 1.0
>
> Well, that's about as far as I've thougt this through for now.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
> Perhaps it is just my long term memory is less capable than others, but
> after being away from POV-Ray for a time I always find myself again
> looking up syntax for things. Why my own SDL generating code tends to
> look like:
The problem is though, you'll forget whether the parameter is called
"center", "position", "location" or "centre", and then have to look it
up anyway. And that's for something simple like a sphere. Imagine you
come to include something as horrendously complex as a cylinder or cone
in your scene, what are the parameter names for the two end points?
Personally I find it far easier to remember the order of parameters than
the names.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/14/2015 09:50 AM, scott wrote:
>>> 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?
I fully expect any new SDL would allow both styles.
The advantage of the more verbose form gets to my question as to whether
part of the aim of a new SDL is to make it easier for new users /
non-programmers to use POV-Ray. The tendency for us as experienced users
is to think specifically about what we most want going forward.
Is part of the aim of a new SDL to broaden usage? If the answer is yes,
I think this goal should influence the form any new SDL takes. In part
doing this by enabling a default style of coding which is more explicit,
more flexible and forgiving as to order and specification.
Today we have things like map types, interpolation types which are just
numbers. There are rules to position and order such as where gamma must
be specified within an image_map. We get used these rules, but they are
just requirements driven/caused by our current SDL implementation.
Requirements which make it harder for the new or casual user to join us
on the ray-tracing playground.
Even with todays sphere syntax, suppose a new user sees sphere { 0.2,
0.5 }, and tries to guess implementation. The programmer oriented short
cuts are no doubt helpful for those coding daily, but they come at the
loss of clarity for those not.
Side story: When I started my first real job out of school I had a pile
of test data I needed to munge. I mentioned what I needed to an older
co-worker - who seemed really old to me at the time at probably 40 - and
he said, "that's easy with a little APL." We went to his office and to
his special keyboard with the APL character support. In about 10 minutes
we had a single line of code maybe 60 characters long that did
everything I wanted & more. I was dumbfounded. I'd written code in
Assembler, Basic and Fortran by the point, but I'd had no prior exposure
to APL. That line of APL was a magic incantation.
>
>> Perhaps it is just my long term memory is less capable than others, but
>> after being away from POV-Ray for a time I always find myself again
>> looking up syntax for things. Why my own SDL generating code tends to
>> look like:
>
> The problem is though, you'll forget whether the parameter is called
> "center", "position", "location" or "centre", and then have to look it
> up anyway. And that's for something simple like a sphere. Imagine you
> come to include something as horrendously complex as a cylinder or cone
> in your scene, what are the parameter names for the two end points?
> Personally I find it far easier to remember the order of parameters than
> the names.
>
If coming to a clean slate and not returning to existing code that can
certainly be true. Where I have coded wrappers for POV-Ray language
elements, my look up for valid options is : DefSphere -h so not too bad,
but yep, nothing perfect and our preferences will differ.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
