Re: Making LUA safe to execute untrusted scripts [replay]

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

Luiz Henrique de Figueiredo
[listproc choked on this one. --lhf]

>From: Bennett Todd <[hidden email]>
>Date: Mon, 17 Apr 2000 20:03:13 -0400
>To: Luc Van den Borre <[hidden email]>
>Cc: Multiple recipients of list <[hidden email]>

2000-04-17-18:32:48 Luc Van den Borre:
> I'm interested in mobile code - (LUA) code received by an
> application from an external, perhaps untrusted source.

A very, very tough problem.

> - restrictions on file-access
> - cpu usage limitations (which would probably mean pre-emptive
>   multitasking between scripts)
> - memory limitations (no more than a fixed amount of memory to
>   play with)
> - time limitations (run no longer than fixed amount of cycles or
>   get killed)
> - doesn't crash - or at least crashes nicely without taking down
>   the host program

Noble goals, and nicely specified. A couple more to add:

  - restrictions on memory access within the program (can't read or
    write arbitrary locations in memory within the process)
  - restrictions on other syscalls --- e.g. connect, kill, ...

I've no idea whether Lua is well-suited to applying such
restrictions, but I'll say this: if its designers felt that it was,
I'd be a _lot_ liklier to trust it in a role like this than any
competitor I've seen, including most especially Java and Javascript.

Simplicity is a virtue. Doubly so when security is a goal.

-Bennett

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

stev
Bennett Todd wrote:
> Luc Van den Borre:
> > I'm interested in mobile code - (LUA) code received by an
> > application from an external, perhaps untrusted source.
> 
> A very, very tough problem.

Do you have details on what parts are tough besides the ones mentioned
below?

> > - restrictions on file-access
> > - doesn't crash - or at least crashes nicely without taking down
> >   the host program

These are easy - just modify thr file access functions and use the
lua error hooks to catch errors. 

> > - cpu usage limitations (which would probably mean pre-emptive
> >   multitasking between scripts)
> > - memory limitations (no more than a fixed amount of memory to
> >   play with)
> > - time limitations (run no longer than fixed amount of cycles or
> >   get killed)

These would be nice, but it's not clear to me that they are necessary.
They also cause issues when good programs that people want to use these
resources need them.

> 
> Noble goals, and nicely specified. A couple more to add:
> 
>   - restrictions on memory access within the program (can't read or
>     write arbitrary locations in memory within the process)

Lua already does this, right?

>   - restrictions on other syscalls --- e.g. connect, kill, ...

This is easy to implement.

> I've no idea whether Lua is well-suited to applying such
> restrictions, but I'll say this: if its designers felt that it was,
> I'd be a _lot_ liklier to trust it in a role like this than any
> competitor I've seen, including most especially Java and Javascript.
> 
> Simplicity is a virtue. Doubly so when security is a goal.

Agreed.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
[listproc choked on this one too. --lhf]

>From: Bennett Todd <[hidden email]>
>To: [hidden email]
>Cc: Multiple recipients of list <[hidden email]>

2000-04-17-21:49:55 [hidden email]:
> Bennett Todd:
> > Luc Van den Borre:
> > > I'm interested in mobile code - (LUA) code received by an
> > > application from an external, perhaps untrusted source.
> > 
> > A very, very tough problem.
> 
> Do you have details on what parts are tough besides the ones
> mentioned below?

Details, no. Generalities, well, I'll try and blither on a little
longer:-).

There've been quite a few efforts, in different contexts, to create
safe mobile code. The currently fashionable cases include Java
and Javascript. An older example would be using Postscript for
a portable document format. I can't recall a single effort that
has succeeded, in the sense of resisting even moderate efforts to
thwart it. Postscript has come the closest; by disabling all I/O
operations, and not having anything else in the process memory space
to worry about, and not worrying if the thing slams against process
limits and dies, previewers are hard enough to hack that people
haven't bothered recently; and printers aren't interesting to hack.

But when you want the mobile code to be able to interact with other
parts of the process space, and with the rest of the system, in a
restricted, controlled fashion, then you have to come up with a way
to specify the restrictions and controls. And the way you specify
it has to be simple enough to make it possible to understand and
modify the specification. And it has to be simple enough to
implement so the implementation is free of exploitable bugs.

So far that collection of simplicity hasn't been assembled. But
then, there hasn't been a programming language architect in decades
who delivered simplicity like Lua's simplicity. And Lua's a _lot_
prettier than Forth:-).

-Bennett

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts

Luc Van den Borre-2
In reply to this post by stev
| > > I'm interested in mobile code - (LUA) code received by an
| > > application from an external, perhaps untrusted source.
| > A very, very tough problem.
| Do you have details on what parts are tough besides the ones mentioned
| below?

If you needed to ensure these conditions, say, with some C code, or even a compiled executable, this would be 'hard'.
I'm hoping LUA's already existing protection mechanisms allow some problems to be solved easily, so we can focus on a
small set of the 'hard' ones.

| > > - cpu usage limitations
| > > - memory limitations
| > > - time limitations
| These would be nice, but it's not clear to me that they are necessary.
| They also cause issues when good programs that people want to use these
| resources need them.

Different scripts could have different security policies applied to them, depending on the application.
In the example I gave earlier, after I've drunk my can of coke, I don't want the coke-can script to hang around. Even if
the script doesn't unload itself, I want my application to do it. As to CPU and memory usage - there's no reason an app
can't use whatever is available, but it mustn't bring the system down by hogging them.


| >   - restrictions on memory access within the program (can't read or
| >     write arbitrary locations in memory within the process)
| Lua already does this, right?

Yes, but (how easily) can a malicious hacker find ways around this?

About the pre-emptive multi-tasking idea - has anyone tried this? I assume this would be easier to implement in version
3.3?

--Luc

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

Nick Trout-2
In reply to this post by Luiz Henrique de Figueiredo
> 2000-04-17-21:49:55 [hidden email]:
> > Bennett Todd:
> > > Luc Van den Borre:
> > > > I'm interested in mobile code - (LUA) code received by an
> > > > application from an external, perhaps untrusted source.
> > >
> > > A very, very tough problem.
> >
> > Do you have details on what parts are tough besides the ones
> > mentioned below?
>
> Details, no. Generalities, well, I'll try and blither on a little
> longer:-).
>
> There've been quite a few efforts, in different contexts, to create
> safe mobile code. The currently fashionable cases include Java
> and Javascript. An older example would be using Postscript for
> a portable document format. I can't recall a single effort that
> has succeeded, in the sense of resisting even moderate efforts to
> thwart it. Postscript has come the closest; by disabling all I/O
> operations, and not having anything else in the process memory space
> to worry about, and not worrying if the thing slams against process
> limits and dies, previewers are hard enough to hack that people
> haven't bothered recently; and printers aren't interesting to hack.
>
> But when you want the mobile code to be able to interact with other
> parts of the process space, and with the rest of the system, in a
> restricted, controlled fashion, then you have to come up with a way
> to specify the restrictions and controls. And the way you specify
> it has to be simple enough to make it possible to understand and
> modify the specification. And it has to be simple enough to
> implement so the implementation is free of exploitable bugs.
>
> So far that collection of simplicity hasn't been assembled. But
> then, there hasn't been a programming language architect in decades
> who delivered simplicity like Lua's simplicity. And Lua's a _lot_
> prettier than Forth:-).

What about Python? Its simpler and more powerful than Lua. It has proper classes
and no confusing upvalues or tags. Lua is faster and more compact though. Better
for games!

I think if you set up a state for each object "thread" and altered Lua's memory
manager (I think you'll only have to modify one function luaM_realloc for all
allocation.) then you could establish a fairly solid system. Its easy to limit
the amount of system level access the user would have and memory management
could be restricted and monitored using your modified allocation system. I'd be
tempted to do something like automatic persistant states for objects then the
user doesnt need (writeable) file access. eg. any information could be stored
using something akin to the registry or .ini files. Or each object could have a
VM space which is initialised on creation and serialised, retaining its state?

It would be really nice if there was a version of Lua that you could just give
some memory (including the state info) and all allocation was done through this
and all code was generated in this. You could serialise a whole frozen Lua
state? Great for memory limited systems (and you could monitor illegal memory
access more easily). Maybe it exists already and I havent read the docs!

N






Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts

Erik Hougaard
In reply to this post by Luc Van den Borre-2
> About the pre-emptive multi-tasking idea - has anyone tried this? I assume
this would be easier to implement in version
> 3.3?

I'm running each state in seperate threads - works like a charm :-) .. .I'm
using my modified 3.2 to handle the states..

/Erik

Reply | Threaded
Open this post in threaded view
|

RE: Making LUA safe to execute untrusted scripts [replay]

Jim Mathies-2
In reply to this post by Luiz Henrique de Figueiredo
 just give some memory (including the state info) and all allocation 
 was done through this

Converting Lua's memory manager to use a memory pool is easy thanks to
their
centralized allocation handlers. You could also tie this into the
garbage 
collection to optimize when free memory  is tight. 

I'm not sure though why you can't use the existing methods of
dumping the entire program state out to a text file.  That ability
in there right now right?  Why do you need to go at it from the 
lowest level - the memory everything is stored in.  This is where 
your going to run into cross platform issues.  Using some sort
of standardized format in a text or binary file to load your
objects and state back into the vm would be simpler I think.


Regards,
Jim

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

stev
In reply to this post by Nick Trout-2
"Nick Trout" <[hidden email]> wrote:
> What about Python? Its simpler and more powerful than Lua. 

How is Python simpler or more powerfull?

> It has proper classes and no confusing upvalues or tags. 

That does make it easier to get started but Python classes are very limiting
compared to prototypes in Lua. You can also easily implement Python-like
classes in Lua. upvalues and tags are confusing, but aren't things most Lua 
developers should ever have to use after setting up their object system.

> It would be really nice if there was a version of Lua that you could just 
give
> some memory (including the state info) and all allocation was done through 
this
> and all code was generated in this. You could serialise a whole frozen Lua
> state? Great for memory limited systems (and you could monitor illegal 
memory
> access more easily). Maybe it exists already and I havent read the docs!

That would be very cool. LISP and Smalltalk have that ability. There are 
portablility issues for using the same frozen state on a different platform 
though.

Steve



Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

stev
In reply to this post by Jim Mathies-2
Jim Mathies <[hidden email]> wrote:
> I'm not sure though why you can't use the existing methods of
> dumping the entire program state out to a text file.  That ability
> in there right now right?  Why do you need to go at it from the 
> lowest level - the memory everything is stored in.  This is where 
> your going to run into cross platform issues.  Using some sort
> of standardized format in a text or binary file to load your
> objects and state back into the vm would be simpler I think.

Jim,

There isn't any built-in way in Lua that I know of to do this yet.
 
You're probably thinking of the work I was doing to do this. It walks the
globals and all tables, writes them out with unique ids and keeps track
of the ones that have already been written. To load them back, it reads
them all in and then links them all together again. 

This technique is portable except some lua data is to things like 
C-functions 
which aren't guaranteed to loading into the namespace on other lua vms, and 
C 
pointers whose value may not be meaningfull when the dump is next loaded. 
Of course, a memory dump would have similar problems.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

Nick Trout-2
In reply to this post by stev
> "Nick Trout" <[hidden email]> wrote:
> > What about Python? Its simpler and more powerful than Lua.
>
> How is Python simpler or more powerfull?

The language design is cleaner and simpler I think. For instance, this argument
about global values being a global table and not a special case already exists
in Python eg. dir(__builtins__) gives you all global methods and exceptions. The
source is also very easy to follow although there is less Lua code! I'm not
trying to deride Lua. Every language has its strengths and you want to use the
best/most practical tool for the job. Lua is easier to embed as you dont have to
mess around with reference counting, very simple interface. Some applications
benefit from Lua being used as its scripting language and some benefit from
Python being used, obviously depends on you needs (application size, memory
available, ease of customisation, speed of script execution, language features,
script supported tookits and libraries etc). Lua is gradually evolving into
being a practical programming language whereas before its goal was just to
provide an easy mechanism to configure your application. Please correct me if I
am wrong. Therefore the language has certain nuances (eg. this global table
problem) whereas Python was created with the intention of being a pragmatic
scripting language. eg. its more OO (list and dictionaries accept methods) and
its syntax is less "bodged" eg. "for" keyword instead of a function in Lua.
Python classes support inheritance. I know a lot of the functionality is
duplicated and Lua itself admits to being a meta language which for me makes it
slightly more complicated ie. less readable/simple! Python is more powerful IMO
for being more OO.

> > It has proper classes and no confusing upvalues or tags.
> That does make it easier to get started but Python classes are very limiting
> compared to prototypes in Lua. You can also easily implement Python-like
> classes in Lua. upvalues and tags are confusing, but aren't things most Lua
> developers should ever have to use after setting up their object system.

I agree with this. Can you do inheritance with Lua? Copy an inherited
class/table into the inherited class table?

> > It would be really nice if there was a version of Lua that you could just
> give
> > some memory (including the state info) and all allocation was done through
> this
> > and all code was generated in this. You could serialise a whole frozen Lua
> > state? Great for memory limited systems (and you could monitor illegal
> memory
> > access more easily). Maybe it exists already and I havent read the docs!
>
> That would be very cool. LISP and Smalltalk have that ability. There are
> portablility issues for using the same frozen state on a different platform
> though.

I think this would be a great feature. Good for embedded systems and "threads"
(in games!). Suppose you could use some kind of compression as well for
serialisation. Would be especially good now Lua is properly reentrant (I think I
read that on here).




Reply | Threaded
Open this post in threaded view
|

RE: Making LUA safe to execute untrusted scripts [replay]

Vincent Penquerc'h-2
> I think this would be a great feature. Good for embedded systems 
> and "threads"
> (in games!). Suppose you could use some kind of compression as well for
> serialisation. Would be especially good now Lua is properly 
> reentrant (I think I
> read that on here).

IMHO, it would be best for Lua itself not to deal with compression or
I/O (or at least leave an option not to do so). The application would
use its own system for writing/reading to disk or whatever. I now have
a scheme where a Lua object has a 'save' and 'load' method that call
C entry points, but this requires the script to know what to load and
to save, which it shouldn't have to deal with.

-- 
Lyrian 

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts

Luiz Henrique de Figueiredo
In reply to this post by Luc Van den Borre-2
Here are some comments on this very interesting thread.
It's a bit long, so bear with me :-)

>From: "Luc Van den Borre" <[hidden email]>

>I'm interested in mobile code - (LUA) code received by an application from an external, perhaps untrusted source.

The current version (3.2) of luac has a '-t' option. To quote the man page
(http://www.tecgraf.puc-rio.br/lua/manual/luac.html):

-t   perform a thourough integrity test when undumping. Code that passes
     this test is completely safe, in the sense that it will not break the
     interpreter. However, there is no guarantee that such code does
     anything sensible. (None can be given, because the halting problem is
     unsolvable.)

The function that implements this test in luac is

	void luaU_testchunk(TProtoFunc* Main);

declared in luac.h. So, it is already a public function and could be used by
a host program.
When luaU_testchunk finds something wrong with the code, it calls lua_error,
and so errors can be trapped.
But perhaps it would be easier to have an API that receives a lua_Object
or a chunk of memory containing bytecodes that returns yes or no.
I could do this if there is demand.

>- restrictions on file-access

It is easy to undefine any built-in function before running a chunk.
CGILua does exactly this.

>- cpu usage limitations (which would probably mean pre-emptive multitasking between scripts)
>- memory limitations (no more than a fixed amount of memory to play with)
>- time limitations (run no longer than fixed amount of cycles or get killed)

This is not so simple to define in detail.
But you could do something with the call hook or by counting the number of
Lua VM instructions that are executed (you'd have to change luaV_execute a
little to do this).

The new version, which has now been officiallu named 4.0 (alpha), will have
states with user-selected stack size.

>- doesn't crash - or at least crashes nicely without taking down the host program

This is a *design* requirement for Lua.
Lua programs should never crash the host.

>From: Bennett Todd <[hidden email]>

>Noble goals, and nicely specified. A couple more to add:
>
>  - restrictions on memory access within the program (can't read or
>    write arbitrary locations in memory within the process)

This is also by design.
Not even the presence of userdata threatens the integrity of the host's memory.

>I've no idea whether Lua is well-suited to applying such
>restrictions, but I'll say this: if its designers felt that it was,
>I'd be a _lot_ liklier to trust it in a role like this than any
>competitor I've seen, including most especially Java and Javascript.

We do feel that Lua provides a trusted enviroment for running scripts.
We take great care that the implementation does this.

>So far that collection of simplicity hasn't been assembled. But
>then, there hasn't been a programming language architect in decades
>who delivered simplicity like Lua's simplicity. And Lua's a _lot_
>prettier than Forth:-).

Thanks for the compliments. They show that we have succeeded!
Of course, every programming language has is quirks, and we cannot please
everyone. But Lua *is* great, even if I say so myself! :-)

>From: "Luc Van den Borre" <[hidden email]>

| >   - restrictions on memory access within the program (can't read or
| >     write arbitrary locations in memory within the process)
| Lua already does this, right?
>Yes, but (how easily) can a malicious hacker find ways around this?

Like I said above, we don't know of any exploits that a malicious hacker could
use to crash a host program from within Lua. Any such exploit is definitely a
bug and will be fixed promptly.

>From: "Nick Trout" <[hidden email]>

>It would be really nice if there was a version of Lua that you could just give
>some memory (including the state info) and all allocation was done through this
>and all code was generated in this.

This seems easy to do because it only requires to change luaM_realloc, as
someone already remarked.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

Roberto Ierusalimschy
In reply to this post by Nick Trout-2
> eg. "for" keyword instead of a function in Lua.

We forgot to tell: Lua will have a "for"! (next week)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

David Jeske-3
On Wed, Apr 19, 2000 at 10:26:43AM -0300, Roberto Ierusalimschy wrote:
> > eg. "for" keyword instead of a function in Lua.
> 
> We forgot to tell: Lua will have a "for"! (next week)

What will the style of the for be?

One of things which I like most about Python is the simple list based
"for". It's responsible for preventing lots of bugs IMO. However, I
noticed a snafu with doing this kind of thing in Lua, namely that
there dosn't seem to be a "next" tag method.

-- For example, given a Python-esq looping structure like:

  a = { 5, 6, 2 };

  for num in a do
    print num;
  end

-- you could have python style number loops based on a table/list, 
-- if you had a "next" tag.

  function range_next(table,curindex)
    if curindex == nil then
      return table['start'];
    end

    if curindex >= table['max'] then
      return nil;
    end
      
    return (curindex + 1);
  end

  range_tag = newtag()
  settagmethod(range_tag, "next", range_next)

  function range(max)
    loop_parms = { start = 0, max = max};
    settag(loop_parms, range_tag);
    return loop_parms;
  end

  for num in range(4) do
    print num
  end

---------------------------------------
-- I'm not as fond of the C style number loops
-- because they are so prone to errors:

  a = { 1, 2, 3 }

  len_a = length(a)

  for (x=0; x=x+1; x< len_a) do
    print num
  end

-- although at least you can do this:

  a = {1, 2, 3}

  for (num=next(a);num=next(a,x); num!=nil) do
    print num
  end

-- With only basic number style loops, iteration will
-- be somewhat strange IMO. Witness the example below:
 
  a = { 5, 6, 2 ; val = "this will cause weird behavior" }

  len_a = length(a) -- 4

  for num = 1 to length(a) do
    print a[num]
  end

  -- outputs: 5, 6, 2, nil

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

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

stev
In reply to this post by Nick Trout-2
"Nick Trout" <[hidden email]> wrote:
>  ...Python was created with the intention of being a pragmatic
> scripting language. eg. its more OO 

As a base system, I'd agree because Python comes with classes, but Lua
allows you to more easily build a more OO system(a prototype-based instead
of class-based OO language) on top of it than you could in Python.

>(list and dictionaries accept methods)

Could you explain this a bit more?

> and its syntax is less "bodged" eg. "for" keyword instead of a function in 
Lua.

I solved this problem for myself by writing a Collection(List) object that 
has
enumeration features.

> I know a lot of the functionality is
> duplicated and Lua itself admits to being a meta language which for me 
makes it
> slightly more complicated ie. less readable/simple! 

I agree. 

  local i, v = next(table, nil) 
  while ( i )
    ...
    i, v = next(table, i)
  end

isn't as nice as Python's:

  for v in table:
    ...

or lua style:

  for i, v in table:
    ...

> I agree with this. Can you do inheritance with Lua? Copy an inherited
> class/table into the inherited class table?

Yes. In fact, that's all that Python does. Python classes are basicaly just
dictionaries with a few extra convenience methods. In Lua, you can also 
implement
inheritance through delegation if you choose. I think this is covered in the
Lua FAQ.

I've implemented a prototype-based object system in Lua that uses delegation 

for inheritance. I could also put together a Python-like class system. If 
you
think you'd find these usefull, I could put them in a package and make them 
available.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

Edgar Toernig
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
> 
> We forgot to tell: Lua will have a "for"! (next week)

I already have one *g* ("for i,v in table do end" and
"for i in num,num do end").  But I found, that it's
not that useful without a break.  And it isn't even
much faster than foreach (and I think I have the fastest
possible implementation).  But a "for" and a "break" is
great :-)

Now that we have all these iterators, how about a "next"
tag method?

Ciao, ET.


Reply | Threaded
Open this post in threaded view
|

Re: Python and Lua

Edgar Toernig
In reply to this post by Nick Trout-2
Nick Trout wrote:
> Steve wrote:
> > How is Python simpler or more powerfull?
> 
> The language design is cleaner and simpler I think.

$if FLAME_MOOD
You must be joking!  They threw everything in that looks like OO.
Then this mess of different data types with overloaded operators.
And all those special __ identifiers.  Ok, the non-freeform syntax
is a matter of taste but I don't like it.  And the last one is the
buggy reference counting...

Really, comparing that monster of Python with the simple, lean and
clean Lua -- your statement must be a joke.
$end

Now I feel better *g*

Ciao ET.


Reply | Threaded
Open this post in threaded view
|

Re: Making LUA safe to execute untrusted scripts [replay]

Nick Trout-2
In reply to this post by stev
> As a base system, I'd agree because Python comes with classes, but Lua
> allows you to more easily build a more OO system(a prototype-based instead
> of class-based OO language) on top of it than you could in Python.

What is the difference between a prototype based OO system and a class based
one? I thought a prototyped systems were just part of the design phase of OO?!

> >(list and dictionaries accept methods)
> Could you explain this a bit more?

eg. Python:
[1,2,3,4,5,2,4,5].count(2)  count the number of 2's in the list.
{ 5:'apple', 6:'pear', 7:'banana' }.keys()  return the keys in the dictionary as
a list = [5,6,7]
This could be just seen as a style of implementation but I like it.Equally
ir( [ ] ) will give you a lists methods but this would imply that all objects
would inherit from an object containing a dir method if it were [ ].dir() which
is probably very bad?

> I solved this problem for myself by writing a Collection(List) object that
> has
> enumeration features.

This is what I find nice about Python you dont have to go round the houses all
the time to find solutions to programming styles ie. in Lua it seems you're
constantly trying to emulate the behaviour of other languages because a feature
you would like is lacking! Now you can see this as both a pain and great feature
(and it is a good feature but its a pain having to write extra code!). What I
would love is if there were a database of scripts on the Lua site implementing
these features so that users could pick and choose and it would be a great
advert for Lua and a good learning tool. I'm sure most casual Lua users are
unaware of the power Luas features or are not using them, me included! I am
using Lua in a hobbyist capacity whereas I use Python at work!! eg. I've only
really used the tag feature for data abstraction eg. vector/colour types etc. I
find Python more productive for being more fully featured. If we had had the
time on our latest project then I would almost certainly have included Lua but
we hard coded everything for speed due to an extremely tight deadline!!

[ By the way, on a seperate note, and you may know. Is Dylan similar to Lua? I
think that has language extension features. How does Lua compare? ]

> > I agree with this. Can you do inheritance with Lua? Copy an inherited
> > class/table into the inherited class table?
> Yes. In fact, that's all that Python does. Python classes are basicaly just
> dictionaries with a few extra convenience methods. In Lua, you can also
> implement
> inheritance through delegation if you choose. I think this is covered in the
> Lua FAQ.

Sorry couldnt find anything about this in the FAQ. I havent really used
delegation. I thought the benefit of it is that it extends the functionality of
objects at runtime, ie. it kind of emulates inheritance at runtime. This would
be useful in a statically typed language eg. C++, but since Python and Lua
classes are dynamic tables is this very useful? I'd be interested in seeing a
good example of this.

> I've implemented a prototype-based object system in Lua that uses delegation
> for inheritance. I could also put together a Python-like class system. If
> you
> think you'd find these usefull, I could put them in a package and make them
> available.

That would be very interesting. Don't go to too much trouble, if you have work
available then I'd like to see it.

Cheers,
Nick.






Reply | Threaded
Open this post in threaded view
|

Re: Python and Lua

Nick Trout-2
In reply to this post by Edgar Toernig
> > > How is Python simpler or more powerfull?
> >
> > The language design is cleaner and simpler I think.

$if CAT_PUT_AMONGST_PIGEONS
        :-)
$end

> $if FLAME_MOOD
> You must be joking!  They threw everything in that looks like OO.
> Then this mess of different data types with overloaded operators.
> And all those special __ identifiers.  Ok, the non-freeform syntax
> is a matter of taste but I don't like it.  And the last one is the
> buggy reference counting...

On comp.lang.python its often stated that Python is designed to be practical.
There are quite a few inconsistencies in the language syntactically and many
features are defined by taste rather than consistency but always the emphasis is
on usefulness. I think Python has to be the clearest and most productive
language I have used. I agree it does seem that "they threw everything in that
looks like OO" and disagreeing with the syntax of any language is a matter of
taste! You have more choice with Lua, that is its strength. Python's is that the
functionality is there and users concentrate on modules and extension libraries
hence further increasing its "usefulness".

> Really, comparing that monster of Python with the simple, lean and
> clean Lua -- your statement must be a joke.
> $end

Okay, I think Python, syntactically, it is easier to read and understand
(simpler). This is a major consideration of its design. But, cleaner well, maybe
that was rash! I'm coming out with my hands in the air! I was trying to imply
that Lua seems to try and emulate other language features but doesnt always do
so in a consistent or nice way ie. I see the foreach functionality as a bodge -
but to the credit of the designers they are fixing this. I think it is good that
the designers are staying focussed on Luas strengths eg. speed, flexibility,
size.

N



Reply | Threaded
Open this post in threaded view
|

RE: Python and Lua

Ashley Fryer-2
> -----Original Message-----
> From: [hidden email] [[hidden email]
> Behalf Of Nick Trout
> Sent: Thursday, April 20, 2000 3:40 AM

> You have more choice with Lua, that is its strength.
> Python's is that the
> functionality is there and users concentrate on modules and
> extension libraries
> hence further increasing its "usefulness".

I admit this is an area where I'm jealous of Python!  It has a very nice
collection of libraries for image manipulation, ftp, www, tkinter, etc.  I
think many people decide to use Python because of the libraries.

So, why do those libraries exist for Python but not for Lua?

Theories:

* Python supports "import" semantics, thus encouraging libraries.

* From its early history, libraries were published for Python.  The early
contributions encouraged later contributions.

* Marketing... Lua is marketed mainly as an extension language, Python
mainly as a standalone scripting language, so Python naturally attracts more
extension libraries.

* User base.  Python has more users ( I think ), therefore it has more
libraries.

* Libraries are platform dependent, thus harder to propogate.  This explains
why Lua _doesn't_ have more librares, but Python has this problem too.  How
come Python overcame it but Lua didn't?

It would be nice to overcome this obstacle to broader acceptance of Lua.

Thoughts?

ashley


12