Unique directions for Lua?

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Unique directions for Lua?

David Jeske-3
Hey all,

In reading the recent list discussions about building a module system
for Lua, and having a few private discussions about the same topic, I
have an interesting question to those who have been happy embedding
Lua into an existing project:

What unique directions can Lua take which will make it better for
embedding?

I've already voiced my opinion that amassing a large set of standard
modules for Lua (ala Perl, Python, Ruby, etc) is a wasted effort. One
motivation for that thought is that once Lua had exceptions, a
class-esq system, and a bunch of modules, it would largly be the same
as all those other systems, and it's just silly wheel-reinventing IMO,
to have so many similar systems.

Today, the way I see it, Lua has three major unique strengths:

1) It's Small and 100% ANSI C  -- I don't think any other comperable 
     scripting language can say that.

2) It's VM is highly tuned and fast -- In fact, I'd like to see a 
     whitepaper written specifically about the Lua VM techniques so 
     it would be easier for languages such as Perl and Python to 
     adopt these techniques where it would help their performance.

3) It's terribly easy to embed -- This is partially due to #1 above.
     In looking into it, the Python embedding API is really not very
     different, but Python as a whole is more complicated, and that
     contributes to some additional confusion. Although there are at
     least as many examples of commercial software with Python embedded,
     possibly more (IIS, Caligari Truespace, XCircuit, ABAQUS/CAE, and
     others)

My question is meant to fuel some interesting discussions about what
directions Lua can take which will make it more useful for it's
current target market, programmers choosing to add an embedded
scripting language.

Some examples of items discussed on the list which might be useful
additions include:

 1) Memory management optimizations for small memory for embedded use
 2) More real-time Garbage collection optimizations for lowering 
    collection pause time (as it seems Lua has been picked up among
    Game programmers)
 3) code-safety features such as "require variable declarations" or
    static typing (ala unrealscript)
 4) compiling Lua code into C 

Do any of you have other ideas about unique features Lua could have
(or perhaps already has that I omitted above)?

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

D Burgess
AGREE, AGREE, AGREE!

----- Original Message ----- 
From: "David Jeske" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Monday, February 04, 2002 4:44 PM
Subject: Unique directions for Lua?


Hey all,

In reading the recent list discussions about building a module system
for Lua, and having a few private discussions about the same topic, I
have an interesting question to those who have been happy embedding
Lua into an existing project:

What unique directions can Lua take which will make it better for
embedding?

I've already voiced my opinion that amassing a large set of standard
modules for Lua (ala Perl, Python, Ruby, etc) is a wasted effort. One
motivation for that thought is that once Lua had exceptions, a
class-esq system, and a bunch of modules, it would largly be the same
as all those other systems, and it's just silly wheel-reinventing IMO,
to have so many similar systems.

Today, the way I see it, Lua has three major unique strengths:

1) It's Small and 100% ANSI C  -- I don't think any other comperable 
     scripting language can say that.

2) It's VM is highly tuned and fast -- In fact, I'd like to see a 
     whitepaper written specifically about the Lua VM techniques so 
     it would be easier for languages such as Perl and Python to 
     adopt these techniques where it would help their performance.

3) It's terribly easy to embed -- This is partially due to #1 above.
     In looking into it, the Python embedding API is really not very
     different, but Python as a whole is more complicated, and that
     contributes to some additional confusion. Although there are at
     least as many examples of commercial software with Python embedded,
     possibly more (IIS, Caligari Truespace, XCircuit, ABAQUS/CAE, and
     others)

My question is meant to fuel some interesting discussions about what
directions Lua can take which will make it more useful for it's
current target market, programmers choosing to add an embedded
scripting language.

Some examples of items discussed on the list which might be useful
additions include:

 1) Memory management optimizations for small memory for embedded use
 2) More real-time Garbage collection optimizations for lowering 
    collection pause time (as it seems Lua has been picked up among
    Game programmers)
 3) code-safety features such as "require variable declarations" or
    static typing (ala unrealscript)
 4) compiling Lua code into C 

Do any of you have other ideas about unique features Lua could have
(or perhaps already has that I omitted above)?

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re-calling lua_loadbuffer

Chris Percival
Group,

I have changed my lua v4.0 so I can use lua_loadbuffer (was parse_buffer).
What happens if I call this function, change the script in the passed
buffer, and then call it again?  Is that allowed?  Would then calling
lua_dobuffer do the second loaded scipt, or not?  If I wanted to
're-compile' the script by calling lua_loadbuffer again, what would I need
to do?

Thanks

Chris Percival
Software Engineer
Interaxis Computing Ltd.
DDI:  +44 (0)1249 700072
http://www.interaxis.co.uk/


Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

Thatcher Ulrich
In reply to this post by David Jeske-3
On Feb 03, 2002 at 09:44 -0800, David Jeske wrote:
> 
> What unique directions can Lua take which will make it better for
> embedding?

Good question.

> Some examples of items discussed on the list which might be useful
> additions include:
> 
>  1) Memory management optimizations for small memory for embedded use
>  2) More real-time Garbage collection optimizations for lowering 
>     collection pause time (as it seems Lua has been picked up among
>     Game programmers)
>  3) code-safety features such as "require variable declarations" or
>     static typing (ala unrealscript)
>  4) compiling Lua code into C 
> 
> Do any of you have other ideas about unique features Lua could have
> (or perhaps already has that I omitted above)?

2 and 3 (a 'global' declaration, not static typing) are close to my
heart.

To that list I would add: an easy-to-use source-level debugger
(several partial solutions exist), and (don't hit me!) a module
system.

Honestly, I think a lightweight module system directly benefits my
embedding efforts, given that my embedding interests center around
game programming, which inherently involves dealing with disparate
native APIs (graphics, sound, input, networking, etc).

I could say lots more about why a module system is a good thing, but
I'll limit myself to one more point: it makes the language more
powerful, without making the core bigger.

-- 
Thatcher Ulrich <[hidden email]>
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

J. Perkins-2
Thatcher Ulrich wrote:

On Feb 03, 2002 at 09:44 -0800, David Jeske wrote:
Some examples of items discussed on the list which might be useful
additions include:

1) Memory management optimizations for small memory for embedded use
2) More real-time Garbage collection optimizations for lowering collection pause time (as it seems Lua has been picked up among
   Game programmers)
3) code-safety features such as "require variable declarations" or
   static typing (ala unrealscript)
4) compiling Lua code into C


[...]


2 and 3 (a 'global' declaration, not static typing) are close to my
heart.


Same here, especially #2.


To that list I would add: an easy-to-use source-level debugger
(several partial solutions exist), and (don't hit me!) a module
system.

Honestly, I think a lightweight module system directly benefits my
embedding efforts, given that my embedding interests center around
game programming, which inherently involves dealing with disparate
native APIs (graphics, sound, input, networking, etc).

I could say lots more about why a module system is a good thing, but
I'll limit myself to one more point: it makes the language more
powerful, without making the core bigger.


I agree with this, but I also agree with whoever said it should probably be a separate project. I have a module/component system in my "research" engine that I rather like and which works very well. I am in the process of upgrading it to work3, and at the same time splitting it out into a standalone library. When/if I get it finished I'll mention it here, but in the meantime, if you are interested, you can see the whole project at http://www.379.com/f4/

Jason


Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

Ignacio Castaño
In reply to this post by Thatcher Ulrich
Thatcher Ulrich wrote:
> Honestly, I think a lightweight module system directly benefits my
> embedding efforts, given that my embedding interests center around
> game programming, which inherently involves dealing with disparate
> native APIs (graphics, sound, input, networking, etc).
>
> I could say lots more about why a module system is a good thing, but
> I'll limit myself to one more point: it makes the language more
> powerful, without making the core bigger.

agreed.

It's clear that the module system cannot be implemented in ansi c, however
lua could define an interface for it, so that, if a module system is
available on some platform it's implemented always the same way, that would
facilitate using modules without rebuilding.

So it would be like the lua threads. If you have threads, use them, if not,
do not.

I've always used lua in embebed platforms, never as a standalone language
and for example I've never used the iolibrary, since this functionality is
provided by the host in a different and secure (or restricted) way. And I
still find a module system usefull, since this way I can extend my program
in unexpected ways writting new modules and simply loading them from lua.


Ignacio Castaño
[hidden email]


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Tag methods

Chris Percival
In reply to this post by Chris Percival
Ok I give up, can someone give me a clear example of how to set a tag method
for 'setglobal' for example?

For example something like this:

	lua_pushnumber(L, 1);
	lua_setglobal(L, "Batch");
	int tag = lua_newtag(L);
	lua_pushcfunction(L, SetglobalHander);
	lua_settagmethod(L, tag, "setglobal");

This doesn't work, I guess I am missing something..  I know I have raised a
couple of issues regarding this over the last week or so, but I just can't
get anything going, and am getting frustrated.  There seems to be a huge
lack of examples around even in the archives.  All the documentation around
Lua is very terse, and doesn't seem to be geared to Lua newbies like me. :(

Chris Percival
Software Engineer
Interaxis Computing Ltd.
DDI:  +44 (0)1249 700072
http://www.interaxis.co.uk/


Reply | Threaded
Open this post in threaded view
|

Re: Tag methods

Peter Loveday-2
What version of Lua are you using?

This works for me in 4.1 work 3 :


lua_newtable(L);

lua_pushstring(L, "settable");
lua_pushcfunction(L, global_settable);
lua_settable(L, -3);

lua_seteventtable(L, LUA_GLOBALSINDEX);


Love, Light and Peace,
- Peter Loveday
eyeon Software


----- Original Message ----- 
From: "Chris Percival" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, February 06, 2002 4:15 AM
Subject: Tag methods


> Ok I give up, can someone give me a clear example of how to set a tag method
> for 'setglobal' for example?
> 
> For example something like this:
> 
> lua_pushnumber(L, 1);
> lua_setglobal(L, "Batch");
> int tag = lua_newtag(L);
> lua_pushcfunction(L, SetglobalHander);
> lua_settagmethod(L, tag, "setglobal");
> 
> This doesn't work, I guess I am missing something..  I know I have raised a
> couple of issues regarding this over the last week or so, but I just can't
> get anything going, and am getting frustrated.  There seems to be a huge
> lack of examples around even in the archives.  All the documentation around
> Lua is very terse, and doesn't seem to be geared to Lua newbies like me. :(
> 
> Chris Percival
> Software Engineer
> Interaxis Computing Ltd.
> DDI:  +44 (0)1249 700072
> http://www.interaxis.co.uk/
> 
> 


Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

David Jeske-3
In reply to this post by David Jeske-3
(forwarded on due to accidental private reply)

Well, here goes another attempt to post from Yahoo groups... wonder 
if it will actually make it to the list...

--- In lua-l@y..., David Jeske <jeske@c...> wrote:
 I've already voiced my opinion that amassing a large set of standard
> modules for Lua (ala Perl, Python, Ruby, etc) is a wasted effort. 
One
> motivation for that thought is that once Lua had exceptions, a
> class-esq system, and a bunch of modules, it would largly be the 
same
> as all those other systems, and it's just silly wheel-reinventing 
IMO,
> to have so many similar systems.
> 

I agree completely, I don't want another Python.  Lua is fast and 
small, and usable in embedded systems.  I could really care less 
about the discussions people have about lexical scoping, and 
correctness, and anything that isn't about size and speed.

> Some examples of items discussed on the list which might be useful
> additions include:
> 
>  1) Memory management optimizations for small memory for embedded 
use
>  2) More real-time Garbage collection optimizations for lowering 
>     collection pause time (as it seems Lua has been picked up among
>     Game programmers)
>  3) code-safety features such as "require variable declarations" or
>     static typing (ala unrealscript)
>  4) compiling Lua code into C 

#2 above is of the most concern.  I would really like to see a 
deterministic garbage collector of some sort.  



Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

paulmatthews
> 3) code-safety features such as "require variable 
> declarations" or static typing (ala unrealscript)
>
IMHO a lot of errors can be traced back to these two
situations, well in my code at least. :-)

Const-correctness is another one. And it can be 
applied at compile to byte code time, rather than 
at run time. ala C++

My other pet hate is the way things get automatically 
cast to fit the situation. I always feel that they 
should be explicit. Or it it just me? 
Silly (non lua) example below.

  complex a = 1.0, 2.0;
  number  b = 7;
  string  c = string(b);  //ie string string(number);
  string  d = string(a);  //ie string string(complex);
    
> >  4) compiling Lua code into C 
>
Compile byte code into C. 



Reply | Threaded
Open this post in threaded view
|

RE: Unique directions for Lua?

John Passaniti-4
In reply to this post by David Jeske-3
> What unique directions can Lua take which will
> make it better for embedding?

I'm glad questions and comments like yours continue to come up every now and
then.  It means people still care about these issues, and that means that I
continue to have the option of using Lua.  Sometimes I get the feeling that
some people want to take Lua into directions that would make it less
suitable for my embedded work.

And when I use the word embedded, I'm talking about embedded systems-- not
just embedding Lua into a larger application.  And that's a world that I
think a lot of people don't really appreciate.  These kids today with their
gigabytes of system memory, 64-bit processors, and massive operating
systems.  Most of the time the targets I work on are 8-bit and 16-bit
microcontrollers with less than 64k of RAM and ROM, no operating system, and
tiny stacks.  Those platforms aren't really appropriate for Lua as it
currently is, but if you're looking for a unique direction to take Lua,
that's certainly one place I'd like to see future effort.  I keep telling
myself that when I get some free time, I'm going to work on "microLua" a
version of Lua that implements the Lua VM for tiny targets.  At my current
rate, I should have some free time in 2015.

For now, my experience embedding Lua in an embedded system was primarily
with the CPC4400 Ethernet switching platform (see the Lua user products page
for more information for those that care).  I'm also working to embed Lua as
a scripting language inside a home theatre management system that I'm
working on.

But back to my stupid ideas.

I'd like to see the Lua compiler implemented in... Lua.  In my experience so
far embedding Lua into an embedded system, I found that the compiler was
seldom used.  In my case, I precompiled Lua code outside the embedded system
and burned it into flash.  Having the Lua compiler in Lua would let me do
interactive development on the embedded target by downloading the compiler
and then unloading it when I no longer needed it.  I suspect that with
careful coding, the Lua compiler would be smaller (both in Lua source and
object) than the equivalent C code.  I guess this gets into a bootstrap
issue of how would you build the Lua compiler without an existing Lua
compiler.  My brain hurts.





Reply | Threaded
Open this post in threaded view
|

Re: Tag methods

Peter Shook-3
In reply to this post by Chris Percival
Chris Percival wrote:
> 
> Ok I give up, can someone give me a clear example of how to set a tag method
> for 'setglobal' for example?
> 
> For example something like this:
> 
>         lua_pushnumber(L, 1);
>         lua_setglobal(L, "Batch");
>         int tag = lua_newtag(L);     
>         lua_pushcfunction(L, SetglobalHander);
>         lua_settagmethod(L, tag, "setglobal");
> 
> This doesn't work, I guess I am missing something..  I know I have raised a
> couple of issues regarding this over the last week or so, but I just can't
> get anything going, and am getting frustrated.  There seems to be a huge
> lack of examples around even in the archives.  All the documentation around
> Lua is very terse, and doesn't seem to be geared to Lua newbies like me. :(

You have only set the tag-method for the 'setglobal' event of some new
tag to be the function 'SetglobalHander'.  As lhf said, you must also
explicitly tag the values that you want to be treated magically.  You
would use the function lua_settag for this.  The manual clearly states
that only userdata and tables can have new tags.

It's important to note that only values are tagged.  Variables contain
values, but it is the value that has the tag and therefor it is the
value that has the magic.  So if a variable has a value that doesn't
have any magic, it's a pretty dull variable, and not much is going to
happen.

All values have a tag which is just some number defined in lua.h

#define LUA_TUSERDATA   0
#define LUA_TNIL        1
#define LUA_TNUMBER     2
#define LUA_TSTRING     3
#define LUA_TTABLE      4
#define LUA_TFUNCTION   5

$ lua
Lua 4.0  Copyright (C) 1994-2000 TeCGraf, PUC-Rio
> print( tag(nil), tag(1), tag"", tag{}, tag(tag) )
1       2       3       4       5
> print(newtag())
9
> print(newtag())
10
> 

The example in the FAQ is interesting because it makes all function
values magical in that if you try to set a global variable that has a
function value, then the protect function will get called.

> function protect(x) error("cannot redefine "..x) end
>
> print(protect)
function: 0x8064ef0
> print(tag(protect))
5
> print(tag(foreach))
5
> settagmethod(tag(protect),"setglobal",protect)
> foreach = 99
error: cannot redefine foreach
stack traceback:
   1:  function `error' [C]
   2:  function `protect' at line 1 [string "function protect(x)
error("cannot redefine ..."]
   3:  main of string "foreach = 99" at line 1
> 

If you change the tagmethod to the print function, you can see what
arguments are passed to the tag method.

> settagmethod(tag(protect),"setglobal",print)
> 
> foreach = 999
foreach function: 0x8060ae8     999
> 

Remember that tag(protect) is nothing more that LUA_TFUNCTION which is
the number 5.  Now we see that when the tag method is called for the
pair (tag=5,event='setglobal'), it is passed three values: the variable
name, the old value of the variable, and the new value that you are
trying to set it to.  Just like the Lua Reference manual says on page
17.

If you want to protect only certain functions and not others, then set
the tag method for the 'setglobal' event for function values like so:

        lua_pushcfunction(L, SetglobalHander);
        lua_settagmethod(L, LUA_TFUNCTION, "setglobal");

And then use the variable name passed to SetglobalHander to decide if
you want to barf or not.

You should re-read page 14 of the Lua 4.0 reference manual very
carefully.  http://www.lua.org/ftp/

Good luck,

- Peter

Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

David Jeske-3
In reply to this post by John Passaniti-4
On Wed, Feb 06, 2002 at 01:10:19AM -0500, John Passaniti wrote:
> And when I use the word embedded, I'm talking about embedded
> systems-- not just embedding Lua into a larger application.  And
> that's a world that I think a lot of people don't really appreciate.
> These kids today with their gigabytes of system memory, 64-bit
> processors, and massive operating systems.  Most of the time the
> targets I work on are 8-bit and 16-bit microcontrollers with less
> than 64k of RAM and ROM, no operating system, and tiny stacks.
> Those platforms aren't really appropriate for Lua as it currently
> is, but if you're looking for a unique direction to take Lua, that's
> certainly one place I'd like to see future effort.  I keep telling
> myself that when I get some free time, I'm going to work on
> "microLua" a version of Lua that implements the Lua VM for tiny
> targets.  At my current rate, I should have some free time in 2015.

I hate to nay-say Lua on the mailing list, but when you have tiny
systems like this, dosn't it make sense to avoid memory expensive
stuff like lua string-based hash tables and the overhead of
interpreting bytecodes?

> But back to my stupid ideas.
> 
> I'd like to see the Lua compiler implemented in... Lua.  

I'm sorry, but I have to laugh at that one. Lua is cool and all, but
not that cool. :) Although to each his own.

> In my experience so far embedding Lua into an embedded system, I
> found that the compiler was seldom used.  In my case, I precompiled
> Lua code outside the embedded system and burned it into flash.
> Having the Lua compiler in Lua would let me do interactive
> development on the embedded target by downloading the compiler and
> then unloading it when I no longer needed it.  

You can already do interactive development on the target. The lua
library has the parser and bytecode compiler built right in. just
dostring() away.

> I suspect that with careful coding, the Lua compiler would be
> smaller (both in Lua source and object) than the equivalent C code.

I doubt it.

> I guess this gets into a bootstrap issue of how would you build the
> Lua compiler without an existing Lua compiler.  My brain hurts.

If we imagine for a second that someone might be crazy enough to do
this, Lua does not generate machine code, so the bytecode interpreter
would still be written in C. It would just be the code which parses
the lua syntax and generates bytecodes which would be written in Lua.

Good luck. :)

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Unique directions for Lua?

Enrico Colombini
In reply to this post by John Passaniti-4
>And when I use the word embedded, I'm talking about embedded 
>systems-- not just embedding Lua into a larger application.  
>And that's a world that I think a lot of people don't really appreciate.

I think I can appreciate it: I used to design industrial applications with
a KIM-1, i.e. an 8-bit 6502 and (in the beginning) 1 KB of RAM, using a
pencil-and paper assembler :-)

Lua, in a sense, has a problem: it is too good and versatile, so different
people would like it to evolve in different directions: a scripting
language, a general-purpose full-fledged language, a specialized embedded
language, and so on (BTW, I plan to use it on all these fronts).

My 0.05 Euro: Lua should stay exactly as it is: essential, elegant, compact
and flexible. There is no point in having it become just like another
existing language.

Of course I'd welcome specialized, derived languages like a "microLua" for
small embedded systems, as long as their development is distinct from that
of Lua proper.

  Enrico


Reply | Threaded
Open this post in threaded view
|

RE: Unique directions for Lua?

Philippe Lhoste
In reply to this post by David Jeske-3
> >And when I use the word embedded, I'm talking about embedded 
> >systems-- not just embedding Lua into a larger application. 
> >And that's a world that I think a lot of people don't really appreciate.
> 
> I think I can appreciate it: I used to design industrial applications with
> a KIM-1, i.e. an 8-bit 6502 and (in the beginning) 1 KB of RAM, using a
> pencil-and paper assembler :-)

Hey, I learned programming this way! Well, after toying with TI-57/58/59...

> Lua, in a sense, has a problem: it is too good and versatile, so different
> people would like it to evolve in different directions: a scripting
> language, a general-purpose full-fledged language, a specialized embedded
> language, and so on (BTW, I plan to use it on all these fronts).
> 
> My 0.05 Euro: Lua should stay exactly as it is: essential, elegant,
compact
> and flexible. There is no point in having it become just like another
> existing language.

I may dream, but I think Lua can still meet these requirements while
becoming even more versatile. We probably just have to add a little stuff in the
core, that can be compiled away if needed, as Roberto indicated, and some
external, probably third party libraries.
These improvements shouldn't go in the way of embedded/tiny systems. You
have the sources, you have a number of pre-processor directives to tailor the
code without fuss, and ultimately, you can hack the source. Although I agree it
is a last resort solution, as it can alter the language (to the point it is
no longer Lua, syntaxically speaking) and it is hard to keep with the new
versions.

BTW, I don't want Lua to become like another language. I like it the way it
is, even if it can stand some (minor?) improvements :-) I don't want another
Python (or Perl, etc.), indeed, weighting megabytes just to run a little
script.

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

Reuben Thomas
In reply to this post by paulmatthews
> My other pet hate is the way things get automatically
> cast to fit the situation.

Me too. I always do explicit casts to show what I mean, and automatic
coercion makes the VM (slightly) more complex than it needs to be. Even
for naive users, the error message that you've supplied a number where a
string was required or vice versa is easy to understand and easy to fix;
it's also easy to give some examples that shows why it's desirable not to
make this automatic. Where automatic conversion is desirable, it can be
done by the program (so that you don't need to put "tostring" and
"tonumber" in config files, for example).

-- 
http://sc3d.org/rrt/ | Analogy is a midwife, identity a murderer


Reply | Threaded
Open this post in threaded view
|

RE: Unique directions for Lua?

Reuben Thomas
In reply to this post by John Passaniti-4
> Sometimes I get the feeling that some people want to take Lua into
> directions that would make it less suitable for my embedded work.

Like me, with standard Lua libraries and big distributions? I try to be
careful to make a distinction between core Lua (which I'd like to see stay
small and portable) and what one might term Lua distributions (which I'd
like to see build out of the box with rich functionality on a wide range
of systems, and come with a large range of Lua and C libraries).

These goals are not opposed, it's just that most single-implementation
languages are also single-distribution.

Note that I've never advocated making the language itself (much) bigger
and certainly not slower in the common case.

Having Lua working better on embedded systems would be great.

> I'd like to see the Lua compiler implemented in... Lua.

Interesting, as I would too, but for rather different reasons: to make it
easier to change the language.

> I guess this gets into a bootstrap issue of how would you build the Lua
> compiler without an existing Lua compiler.  My brain hurts.

How is this different from "how would you build the C compiler without an
existing C compiler"? Anyway, we *have* an existing Lua compiler.

-- 
http://sc3d.org/rrt/ | Quidquid latine dictum sit, altum viditur (Anon)


Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

Reuben Thomas
In reply to this post by David Jeske-3
> I hate to nay-say Lua on the mailing list, but when you have tiny
> systems like this, dosn't it make sense to avoid memory expensive
> stuff like lua string-based hash tables and the overhead of
> interpreting bytecodes?

Hash tables I would worry about. Forth and BCPL (as implemented in
Cintcode)  demonstrates that interpretation can improve matters in a small
system.

-- 
http://sc3d.org/rrt/ | computation, n.  automated pedantry


Reply | Threaded
Open this post in threaded view
|

Re: Unique directions for Lua?

CRIBBSJ
In reply to this post by David Jeske-3
wuerchj wrote:

I agree completely, I don't want another Python. Lua is fast and small, and usable in embedded systems. I could really care less about the discussions people have about lexical scoping, and correctness, and anything that isn't about size and speed.

IMHO, it would make more sense to compare Lua to Tcl, not Python or Perl. Python is know for its "batteries" included philosophy. Perl is just ... bloated (not that that's horrible; you can get A LOT done with Perl). Tcl, on the other hand, is still relatively lean and mean. Most of the time, if you want to run a Tcl extension, you just download it into your working directory and either "source" it or "load" it. No having to mess with PPM (sp?) or running setup.py.

However, Tcl does have some pretty funky syntactical quirks. Thats why I get excited when I think about the idea of having the clean syntax of Lua with the ease of use of Tcl's extension usage. I look at Lua as being a successor to Tcl. Of course, I hold Tcl in a lot higher regard than a lot of people do. :)

By the way, in response to your statement above, there are a lot of people on this list who could care less about the discussions people have about Lua's embedded capabilities. :) I think Lua is a good enough language to satisfy both camps.

Jamey.

Reply | Threaded
Open this post in threaded view
|

RE: Unique directions for Lua?

John Passaniti-4
In reply to this post by David Jeske-3
> I hate to nay-say Lua on the mailing list, but when
> you have tiny systems like this, dosn't it make
> sense to avoid memory expensive stuff like lua
> string-based hash tables and the overhead of
> interpreting bytecodes?

Often, yes.  One platform I'm currently working on is a 8-bit HC08 with 32k
of flash and a tiny amount of RAM.  Lua on such a system would be totally
stupid, and I wouldn't even attempt it.

But there are small systems I would try it on.  Another platform I'm working
on is 8051-based, but we've extended it with bank switching logic to have a
huge amount of program and data space.  My interest in Lua for such a system
is not to have a high-performance system, but to have a system where
extensions and customizations can be written in a high-level language like
Lua.

More realistically, our next project will be using a 16-bit ColdFire
processor with a large amount of RAM.  There, I expect getting Lua running
there is going to be far easier.

> You can already do interactive development on the
> target. The lua library has the parser and bytecode
> compiler built right in. just dostring() away.

I know; on the CPC4400 project, we embedded Lua into the embedded Ethernet
switch platform and had great fun working interactively.  As a fan of Forth,
this was no big deal for me, but for the folks at work who only knew C,
interactive development blew their minds.

> > I suspect that with careful coding, the Lua compiler
> > would be smaller (both in Lua source and object) than
> > the equivalent C code.
>
> I doubt it.

The goal of having the Lua compiler as a Lua program is really to minimize
the Lua kernel down to the absolute bare minimum, but still have the ability
to do interactive work on it.  As someone who spends probably 85% of my
programming time on very small systems, I fully appreciate that doing what I
want may be some combination of insane and stupid.  And really, I've already
solved the problem-- Forth.  But I like to explore the limits of things, and
seeing if Lua can work on such platforms is one of those limits.  It might
not result in anything useful when I'm done, but the experience should be
fun.

For those interested in the kind of things one can do with a virtual machine
on a tiny 8-bit target, look at ftp://ftp.dunfield.com/avirtual.zip for
inspiration.  It's not Lua-- described is a small, high-performance VM used
to get past a hardware environment that has an extremely restricted address
space.  But the essential ideas here are what I'm going to explore.



123