POV-Ray : Newsgroups : povray.pov4.discussion.general : Random POV-Ray 4 SDL proposal, #1 Server Time
18 May 2024 10:18:59 EDT (-0400)
  Random POV-Ray 4 SDL proposal, #1 (Message 36 to 38 of 38)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: jr
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 16 Jul 2021 09:35:00
Message: <web.60f189a12ab8183e5e0fed26cde94f1@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 14.07.2021 um 11:35 schrieb jr:
> > have you looked at Tcl/Tk yet, for inspiration?  has many (imo) natty features,
> > nice, clean syntax, and byte-compiles.
> ...
> At a very first glance, Tcl/Tk sounds like a promising basis: Its main
> purpose (nowadays) is also to describe hierarchical structures (albeit
> not geometric objects and surface properties, but rather GUI elements),
> with programmatic elements mixed in for good measure. Unfortunately, the
> Tk part (which is the description of GUI elements) was bolted on later,
> and in my opinion it shows. At its very core, Tcl is a command
> shell-style scripting language.

yes and no.  I'd argue that the interpreter is the core.  and that is designed
to be extended (with "package"s and other mechanisms), and designed to be
embedded, that is provide scripting support to an application.


> One of the results is that different Tcl statements may have their own
> individual quirky "micro-syntax". Just like all of POV-Ray's individual
> geometric primitive, pattern and what-have-you statements all have their
> own little "micro-syntax" quirks. Any commonalities between them are
> just superficial conventions. Which bothers me to no end.

would not, in the end, a database "backbone" allow to, bit by bit, reduce the
"chaos"? (for instance, the stuff provided in the many /include/ files, if
pre-processed and stored in a db, could then allow the parser to simply "paste"
the code actually used, on demand so to speak)


> In my opinion, the best approach to judge a language for suitability as
> the basis for a new SDL is to ask (and answer) the following three
> questions:
>
> - "What is the 'grammar' of this language, i.e. the core principles that
> govern its syntax?"
>
> And based on that:
>
> - "How would a simple scene be described in this language?"
> (A chrome sphere on a colorful checkered plane, with camera and all, and
> maybe a text object to showcase strings, should do as a first example.)
>
> - "How would programmatic elements mesh with this syntax?"
> (A simple example with a loop and a few conditionals should be a
> reasonable starting point.)
>
>
> When I do that for Tcl/Tk, I find that the results look - in my mind -
> ugly AF.

agree that "just translating" does not work too well.  and the fact that Tcl
does not provide "traditional" arrays is another drawback.  still (biased and
all) I think that owing to its design, a SDL/Tcl could make a "nice hybrid".


regards, jr.


Post a reply to this message

From: Mr
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 16 Jul 2021 09:40:00
Message: <web.60f18ad12ab8183e6adeaecb3f378f2@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

> to allow for a compiling rather than interpreting parser.

I'm so glad I asked the question ! Now not only am I fully convinced by all of
your points ! But I
actually am pretty enthusiastic ! Thanks to the last line,  about your proposal:
compiled POV scenes, wow ! that sure is a great benefit. And just to make sure I
didn't get you wrong, this means some speed increase too, doesn't it?


Post a reply to this message

From: clipka
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 16 Jul 2021 21:30:13
Message: <60f232a5$1@news.povray.org>
Am 16.07.2021 um 15:35 schrieb Mr:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> to allow for a compiling rather than interpreting parser.
> 
> I'm so glad I asked the question ! Now not only am I fully convinced by all of
> your points ! But I
> actually am pretty enthusiastic ! Thanks to the last line,  about your proposal:
> compiled POV scenes, wow ! that sure is a great benefit. And just to make sure I
> didn't get you wrong, this means some speed increase too, doesn't it?

When re-running one and the same scene a lot, say, in an animation? Yes, 
most certainly.

When looping a lot in a scene, even if you render it only once? Probably.

When using a lot of include files that you tend to use over and over 
again? Or rendering a scene again that is structured into many 
individual files, and you've changed only a single one of them? We could 
probably get some performance win for that scenario, too.


When rendering a monolithic still scene, with very few programmatic 
elements, just that one single time? No, most likely not.


So we should have a way for the user to tell the parser which files to 
compile, and which just to interpret.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.