SharkD wrote:
>  > Similarly, I think a clear distinction between floats and vectors 
> would be good.
> 
> I *strongly* disagree with this point. I think POV's loosely typed 
> nature is an asset, not a curse.
> 
> -Mike

However, a vector is just another type of array that uses a different 
syntax ("<" and ">" instead of "{" and "}"), so there's no real need to 
keep both, technically.

And, I think the current method of declaring arrays/objects is bulky. In 
JavaScript you can use the "literal" form to declare normal arrays like 
this:
	var foo = [bar1, bar2, bar3];

and hash arrays like this:
	var foo = {bar1 : "lala", bar2 : "bebe", bar3 : "dada"};



In Lua it's even simpler. You declare normal arrays like this:
	local foo = {bar1, bar2, bar3}

and hash arrays like this:
	local foo = {bar1 = "lala", bar2 = "bebe", bar3 = "dada"}

Mixed normal and hash arrays require a bit of extra work in Lua, though. 
But, I'll not get into that here.

-Mike

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> Anything C-like (such as JavaScript) would also be OK.

I'd agree: JavaScript might be the right balance between popularity,
accessibility, and capability.

You might be able to draw upon the existing experience and projects that already
use JavaScript. For example (and these are wild examples), JIT compilers,
already-solved problems with parsing, scope, and OO (or variants thereof).

We'd then need to decide the object model.

Would we have POV-Ray JavaScript just as a SDL, or would it also containin the
rendering instructions (like PostScript says 'showpage' to print, or OpenGL's
control over rendering)? If so, then we'd enjoy lots of extra functionality,
but we'd need to lock it down against potentially malicious third-party
scripts.

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> I agree with all your points so far. I'd just like to add that I like
> the Lua scripting language because it has a small footprint and comes
> without a lot of baggage. However, some might *prefer* all the baggage
> that comes with a language such as Python.

I've never had a look at Lua - until right now. I guess I'd like it, too.

As a matter of fact, I guess it would serve as the ideal basis for a next
generation SDL:

- It comes with a free parser designed to be integrated into other software.

- It runs on a virtual machine. (someone say "functions" and "rendering-time
execution"!)

- It allows to parse strings into code, and execute it (someone say "macro"!);
or (didn't check but simply expect it) save the code to file for later
execution, like those height field macros do.

- I think the syntax is not ideal, and a few features are missing (like native
vector support); however, with Lua being free open source, nothing hinders us
from modifying the language to suit the needs of POV-Ray.

- It includes a host of features I would want to see in a POV 4 SDL anyway, like
multithreading support (would need to be checked though whether it could
actually benefit from SMP, or whether that would require additional work);
functions returning a list of values; user data types being simulated by
associative arrays, with a special shorthand form to access them.


As a matter of fact, if Lua was a good deal closer to C, I might already be
jumping up shouting "that's our language!"

So maybe the way to go is take Lua as a basis (it seems to have a very well
designed framework), and just modify/extend the language syntax to better suit
POV's needs.

We definitely want vector literals, that's for sure.

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> However, a vector is just another type of array that uses a different
> syntax ("<" and ">" instead of "{" and "}"), so there's no real need to
> keep both, technically.

Oh, there is: We can do math with vectors. And we're using them so frequently
that we may want them to be optimized.

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> > - The scripting language should also be designed so that it's easy to
> >   flexibly read, parse and write data files (as well as handle the data
> >   itself). This would allow writing things like 3DS or OBJ file format
> >   importers as libraries. (This is an example of something which should
> >   definitely be a library rather than a core feature.)
>
> I agree with this as well. I wrote a parser for Lua once, so I know how
> difficult it can be. Are there any examples of existing languages we can
> compare to that were designed with this aspect in mind?

I think there's no need to have dedicated support for parsing other file formats
in the SDL language syntax itself: A set of library functions should do, I
guess. Which would also mean that there wouldn't be need to implement it right
from the start.

Post a reply to this message

clipka wrote:
> As a matter of fact, if Lua was a good deal closer to C, I might already be
> jumping up shouting "that's our language!"

Well, there's good news:

"Lua is implemented as a library, written in C. Being an extension 
language, Lua has no notion of a ``main'' program: it only works 
embedded in a host client, called the embedding program. This host 
program can invoke functions to execute a piece of code in Lua, can 
write and read Lua variables, and can register C functions to be called 
by Lua code. Through the use of C functions, Lua can be augmented to 
cope with a wide range of different domains, thus creating customized 
programming languages sharing a syntactical framework."

The compiled bytecode is also indistinguishable from C.

-Mike

Post a reply to this message

clipka wrote:
> I think there's no need to have dedicated support for parsing other file formats
> in the SDL language syntax itself: A set of library functions should do, I
> guess. Which would also mean that there wouldn't be need to implement it right
> from the start.

No, you got it backwards. The aim is to make POV SDL easy to parse by 
other programs. I've already written a Lua parser (specifically, a 
pretty-printer for program source code) that anyone is welcome to adapt 
if things end up going that way.

-Mike

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> Warp wrote:
> > - The scripting language should also be designed so that it's easy to
> >   flexibly read, parse and write data files (as well as handle the data
> >   itself). This would allow writing things like 3DS or OBJ file format
> >   importers as libraries. (This is an example of something which should
> >   definitely be a library rather than a core feature.)


> I agree with this as well. I wrote a parser for Lua once, so I know how 
> difficult it can be. Are there any examples of existing languages we can 
> compare to that were designed with this aspect in mind?

  I think you misunderstood what I wrote.

  I said that the SDL itself should be as flexible and expressive as possible
so that it will be possible (and preferably easy) to write file format parser
in SDL.

-- 
                                                          - Warp

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> clipka wrote:
> > As a matter of fact, if Lua was a good deal closer to C, I might already be
> > jumping up shouting "that's our language!"

> Well, there's good news:

> "Lua is implemented as a library, written in C. Being an extension 
> language, Lua has no notion of a ``main'' program: it only works 
> embedded in a host client, called the embedding program. This host 
> program can invoke functions to execute a piece of code in Lua, can 
> write and read Lua variables, and can register C functions to be called 
> by Lua code. Through the use of C functions, Lua can be augmented to 
> cope with a wide range of different domains, thus creating customized 
> programming languages sharing a syntactical framework."

> The compiled bytecode is also indistinguishable from C.

  I don't think you understood him. I believe he meant "if Lua was a good
deal closer to C *in syntax*".

-- 
                                                          - Warp

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> clipka wrote:
> > I think there's no need to have dedicated support for parsing other file formats
> > in the SDL language syntax itself: A set of library functions should do, I
> > guess. Which would also mean that there wouldn't be need to implement it right
> > from the start.
>
> No, you got it backwards. The aim is to make POV SDL easy to parse by
> other programs. I've already written a Lua parser (specifically, a
> pretty-printer for program source code) that anyone is welcome to adapt
> if things end up going that way.

?? Your statement doesn't parse to me in this context.

The previous post I was referring to proposed that *POV* should be able to parse
*other* formats.

This was plain and clear: .obj and .df3 were explicitly mentioned - which are
file formats, not programs.

Post a reply to this message