David Buck schrieb:
> 
> I'm going to make a radical proposal for you to think over.
> 
> As POVRay's SDL has evolved over the years, it's become more and more 
> like a programming language.  I think it's worth considering pushing it 
> into a real programming language.
> 
> These days, I do most of my work in Smalltalk.  It's one of the simplest 
> yet most powerful programming languages around.
> [...]

The question of the general concept of a new SDL or extension of the 
existing one has already been discussed quite a lot (some of it in 
private) - although there has not been anything definite on the matter 
yet some important issues have crystallized that stand against your 
suggestion.

Anyone agrees that the current SDL lacks important features for coding 
more complex functionality and the current design significantly limits 
performance of SDL code interpretation.  Both together make it difficult 
to extend POV-Ray's features using the SDL.

Another problem of the current language is that the different levels of 
the language are difficult to understand for the beginner - the use of 
loops and macros in user defined functions being a good example.

But the most important thing is it needs to be straight away to do 
simple scenes using it.  Languages like Smalltalk appeal to the ones who 
know them because they are very consistent on the whole.  The price for 
this however is that even for the most simple tasks you need to 
understand most of the language's advanced concepts and this makes it 
fairly unsuited as a SDL.

In short:  Simple tasks like a reflective sphere over checkered plane 
need to be straight away to implement and to read - without knowing 
about language concepts.  Like in the current SDL version of such a 
simple scene the purpose of every token should be intuitively 
understandable.  More complex features of the language would need to be 
optional additions to this.

-- Christoph

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Warp wrote:
> > andrel <a_l### [at] hotmailcom> wrote:
> >> My suggestion for a 'new' language would be to have an as simple as 
> >> possible language (without loops and control structures)
> > 
> >   Bad idea. The new language should be more powerful, not less.
> > 
> A small misunderstanding, I guess. What I proposed was to have a well 
> defined low level language (think RISC)

  A RISC without loops and control structures? I still think it's a bad idea.

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
>  It even features the infamous tail call optimization from functional
> languages!

  I believe the word "infamous" has a negative connotation to it. Was that
really what you wanted to express?-)

-- 
                                                          - Warp

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> How hard would it be to separate the parser and the renderer as much as 
> possible, and thereby allow for both a parser based on the current SDL, 
> and another parser based on an entirely different SDL (as well as a 
> rendering engine that is not primarily a ray-tracer)?

  I'm not 100% sure that separating the parser from the renderer even
further is actually the right thing to do.

  It may sound rational because it would allow changing the parser easily.

  However, that's where the advantages end. The disadvantage is, however,
that it would limit the usability of the language *during rendering* even
more than the current SDL (which at least has user-defined functions which
can be evaluated during render-time).

  A separate "shader" language and a "post-processing" language would be
needed for enhanced functionality. That's already three separate languages
in one. Is that really what we want? Or do we want one language which can
be used for everything?

-- 
                                                          - Warp

Post a reply to this message

On Wed, 12 Sep 2007 07:27:16 -0400, Warp wrote:

>> A small misunderstanding, I guess. What I proposed was to have a well
>> defined low level language (think RISC)
> 
>   A RISC without loops and control structures?

IIRC (and I probably don't), unrolling loops (in particular) is an 
optimization; but at a low level, I don't necessarily see that as a bad 
idea myself.  But the high-level language does need these structures.

Jim

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> >  It even features the infamous tail call optimization from functional
> > languages!
>
>   I believe the word "infamous" has a negative connotation to it. Was that
> really what you wanted to express?-)
>
> --
>                                                           - Warp

that was my half-assed attempt at a joke at replacing the term "famous". :P

obviously, tail call optimization is a very Good Thing!

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> IIRC (and I probably don't), unrolling loops (in particular) is an 
> optimization;

  So how do you unroll a loop which depends eg. on the color of a pixel,
determined at rendertime?

-- 
                                                          - Warp

Post a reply to this message

in news:46e7797a$1@news.povray.org Fa3ien wrote:

> Each envisioned language and/or paradigm should be tested 'against'
> these scenes, with sample would-be code.  This would allow, IMO,
> better evaluation upon criterias such as features, powerfulness,
> expandability, readability, user-friendliness, ease of
> implementation, etc... 
> 

I like that.

somewhat related, here is a link to something somebody did in Python to 
creat POV-Ray scenes. http://arrowtheory.com/software/python/pypov/
I did simmilar things myself and immediatly missed a built in vector <>.

ingo

Post a reply to this message

in news:Xns99A9CF023F162seed7@news.povray.org ingo wrote:

> somewhat related, here is a link to something somebody did in Python to 
> creat POV-Ray scenes. http://arrowtheory.com/software/python/pypov/
> 

I should not this was written for Python users, so it uses things not 
ovious for POV-Ray users like list comprehention. There is non need to use 
it that way.

ingo

Post a reply to this message

Jim Henderson wrote:
> On Wed, 12 Sep 2007 07:27:16 -0400, Warp wrote:
> 
>>> A small misunderstanding, I guess. What I proposed was to have a well
>>> defined low level language (think RISC)
>>   A RISC without loops and control structures?
> 
> IIRC (and I probably don't), unrolling loops (in particular) is an 
> optimization; but at a low level, I don't necessarily see that as a bad 
> idea myself.  But the high-level language does need these structures.
> 
That was indeed my suggestion. Add sophisticated control structures to a 
high level language and while executing that, fill a pipeline with 
objects and other necessary descriptions of the scene.

For what I mostly do that would be enough and I could even imagine that 
I would write my matlab programs in such a way that I could directly 
fill the pipeline. But I have never used complex textures, so I am not 
in a position to judge if you really need a full blown programing 
language to define those. Nor if that would be incompatible with such a 
pipeline.

Post a reply to this message