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

Warp <war### [at] tagpovrayorg> wrote:
> 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:
....

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

Exactly.

Post a reply to this message

clipka wrote:
> 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.

Woops! My mistake.

-Mike

Post a reply to this message