Re: [glob2-devel] Language demands

[Martin Voelkle]

Hello

> I have been working on my new version of TEA, and have been trying to 
> take all things in account that have been discussed in the last 
> "scripting language" thread.

It's great to hear this!

> I have a few issues left that I like to ask about :
> 
> 1. as I see it now, the current language have the possibility to run a 
> certain number of instructions, and then return control to the game to 
> be able to control CPU usage (time share). There are tree ways to do 
> this in TEA as I see it :
>   
>    a. Limit the number of VM instructions performed per "tick" (store 
> the pc and cont. at next pos on return)
>    b. Make some kind of cooperative multitasking (locally allocated 
> stack, and wait instructions)
>    c. use the existing thread system (semaphore locked), and the wait 
> instruction.

SGSL now does a mixture of a and b. Normally, there is cooperative
multitasking, but if the thread runs too long without waiting, it is
'preempted' after a number of VM instructions.

> a. sounds simple, but I dislike to put too much complexity into the 
> language code (there is plenty already :-))

It is perfectly possible to avoid this if you get rid of preemption.

> b. I am not sure this is possible at all in a modern OS, but I have used 
> this and longjump in the past for tasks like this. but I dislike it and 
> it will be very hard to debug.

If you handle your stack yourself, you can do the switch without any
longjump.

> c. This sound to me, like a nice way to do it. We allocate to threads, 
> and when we like to make a script run, we unlock one semaphore and wait 
> on another, and then the script engine will run until the next "wait" 
> instruction, that will give back control, using the same semaphores. 
> There will not be any thread related problems, as only one thread runs 
> at a time, and debugging will be likewise easier.

This sounds exactly like b, but you're using thread support just to
emulate longjump. I'm not sure it will be easier do debug than b.

> How does that sound ? Am I totally off track ?

No, you're right. Remember that whatever the model you chose, you need
to be able to save the execution state in a file and resume it.

> 2. License, I like LGPL but I also like to add the same note as the 
> folks at LUA did, that say : "If the syntax and semantics of the 
> language (that is, the parser and the virtual machine) remain the same, 
> then the language is still Lua. If you simply add new libraries, or even 
> replace the standard libraries by your own, the language is still the 
> same, and you don't need to give it a completely different name."
> Does anyone know if this is possible to combine ?

LUA's license said "Altered source versions must be plainly marked as
such, and must not be misrepresented as being the original package."
which is not what you intend to use. See
http://lua-users.org/wiki/LuaLicense for discussion about this. The main
problem with such statements is that they are incompatible with the GPL.

What you can do is separate the language specification form your
reference implementation. Protect the specification in some way (but
keep it free) and put the implementation under a GPL-compatible license.

> But beside this, TEA are heading in the right direction, after a big 
> cleanup (and addintion of param. function) and addition of a real stack 
> vm :-)

It's good to see someone doing the right things.

Martin