Re: [glob2-devel] Language demands

[Bo Lorentsen]

Martin Voelkle wrote:

> I meant you can just forget about detecting infinite loops with this kind of 
> instructions and just use cooperative multitasking.
>  
Ok, I think I understand.

> It's a bad idea to use the call stack for TEA functions, since you won't be 
> able to save/restore it. SGSL doesn't have that problem, because it doesn't 
> have stacks. The only thing that must be saved are the instruction pointer 
> and a few global variables.
>  
Yes, SGSL have no control statements and internal script functions, and 
that make a big difference. I have been thinking about the "call stack" 
problem in TEA, and I guess I could make it use another method there too 
(I maintain the call stack), and yes this makes persisting the script 
state more easy to do.

The only problem that remain (for both TEA and SGSL) is when the script 
calls some external functions, as we have no control over these as for 
dead loop and other faults !

> If you want ease of debugging, you might better go for a stack manipulated by 
> interpreter code.
>  
Yea yea, you convinced me :-)

> There is no "language comment" in the LUA license. It speaks about the source 
> code of the implementation that can't be modified without modifying the name 
> of the program. LUA abandoned that license for this reason and switched to 
> the MIT license.
>  
... they just defines what may be viewed as an extension to LUA and what 
is a change in the language semantic, and I like that separation.

But if it is true that it is possible to link a LGPL staticly to a 
commercial program as long as the dynamic version is available to )or a 
ref to it), then I am happy for the LGPL license.

> You are right, your company wouldn't be able to release a work containing 
> statically-linked portions of LUA unless the user (someone who legally gets 
> the work) has the possibility of getting a dinamically-linked binary as well.
>  
Ok that is nice, this is what I want. I want to use TEA both at my work 
for commercial software and in other OS programs like glob2. But I like 
all future improvements and extensions (semantic or language core), to 
remain LGPL !

> You can still do a private dual-licensing: release the code under LGPL to the 
> public and the copyright holder (be it you or your company) can also use the 
> code in any way it wants, including allowing someone else to get it under an 
> other permissive license. If you do this, don't forget to ask either 
> copyright transfer or a permissive license for any non-trivial change you get 
> from someone using the LGPL licensed version if you want to be able to use it 
> at your company.
>  
I hate the idea of dual license, but I know what you mean :-)

> I had misunderstood what you wanted to keep free. I thought you wanted the 
> specification of the language to be fixed and your implementation to be free. 
>  
If someone thinks they can improve TEA by changing the language, they 
are welcome to use my code as base, as long as it has another name and 
remain LGPL. But I prefere to see the changes go into TEA to make it an 
even better language.

> But it seems like you want to let people modify the language as well.
>  
Yes, but I like to stay in control of this instance :-)

Is this a bad idea ?

/BL