Re: lua chip AND SOME IDEA - about making a blueprint of ROADMAP of Lua core

classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: lua chip AND SOME IDEA - about making a blueprint of ROADMAP of Lua core

Ashish Ranjan
oh, come on. This discussion is not about persistence only. This is
about creating a ROADMAP of lua. A TODO of lua. Just what PHP 5 has
done in an overwhelming way to PHP. Upcoming Perl 6 and ParrotVM is
doing with Perl. VB.Net has done with VB. Jdk 1.5 has done with java.
This does not says that pull all those things to lua.
 This is to say that - After a period of stabilisation, there is a
need to get a vision of future for every language. This talk is about
that, what we should set our look upon. Just give ideas first, which
are in sync with lua phillosophy.
    What about annotations? This is a meta-mechanism , which is in
sync with lua philosophy. If lua core implements annotations. Then
atleast , say for example,i give a simple parametric annotations in my
lua code to mark it as two separate threads and implementator of this
annotation mechanism will generate the necessary code/bytecode. Game
developers will say scripters only to mark their lua code with some
special annotations and it will give the scripters a sigh of relief by
implementing many special things by a very least annotation markings.
   If one didn't want to compile annotations facility in lua core,
then he may optionally switch it of in the makefile (say).
    AGAIN, I just not wanted to say about getting all sort of rubbish
to be implemented in a such a small , sweet language. I did not wanted
to say about implementing only Persistence. I did not wanted to say
about implementing only annotations. I wanted ideas from u. From
Users. From Game developers. So that as a community we can freeze only
some minimum ideas/TODOs to enrich the lua core in next milstones ,
with only those ideas which fit into lua philosophy.
bye :-)
Ashish Ranjan
bye :-)
Ashish

Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Klaus Ripke
hi

On Friday 14 January 2005 06:12, Ashish Ranjan wrote:
> Just what PHP 5 has done in an overwhelming way to PHP.
I'm quite overwhelmed, waiting for a 5.3 or something to be
ready for use on our production sites mayby early 2007.

> Upcoming Perl 6 and ParrotVM is doing with Perl.
> VB.Net has done with VB. Jdk 1.5 has done with java.
and STL did to C++ and C99 did to C and you name it:
turning stable existing systems into new upgrade nightmares
for years to come.

> need to get a vision of future for every language.
I guess there is a pretty strong vision to just leave it alone?

But no: There is perfectly no need to ask
"what could be added and why not?" -- it's just the wrong question.
To the very contrary, in order to satisfy actual needs, proposals
have to be based on actual needs instead of random brainstorming.
As Mike noted, persistence is a non-issue with regard to the core,
and so are annotations and we can focus on implementation issues
like the GC instead.

What's really missing?


cheers
Klaus


Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Petite Abeille

On Jan 14, 2005, at 11:50, Klaus Ripke wrote:

What's really missing?

Even better: what could be removed? (Half-joking :o)

Cheers,

PA.


Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Luiz Henrique de Figueiredo
> > What's really missing?
> 
> Even better: what could be removed? (Half-joking :o)

That's not a joke at all. That's what the Lua team discusses in our meetings.
We take Saint-Exupery seriously (at least that quote about perfection).
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Petite Abeille

On Jan 14, 2005, at 12:01, Luiz Henrique de Figueiredo wrote:

What's really missing?

Even better: what could be removed? (Half-joking :o)

That's not a joke at all. That's what the Lua team discusses in our meetings.
We take Saint-Exupery seriously (at least that quote about perfection).

That's exactly what I wanted to hear! I knew there was something fundamentally right about Lua's approach :)

Cheers,

PA.


Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Wim Couwenberg-5
In reply to this post by Petite Abeille
Even better: what could be removed? (Half-joking :o)

My tentative list:

-  function environments (see (1) below)
-  coroutines (is there *anyone* at all who agrees??  :-)  )
-  mutable upvalues (see (2) below)
-  proxy constructions

And some pluses:

+  __pairs metamethod
+  __settable, __gettable metamethods


(1) I hazard a guess that gunction environments are mainly used to "package" functions in some way (sandboxing and what not). This could also be realised with upvalues (global name lookup in an upvalue instead of fenv)

(2) I actually like the current possibility to "forward declare" locals (gives us cleaner recursive functions a/o). What would be sufficient for me is that upvalues can not be assigned to in a closure and that the closure receives a (private) copy of the value when the upvalue goes out of scope.


Small lists no?  :-D


--
Wim

Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Adam D. Moss
Wim Couwenberg wrote:
-  function environments (see (1) below)
(1) I hazard a guess that gunction environments are mainly used to "package" functions in some way (sandboxing and what not). This could also be realised with upvalues (global name lookup in an upvalue instead of fenv)

Wow, I think I'd be quite lost without fenv().  Global lookups from
an upvalue is an interesting idea but I'm not sure it'd all work
out simpler (either semantically or from an implementation pov) than
the current scheme in reality.

> -  coroutines (is there *anyone* at all who agrees??  :-)  )

They're fantastic (albeit not essential) as iterators.  Apart from
that I don't use them myself, as attractive as they are from a
'computer science' angle.

> -  mutable upvalues (see (2) below)

I rely on mutable closures for a few things.  I'd be sad if they
went away, but would survive.  Wouldn't it kill module-top-level
locals though, since these are treated as mutable upvalues
in functions that reference them?  Again, though, I'm really
not sure that making a closure a read-only copy of the var's
last value at the point it leaves scope would be *at all* simpler
to understand or implement than the current scheme.

> -  proxy constructions

What is meant by this?  __newindex etc?

> And some pluses:
>
> +  __pairs metamethod

Although this would be academically pleasing and the lack of
such a metamethod seems like an obvious hole in proxy tables
etc, in real life I seem to be living quite comfortably without.

> +  __settable, __gettable metamethods

Doing what exactly?

Regards,
--Adam
--
Adam D. Moss   . ,,^^   [hidden email]   http://www.foxbox.org/   co:3

Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Spencer Schumann-2
> Wow, I think I'd be quite lost without fenv().  Global lookups from
> an upvalue is an interesting idea but I'm not sure it'd all work
> out simpler (either semantically or from an implementation pov) than
> the current scheme in reality.

I also rely upon fenv(), but I think they could use an addition:
currently, each function is associated with one fenv.  In some cases,
you need to have identical functions that are each associated with a
different fenv.  In pure Lua, this can be solved by making sure each
function is a distinct closure, or by using string.dump() and
loadsttring() to make duplicates.  The method I'm using right now is a
"clone" function added to the Lua core that makes a copy of a function
(by creating a new closure using the proto of an existing function),
and these copies can all have separate fenvs.

>  > -  coroutines (is there *anyone* at all who agrees??  :-)  )
> 
> They're fantastic (albeit not essential) as iterators.  Apart from
> that I don't use them myself, as attractive as they are from a
> 'computer science' angle.
> 

Coroutines were part of the reason Lua was chosen for my current
project.  I need to be able to run multiple concurrent scripts, and
coroutines provide a very lightweight way to do that.

> I rely on mutable closures for a few things.  I'd be sad if they
> went away, but would survive.  Wouldn't it kill module-top-level
> locals though, since these are treated as mutable upvalues
> in functions that reference them?  Again, though, I'm really
> not sure that making a closure a read-only copy of the var's
> last value at the point it leaves scope would be *at all* simpler
> to understand or implement than the current scheme.

I agree.

>  > And some pluses:
>  >
>  > +  __pairs metamethod
> 
> Although this would be academically pleasing and the lack of
> such a metamethod seems like an obvious hole in proxy tables
> etc, in real life I seem to be living quite comfortably without.

I think a __pairs metamethod would be useful, and I'm considering
adding one myself.  The big trouble is that there are multiple ways of
iterating through some objects, such as pairs() and ipairs() for one. 
Perhaps it is sufficient to keep the current method of allowing
arbitrary iteration functions.

>  > +  __settable, __gettable metamethods

There is a "hole" in that there is a __newindex metamethod, but not a
__setindex metamethod...perhaps that is what this suggestion is about?

Reply | Threaded
Open this post in threaded view
|

RES: idea of vision of blueprint of ROADMAP of Lua core

André de Leiradella
In reply to this post by Wim Couwenberg-5
> My tentative list:
> 
> -  function environments (see (1) below)
> -  coroutines (is there *anyone* at all who agrees??  :-)  )
> -  mutable upvalues (see (2) below)
> -  proxy constructions
> 
> And some pluses:
> 
> +  __pairs metamethod
> +  __settable, __gettable metamethods
> 

What about:

+ Classes and objects

It's #1 to me. This seems to be a common wish, every now and then we see
threads on this topic and many people have developed workarounds so that
it looks like Lua is a real OOP language, and (or as) the game
programing community uses C++ a lot. It's not necessary to add
predefined classes to the core (like Java's VM that rely on String and
StringBuffer at least), just the ability to define classes, instantiate
objects and calling [inherited] methods.

Regards,

Andre de Leiradella


Reply | Threaded
Open this post in threaded view
|

Re: RES: idea of vision of blueprint of ROADMAP of Lua core

Adam D. Moss
André de Leiradella wrote:
+ Classes and objects

It's #1 to me. This seems to be a common wish, every now and then we see
threads on this topic and many people have developed workarounds so that
it looks like Lua is a real OOP language, and (or as) the game
programing community uses C++ a lot. It's not necessary to add
predefined classes to the core (like Java's VM that rely on String and
StringBuffer at least), just the ability to define classes, instantiate
objects and calling [inherited] methods.

This is very possible... there are various ways to do it, but
that's what metaprogramming is about.  Regardless of how you
get there you end up with something about as elegant as you
could ask for (obj:method(), obj.attribute), but you have to
'do it yourself' (though a simple implementation is already
very simple).  So I can't see a 'blessed' way of doing
this making it to the core, but I assume it's already well-covered
by projects such as LuaCheia (and definitely amply covered by
the Wiki code).

--Adam
--
Adam D. Moss   . ,,^^   [hidden email]   http://www.foxbox.org/   co:3

Reply | Threaded
Open this post in threaded view
|

Re[2]: idea of vision of blueprint of ROADMAP of Lua core

Gunnar Zötl
In reply to this post by Adam D. Moss
Adam wrote:
ADM> Wim Couwenberg wrote:
>> -  function environments (see (1) below)

I consider those to be a meta-mechanism, allowing to do some
interesting stuff by working around the lexical scoping. Lexical 
scoping is a good_thing[tm], but as lua relies on meta-mechanisms, a
controlled way around that does help in implementing things that would
be tough to do without. The use for packages is an example.

>> -  coroutines (is there *anyone* at all who agrees??  :-)  )

ADM> They're fantastic (albeit not essential) as iterators.  Apart from
ADM> that I don't use them myself, as attractive as they are from a
ADM> 'computer science' angle.

I do use them for all sorts of things. Maybe that's a consequence of
having worked on a system with only cooperative multitasking for quite some
time, subsequently getting used to that sort of thing. They are
excessively handy for implementing lightweight multitasking within an
application.

>> -  mutable upvalues (see (2) below)

ADM> I rely on mutable closures for a few things.  I'd be sad if they

me, too.

>> -  proxy constructions

Did I miss something? I thought this proxy stuff was not part of the
language, but rather a common lua pattern.

 >> And some pluses:
 >>
 >> +  __pairs metamethod

ADM> Although this would be academically pleasing and the lack of
ADM> such a metamethod seems like an obvious hole in proxy tables
ADM> etc, in real life I seem to be living quite comfortably without.

I'd like that. A need for iterating through all values accessible
through a table that inherits from another table by means of
metatables made me implement a __pairs metamethod myself. However, the
necessary modifications to the pairs() function can be done from
within lua, so there is not really a need for this. Still, I'm all in
favor of this. 

 >> +  __settable, __gettable metamethods

ADM> Doing what exactly?

As I see it, those are meant to be counterparts to __index and
__newindex, with the difference that they intercept accesses to values
already defined in the table. With those one could get rid of the
proxy constructions. I have no opinion on that, as the proxy approach
works reasonably well for me.

have a nice day,

Gunnar




Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Eric Scouten
In reply to this post by Wim Couwenberg-5
Wim Couwenberg wrote:

Even better: what could be removed? (Half-joking :o)


My tentative list:

-  coroutines (is there *anyone* at all who agrees??  :-)  )

Ummm... probably not. Let me be another voice speaking up in defense of coroutines. Our application initially made heavy use of preemptive multithreading and a single Lua universe. We found that we wound up spending a *lot* of time in mutex (un)lock calls. This penalty outweighed the purported benefits of preemptive multithreading. We have since moved to allowing only a single thread per Lua universe with heavy use of coroutines to handle much of our "background" processing. This has both improved the performance of our application significantly and dramatically reduced the amount of head-scratching we do about threading issues. :-) We continue to use other threads, but their use is now restricted to CPU-intensive tasks that are easily disconnected from the rest of the system.

-Eric


Reply | Threaded
Open this post in threaded view
|

RE: idea of vision of blueprint of ROADMAP of Lua core

Vijay Aswadhati-2

> -----Original Message-----
> From: [hidden email] [[hidden email]
> [hidden email]] On Behalf Of Eric Scouten
> Sent: Friday, January 14, 2005 9:50 AM
> To: Lua list
> Subject: Re: idea of vision of blueprint of ROADMAP of Lua core
> 
> Wim Couwenberg wrote:
> 
> >> Even better: what could be removed? (Half-joking :o)
> >
> >
> > My tentative list:
> >
> > -  coroutines (is there *anyone* at all who agrees??  :-)  )
> 
> Ummm... probably not. Let me be another voice speaking up in defense of
> coroutines.

FWIW, count my voice as well speaking up for coroutines as a first class
feature of the Lua language. And while at it, it would be super to include
the work of (Mike Pall and Eric Jacobs) on this subject into the core
language core as opposed to being a power patch.

--v.a




Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Javier Guerra Giraldez
On Friday 14 January 2005 1:13 pm, Vijay Aswadhati wrote:
> > Wim Couwenberg wrote:
> > >> Even better: what could be removed? (Half-joking :o)
> > > -  coroutines (is there *anyone* at all who agrees??  :-)  )
> >
> > Ummm... probably not. Let me be another voice speaking up in defense of
> > coroutines.
>
> FWIW, count my voice as well speaking up for coroutines as a first class
> feature of the Lua language. And while at it, it would be super to include
> the work of (Mike Pall and Eric Jacobs) on this subject into the core
> language core as opposed to being a power patch.

me too, coroutines are really one of the great Lua features, and one i don't 
think could be as well integrated if done as a library.  Besides, since 
they're _so_ lightweight, i think most projects would be more bloated without 
them (especially deeply embedded uses).

i don't get what's that Pall/Jacobs powerpatch... care to elaborate?

-- 
Javier

Attachment: pgpNKWyj5Gjnx.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: RES: idea of vision of blueprint of ROADMAP of Lua core

Javier Guerra Giraldez
In reply to this post by Adam D. Moss
On Friday 14 January 2005 9:02 am, Adam D. Moss wrote:
> André de Leiradella wrote:
> > + Classes and objects
>
> This is very possible... there are various ways to do it, but
> that's what metaprogramming is about.  Regardless of how you

i think too that it's better done as a library and not in the core.  but 
making a 'reference' implementation would make things easier for many people, 
and maybe also encourage code sharing between projects.

-- 
Javier

Attachment: pgpbFqJr83F0l.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Improved coroutines (was Re: idea of vision of blueprint of ROADMAP of Lua core)

Mike Pall-50
In reply to this post by Vijay Aswadhati-2
Hi,

Vijay Aswadhati wrote:
> FWIW, count my voice as well speaking up for coroutines as a first class
> feature of the Lua language. And while at it, it would be super to include
> the work of (Mike Pall and Eric Jacobs) on this subject into the core
> language core as opposed to being a power patch.

Well, yes and no. I do not think that my proof-of-concept implementation
of true C coroutines with machine dependent stack switching is really
feasible. As I pointed out in another message I encountered too many
difficulties porting it and there are other issues, such as the stack
allocation problem.

However I would very much like to see something similar to Eric's approach
( http://lua-users.org/wiki/ImprovedCoroutinesPatch ) in the Lua core.
I even thought about porting it to Lua 5.1 ...

But I'd like to have feedback from the Lua authors on this issue first.
It's very hard to maintain this as a separate patch, since it affects
many areas of the Lua core. Sooo ...

Is Eric's approach something you would like to incorporate into the Lua core?
If yes, is there anything that needs to be modified in your opinion?
Do you want us to port it to 5.1 or do you want to integrate it yourself?

Bye,
     Mike

Reply | Threaded
Open this post in threaded view
|

Binding code generator

Elghaouat
Hello everybody,

we are planning to use Lua in our next game, it is pretty sure that we will
be using a binding code genretaor. I tryed tolua++ to do some samples and it
seems that he does the job but i am sure that it is the best, so i am asking
which tool is more efficient or what are the adavantages and the drawbaks of
each one, that would help me  decide which one to use, we still also open to
the idea of writing our binding code genereator.

Thanks !




Reply | Threaded
Open this post in threaded view
|

Re: idea of vision of blueprint of ROADMAP of Lua core

Wim Couwenberg-2
In reply to this post by Gunnar Zötl
-  proxy constructions

Did I miss something? I thought this proxy stuff was not part of the
language, but rather a common lua pattern.

There is an (undocumented?) function "newproxy" in the baselib. But actually I meant the proxy idea in general, which is related to...

+  __settable, __gettable metamethods

As I see it, those are meant to be counterparts to __index and
__newindex, with the difference that they intercept accesses to values
already defined in the table. With those one could get rid of the
proxy constructions.

Exactly. ("settable" and "gettable" were tag methods in Lua 4, hence my notation. Maybe __getindex and __setindex would be more appropriate Lua 5 names.)

--
Wim

Reply | Threaded
Open this post in threaded view
|

Re: RES: idea of vision of blueprint of ROADMAP of Lua core

Asko Kauppi-3
In reply to this post by André de Leiradella

Yes, this (classes) could well get my vote for things to commonalize (not standardize ;) after the modules dilemma will be out of the way.

Something like a simple 'class.' table like the rest of the Lua add-ons. I'd like that. :)

Of course, there's nothing keeping us from starting that work already now.

-ak


14.1.2005 kello 16:57, André de Leiradella kirjoitti:

 My tentative list:

-  function environments (see (1) below)
-  coroutines (is there *anyone* at all who agrees??  :-)  )
-  mutable upvalues (see (2) below)
-  proxy constructions

And some pluses:

+  __pairs metamethod
+  __settable, __gettable metamethods


What about:

+ Classes and objects

It's #1 to me. This seems to be a common wish, every now and then we see threads on this topic and many people have developed workarounds so that
it looks like Lua is a real OOP language, and (or as) the game
programing community uses C++ a lot. It's not necessary to add
predefined classes to the core (like Java's VM that rely on String and
StringBuffer at least), just the ability to define classes, instantiate
objects and calling [inherited] methods.

Regards,

Andre de Leiradella



Reply | Threaded
Open this post in threaded view
|

RE: Improved coroutines (was Re: idea of vision of blueprint of ROADMAPof Lua core)

Vijay Aswadhati-2
In reply to this post by Mike Pall-50

> 
> Vijay Aswadhati wrote:
> > FWIW, count my voice as well speaking up for coroutines as a first class
> > feature of the Lua language. And while at it, it would be super to
> include
> > the work of (Mike Pall and Eric Jacobs) on this subject into the core
> > language core as opposed to being a power patch.
> 
> Well, yes and no. I do not think that my proof-of-concept implementation
> of true C coroutines with machine dependent stack switching is really
> feasible. As I pointed out in another message I encountered too many
> difficulties porting it and there are other issues, such as the stack
> allocation problem.

I am aware of that and hence I included Eric Jacobs work. However I did not
follow up on what the status of his patch.

> 
> However I would very much like to see something similar to Eric's approach
> ( http://lua-users.org/wiki/ImprovedCoroutinesPatch ) in the Lua core.
> I even thought about porting it to Lua 5.1 ...
> 
> But I'd like to have feedback from the Lua authors on this issue first.
> It's very hard to maintain this as a separate patch, since it affects
> many areas of the Lua core. Sooo ...
> 
> Is Eric's approach something you would like to incorporate into the Lua
> core?

Ideally I would like the plausible performance improvements that come with
the 'C' coroutines and the convenience of such coroutines available
seamlessly in Lua (the scripting environment)

> If yes, is there anything that needs to be modified in your opinion?
> Do you want us to port it to 5.1 or do you want to integrate it yourself?

To be honest I have not had the chance to play with both of these patches
and hence I cannot offer any comments other than to suggest that first class
features of any language should be part of the core distribution fully
integrated and tested. I use the term 'first class' in a similar vein as the
statement 'Functions in Lua are first-class values...' (PIL:
http://www.lua.org/pil/6.html)


--v.a




12345