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) and on top of that a very user 
friendly one that directly communicates to the backbone.
That would separate the POV design into two more or less disjunct 
concerns. One with a focus on low level features and one with a focus on 
a user friendly interface. It is my experience that the set of people 
that are able to solve difficult mathematical problems and are able to 
implement those (provable) bugfree and understand the subtleties of 
language design is almost empty.
>   For example, I envision that with the new language you could, for example,
> create a function which opens and parses a JPEG2000 file and returns an
> image map from it. Or that you could create render-time code with it (like
> shaders and such) as well as post-processing code (which could very well
> benefit from things like loops and control structures).
> 
>   The current user-defined functions are a step towards this goal (after
> all, they can be evaluated at render-time, and you can even create loops
> with them).
>

Post a reply to this message

andrel wrote:
> A small misunderstanding, I guess. What I proposed was to have a well 
> defined low level language (think RISC) and on top of that a very user 
> friendly one that directly communicates to the backbone.

Perhaps something like a well-defined byte-code interpreter is what you
mean? With calls that allow access to all of the ABI?

I'd already raised the issue that I felt that a byte-coded (or JIT'd) back-
end to any SDL was necessary for speed. If this was exposed and formally
documented then, firstly, more or less any language could be used with it
(assuming someone wants to write the translator), and secondly, portability
is at least vaguely possible by providing a reverse-compiler that outputs
some form of 'standard' SDL (whatever we end up calling 'standard' is up to
question of course).

This wouldn't be ideal for portability as you'd lose comments and the code
may be unreadable (especially if the front-end optimized it), but it's
possible it's better than nothing.

Note I am not necessarily advocating doing this: I am merely pointing out
that it is possible.

-- Chris

Post a reply to this message

gregjohn wrote:
> But I'm surprised that you appeared to be more worried about OSI than GPL3.

Where do you get that from?

> way, but wondering why you'd strive for OSI if GPL3 were in the bag. As far
> as "acceptance," wouldn't GPL3 suffice?

IIRC this is exactly what I said.

-- Chris

Post a reply to this message

Chris Cason wrote:
> Warp wrote:
> 
>>  Does this mean that 4.0 will *not* have any kind of revised SDL language?
> 
> 
> I have to be realistic here and take the approach that attempting to write a
> new SDL prior to releasing the tree for folks to work on would not be
> practical. On the other hand, the existing parser has to be replaced since it
> is fairly cumbersome and hard to maintain.

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)?

Regards,
John

Post a reply to this message

gregjohn wrote:
> But I'm surprised that you appeared to be more worried about OSI than GPL3.
> Right now, some linux distros turn their nose at the current license, and I
> thought you were already OSI-approved. Now I'd respect your choice either
> way, but wondering why you'd strive for OSI if GPL3 were in the bag. As far
> as "acceptance," wouldn't GPL3 suffice?
> thanks.

OSI is a non-profit institution that owns the phrase "Open Source". If 
they "like" your license, then you can call your program Open Source. 
The current POV license does not meet the OSI's criteria to be called 
Open Source.

GPLv3 has not yet received the OSI's approval as an Open Source license, 
but it's pretty much a given that it will. The first two versions of the 
GPL, along with the BSD license (and possibly the MIT license), were 
what pretty much defined Open Source in the first place.

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you start wishing you were 
actually in that futuristic mandelbrotian landscape you just rendered.
     -- fish-head

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> andrel wrote:
> > My suggestion for a 'new' language would be to have an as simple
> > as possible language (without loops and control structures) that
> > is easy to parse for a machine but not necessarily for a human.
> > Plus an easy way to integrate that with a front end, one of those
> > should be a pov 3.6 style language. Or perhaps as the only front
> > end, because if everybody can make his own language we may not be
> > able to share our sources.
>
> This would COMPLETELY DESTROY the way this community works. The language
> *must* be human-friendly.

I second that.  So far, I've not seen any other renderer out there with such
friendly and easy-going DSL like povray's SDL.  I hate the XML or structured
ones with no loops or conditionals.

I like Warp's proposal for Lua as the embedded language.  The language has
many strong points going for it, including being free software (MIT
license), easy integration to C/C++ code, simple, friendly syntax, powerful
and flexible constructs, and offers a very lightweight and fast interpreter.
 It even features the infamous tail call optimization from functional
languages!  Seems to have learned a lot from past Scheme, Tcl and Forth
experiments...

and last but not least, it was developed here in Brazil... :)

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> By the way, I have been reading the stuff Pixar has at
> http://graphics.pixar.com

wow!  wonderful collection of papers!  thanks for the link!

Post a reply to this message

My 2 cents...

I think that, prior to discussions about which approach should be
taken, we should create a dozen (or so) of typical simple scenes
which would include most typical SDL features (one with a loop, one
with a macro, one with textures, one with 'trace', etc...).

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...

Fabien.

Post a reply to this message

> This would COMPLETELY DESTROY the way this community works. The language 
> *must* be human-friendly.

I second that.  In these days of point-and-click systems, people are already
frightened enough at the idea of *typing* something to get an image.  If
the language becomes human-unfriendly, the future of POV-Ray is, at best,
to become some other Blender-compliant rendering engine...

Fabien.

Post a reply to this message

Fa3ien wrote:
> My 2 cents...
> 
> I think that, prior to discussions about which approach should be
> taken, we should create a dozen (or so) of typical simple scenes
> which would include most typical SDL features (one with a loop, one
> with a macro, one with textures, one with 'trace', etc...).
> 
> 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...

Very good idea!!!

	Thorsten

Post a reply to this message