 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So... after 30+ year ago, here is the answer tomy question: when is
POV-Ray 4 is going to go out? Me and many others, that were quickly met
with belligerent: it's going to be when is done, now STFU about it and
never ask the fucking question again in your life! Or be banned from the
entire pov-ray newsgroup! Or something to that shock effect; but I feel
other and I contributed my 2 cents to keep things, at least alive, if
not greasing them a little, until they started going; hey, I pushed Warp
to join as an active programmer, so your welcome bitches! LOL :-D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So... after 30+ years
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> As a starting point, I'll take an existing language
Okay, Maybe what follows is incompatible with this language I know nothing
about, so ignore my remarks in that eventuality because I do value that idea of
leveraging the best and closest standard if possible.
> A simple POV-Ray scene described in this format might look like this:
[...]
> {
> camera: {
> up: [ 0, 1, 0 ],
> right: [ 1.33, 0, 0 ],
> direction: [ 0, 0, -1 ],
> location: [ 0, 0, 5 ],
> look_at: [ 0, 0, 0 ]
> },
> objects: [
> light_source {
> location: [ -100, 100, 100 ],
> colour: #FFFFFF
> },
> sphere {
> location: [ 0, 0, 0 ],
> radius: 1,
> texture: {
> pigment: {
> colour: #FFFFFF
> }
> }
> }
> ]
> }
The first thing bothering me is the combination of colons and brace characters
in some places or maybe rather that it seems it can't be used the same way
elsewhere?
Would we have to write camera: {
It would seem a little cluttered to have to use a : for just specifying the
opening of a block. do we have to ? ... why not:
camera{
up: [ 0, 1, 0 ],
right: [ 1.33, 0, 0 ],
direction: [ 0, 0, -1 ],
location: [ 0, 0, 5 ],
look_at: [ 0, 0, 0 ]
},
Also for same reason, would the comma after the brace really be necessary ?
> Next we need variables; again we don't want them to collide with our
> unquoted strings, so I'll use just about the same trick, except that I
> use "@" to refer to variables.
Fine,
> center: @@Bar // look what I just did there
I'm not sure I understand, maybe that's why, but it looks a little barbarian to
my delicate profane eye :-) Does json force to specify like this instead of some
"object" dot lookup operator?
> There. Behold your new SDL, chilren of POV-Ray.
Yay ! great to see some direction, and a great start !
> One possible change to the syntax could be the use of regular braces
> around list items instead of square brackets to specifically denote
> vectors, if only to make it more pleasant to read.
I believe readability would suffer and prefer your proposition versus curly
braces everywhere whith no rythmic to distinguish what's inside what though the
too-many-different-enclosing-signs margin is probably easily reached, so <>
could go away as far as i'm concerned
> I'd also love to add ranges to the set of types, using a syntax akin to
> this:
>
> [ 1 .. 20 ] // range from 1 to 20, both inclusive
> ( 1 .. 20 ) // range from 1 to 20, both exclusive
> [ 1 .. 20 ) // range from 1 inclusive to 20 exclusive
> ( 1 .. 20 ] // range from 1 exclusive to 20 inclusive
Personally I think this looks pretty cool! But again I'm no expert at all.
> symbols as (entirely optional) syntactic sugar.
Sounds awesome as well and a breath of fresh air for such a feature rich
program, it also goes well with the cypher obscure reputation of POV, except for
once it would have some real benefits, I assume, in code parsing computation
times ? But with the prerequisites that they should have an explicit
alternative for when we don't know or have any internet to check for the code to
type. most people never enter a unicode special number their whole life. but
maybe the parsing times could really be worth that learning?
This brings to my mind the topic even outside of the mathematical field of some
unicode symbols or even some more common non ascii characters, sorry if too off
topic for lack of terminology and specialists concepts here, but my naive
expectations for POV sdl of my dreams :
a)It should strive to still look intuitive and elegant to non programmers,
preferably one & looks better than two or three && or @@ except where
conventions are long there in several mainstream languages like comments with
doubled chars // for many languages and some alternative doubled sign in many
more others.
b)May we try to keep it easy to type with less modifier keys across the two or
three most used keyboard layouts, since we don't want povers to have carpal
tunnel. (but probably the most cryptic unicode are easier to call by their id
number than some of the characters available of the keyboard layouts requiring
to type a space before they appear and one of two alt keys etc...
I'm getting lost in that stream of thoughts, wishes and good intentions, so I
should stop especially as I trust the experts around here a lot more !
Thanks for giving this a lot of thought!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
delete this message, I can't do it myself from Mozilla Thunderbird,
tried to unsubscribe and subscribe several times, tried several methods
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
delete this message, I can't do it myself from Mozilla Thunderbird,
tried to unsubscribe and subscribe several times, tried several methods,
it was a moment of insanity, sorry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
delete this message, I can't do it myself from Mozilla Thunderbird,
tried to unsubscribe and subscribe several times, tried several methods,
it was a moment of insanity, sorry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > A simple POV-Ray scene described in this format might look like this:
> [...]
> > {
> > camera: {
> > up: [ 0, 1, 0 ],
> The first thing bothering me is the combination of colons and brace characters
> in some places or maybe rather that it seems it can't be used the same way
> elsewhere?
> Would we have to write camera: {
> It would seem a little cluttered to have to use a : for just specifying the
> opening of a block. do we have to ?
I would say that some of these things will have to be looked at from the
perspective of
1. the developer / parser
2. the end user
I would like it if we could dispense with some of the brackets altogether, and
just have a LF/CR/NL or new keyword signal the end of a statement.
On the other hand, I _would_ like to have explicit endings for code blocks, such
as
#endcamera
#endif
#endfor
#endwhile
as I think that overall it would be in the long run easier from both
perspectives to follow and debug code.
> > One possible change to the syntax could be the use of regular braces
> > around list items instead of square brackets to specifically denote
> > vectors, if only to make it more pleasant to read.
There has been some discussion about typing and automatic vector promotion.
Getting rid of brackets and braces altogether would make a little less typing to
do, but maybe it would be worth it to lose that benefit if we had to specify
things like vec2, vec3, vec4 - if only to keep it at the forefront of our minds
what sort of values we're dealing with in any given instance.
> > I'd also love to add ranges to the set of types, using a syntax akin to
> > this:
> >
> > [ 1 .. 20 ] // range from 1 to 20, both inclusive
> > ( 1 .. 20 ) // range from 1 to 20, both exclusive
> > [ 1 .. 20 ) // range from 1 inclusive to 20 exclusive
> > ( 1 .. 20 ] // range from 1 exclusive to 20 inclusive
Ranges would be very nice, but maybe I would like to get rid of the parentheses
in favor of a leading keyword, so that we could instead have all manner of
parentheses available for use in grouping terms in equations without making
parsing (more of) a complicated ordeal.
so, the keywords for the above examples might be ii, ee, ie, ei.
then we could write equations like val = [sin (x+3) / pi] + (tau/6) -
abs{cos[(q/360)+(<n/0.5>+0.5)]};
It would also be nice to drop the requirement for #declare and just write
x=3;
> > symbols as (entirely optional) syntactic sugar.
This would be very nice, especially for placing the text/symbol in the render.
The same would go for a mechanism for exposing the text of a parsed line of code
to the SDL.
What I mean by that is to have a mechanism similar to that in a spreadsheet
whereby if cell A3 has (x+1)/10 in it, then formula (A3) returns the string
"(x+1)/10"
> But with the prerequisites that they should have an explicit
> alternative for when we don't know or have any internet to check for the code to
> type. most people never enter a unicode special number their whole life. but
> maybe the parsing times could really be worth that learning?
We could do that with an include file, like we have with functions.inc -
symbol.inc could have #declare sym_nabla = symbol (U+2207); or however it would
get coded.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.06.2021 um 20:13 schrieb Bald Eagle:
>>> I'd also love to add ranges to the set of types, using a syntax akin to
>>> this:
>>>
>>> [ 1 .. 20 ] // range from 1 to 20, both inclusive
>>> ( 1 .. 20 ) // range from 1 to 20, both exclusive
>>> [ 1 .. 20 ) // range from 1 inclusive to 20 exclusive
>>> ( 1 .. 20 ] // range from 1 exclusive to 20 inclusive
>
> Ranges would be very nice, but maybe I would like to get rid of the parentheses
> in favor of a leading keyword, so that we could instead have all manner of
> parentheses available for use in grouping terms in equations without making
> parsing (more of) a complicated ordeal.
>
> so, the keywords for the above examples might be ii, ee, ie, ei.
>
> then we could write equations like val = [sin (x+3) / pi] + (tau/6) -
> abs{cos[(q/360)+(<n/0.5>+0.5)]};
> It would also be nice to drop the requirement for #declare and just write
> x=3;
I think we can have both.
The style of range notation is deliberately chosen to make it easy to
determine what is the start of something and what the end; for instance,
I personally prefer the following alternative notation because I find it
more intuitive with respect to which end is "inclusive" and which is
"exclusive", but _that_ would indeed seriously complicate parsing:
[ 1 .. 20 ] // range from 1 to 20, both inclusive
] 1 .. 20 ] // range from 1 exclusive to 20 inclusive
As for the proposed syntax further above, distinguishing an arbitrary
mathematical expression from a range should be easy: All the parser
needs to do is look at the "..", which we can take as an operator that
takes two numeric values and returns what we might call a "naked range".
Parentheses and/or brackets around such a "naked range" would then
convert that into what we might call a "qualified range". (Further
wrapping a "qualified range" in more parentheses or brackets would have
no additional effect.)
>> But with the prerequisites that they should have an explicit
>> alternative for when we don't know or have any internet to check for the code to
>> type. most people never enter a unicode special number their whole life. but
>> maybe the parsing times could really be worth that learning?
>
> We could do that with an include file, like we have with functions.inc -
> symbol.inc could have #declare sym_nabla = symbol (U+2207); or however it would
> get coded.
Explicit ASCII alternatives, hard-baked into the language, would be a
must, IMO. As I mentioned, Unicode symbols would be syntactic sugar. The
ASCII constructs would be the real deal, while the Unicode symbols would
be considered shortcuts.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Explicit ASCII alternatives, hard-baked into the language, would be a
> must, IMO. As I mentioned, Unicode symbols would be syntactic sugar. The
> ASCII constructs would be the real deal, while the Unicode symbols would
> be considered shortcuts.
Okay, and do you confirm that such kind of things would have significant impact
on parse time, like: linearly, if you divide the character amounts by two you
get half parsing code?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.06.2021 um 13:18 schrieb Mr:
> clipka <ano### [at] anonymousorg> wrote:
>
>> Explicit ASCII alternatives, hard-baked into the language, would be a
>> must, IMO. As I mentioned, Unicode symbols would be syntactic sugar. The
>> ASCII constructs would be the real deal, while the Unicode symbols would
>> be considered shortcuts.
>
> Okay, and do you confirm that such kind of things would have significant impact
> on parse time, like: linearly, if you divide the character amounts by two you
> get half parsing code?
No, parser performance is not that simple.
A good parser (which POV-Ray's old one is not by any stretch, and even
the overhauled one is only a step on the way there) will just _scan_ the
whole file once (i.e. identify start and end of each character sequence
that look like a token at first glance - e.g. sequences that look like
numbers, sequences that look like keywords or identifies, sequences that
look like operands, etc.), _tokenize_ it once (i.e. translate those
character sequences into internal numeric IDs, aka tokens), and from
there on just juggle those IDs.
The next steps would be to either...
- walk through those tokens and "execute" them, implementing loops by
processing the corresponding tokens over and over again; in this case
processing the loops again and again would be the bottleneck.
- digest that token sequence even further, "compiling" it into something
that can be executed so efficiently that it might have a chance to
become negligibe compared to the time spent scanning and tokenizing; but
to achieve that, the effort to bring it into this efficient form will
itself outweigh the effort of scanning and tokenizing.
In either case, the genuinely time-consuming portions of parsing will
work on a representation in which the number of characters comprising
the keywords or operands will have become entirely irrelevant.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
