stdlua.lua

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

stdlua.lua

Erik Hougaard
I would like to propose a standard lua library. Written in Lua. This library
should hold a series of well-defined, offen used functions. The purpose of
the stdlua is to create a common library that will improve the expirence of
programming in Lua and will help people exchanging source code.

The library could also be a good starting point for new users trying to
learn Lua.

How to include:
dofile("stdlua.lua")

stdlua.lua should only expose a single global variable "stdlua" and all
functions should be members in stdlua.

Example of function that could be part of stdlua.lua:
clone()

www.lua-users.org could be the place for suggesting, validating and
maintaining the library. A primary maintainer should be appointed.

/erik



Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Reuben Thomas-4
> I would like to propose a standard lua library. Written in Lua. This library
> should hold a series of well-defined, offen used functions. The purpose of
> the stdlua is to create a common library that will improve the expirence of
> programming in Lua and will help people exchanging source code.
> 
> The library could also be a good starting point for new users trying to
> learn Lua.
> 
> How to include:
> dofile("stdlua.lua")
> 
> stdlua.lua should only expose a single global variable "stdlua" and all
> functions should be members in stdlua.
> 
> Example of function that could be part of stdlua.lua:
> clone()
> 
> www.lua-users.org could be the place for suggesting, validating and
> maintaining the library. A primary maintainer should be appointed.

I think this is an excellent idea. It would be even better if this
could be part of the distribution, but initially it's a better idea to
"shake down" a first version.

In any case, the time is certainly ripe to start such a library, so
that people such as myself who use Lua mainly for scripting don't have
to keep reinventing the wheel. It's been pointed out several times
that Lua lacks the framework of Perl, Python or Ruby, and Lua could
actually be a very strong contender in the general scripting arena
(without compromising its original design goals) with better library
support.

On the other hand, it's still worth applying the same criteria of
simplicity and minimality to a library as to Lua itself: to my mind,
there's very little point having a Foo::Bar::Baz() routine that does
exactly what you want in a single line if there's an obvious way to do
the same thing in two or three lines with a much smaller and simpler
library.

I have already been delighted time and time again to find
that I can write scripts in Lua that are as short as or nearly as
short as the equivalent in Perl, despite the fact that the base
language and standard libraries are much smaller than Perl and its
standard libraries. Lua's beautifully sugared syntax, powerful tables,
brilliant string matching, first-class functions and extensible
semantics allow a lot of common scripting needs to be expressed
concisely without the sort of random "magic" you get in Perl.

I have a collection of a few tens of routines of my own that I'd be
happy to throw into the mix, as I'm sure many others do.

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

Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Erik Hougaard
----- Original Message -----
> I think this is an excellent idea. It would be even better if this
> could be part of the distribution, but initially it's a better idea to
> "shake down" a first version.

Well I'm sure that if we put together a great library, it would not be a
problem to distribute it with the distribution. Lots of other distrubtions
has a "3rdparty" directory.

/e


Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

James Hearn
In reply to this post by Erik Hougaard
> I would like to propose a standard lua library. Written in Lua. This
library
> should hold a series of well-defined, offen used functions. The purpose of
> the stdlua is to create a common library that will improve the expirence
of
> programming in Lua and will help people exchanging source code.
>
> The library could also be a good starting point for new users trying to
> learn Lua.
>
> How to include:
> dofile("stdlua.lua")
>
> stdlua.lua should only expose a single global variable "stdlua" and all
> functions should be members in stdlua.
>
> Example of function that could be part of stdlua.lua:
> clone()
>
> www.lua-users.org could be the place for suggesting, validating and
> maintaining the library. A primary maintainer should be appointed.
>
> /erik

I would also throw my support behind this idea. I know that I personally
would appreciate such a library for everyday use. And while I may not be a
new user, I certainly would appreciate the chance to see some well-written
Lua code to increase my understanding of the language.

--James Hearn

P.S [OT] - I just got a job integrating Lua into a research project at my
university! How cool is that? Getting *paid* to work with Lua!


Reply | Threaded
Open this post in threaded view
|

RE: stdlua.lua

Philippe Lhoste
In reply to this post by Erik Hougaard
> > I would like to propose a standard lua library. Written in Lua. 
> This library
> > should hold a series of well-defined, offen used functions. The 
> purpose of
> > the stdlua is to create a common library that will improve the 
> expirence of
> > programming in Lua and will help people exchanging source code.
> > 
> > The library could also be a good starting point for new users trying to
> > learn Lua.
> > 
> > How to include:
> > dofile("stdlua.lua")
> > 
> > stdlua.lua should only expose a single global variable "stdlua" and all
> > functions should be members in stdlua.
> > 
> > Example of function that could be part of stdlua.lua:
> > clone()
> > 
> > www.lua-users.org could be the place for suggesting, validating and
> > maintaining the library. A primary maintainer should be appointed.
> 
> I think this is an excellent idea. It would be even better if this
> could be part of the distribution, but initially it's a better idea to
> "shake down" a first version.
> 
> In any case, the time is certainly ripe to start such a library, so
> that people such as myself who use Lua mainly for scripting don't have
> to keep reinventing the wheel. It's been pointed out several times
> that Lua lacks the framework of Perl, Python or Ruby, and Lua could
> actually be a very strong contender in the general scripting arena
> (without compromising its original design goals) with better library
> support.
> 
> On the other hand, it's still worth applying the same criteria of
> simplicity and minimality to a library as to Lua itself: to my mind,
> there's very little point having a Foo::Bar::Baz() routine that does
> exactly what you want in a single line if there's an obvious way to do
> the same thing in two or three lines with a much smaller and simpler
> library.
> 
> I have already been delighted time and time again to find
> that I can write scripts in Lua that are as short as or nearly as
> short as the equivalent in Perl, despite the fact that the base
> language and standard libraries are much smaller than Perl and its
> standard libraries. Lua's beautifully sugared syntax, powerful tables,
> brilliant string matching, first-class functions and extensible
> semantics allow a lot of common scripting needs to be expressed
> concisely without the sort of random "magic" you get in Perl.
> 
> I have a collection of a few tens of routines of my own that I'd be
> happy to throw into the mix, as I'm sure many others do.

Excellent idea, I suppose a lot of people already have a toolbox of small
Lua snippets and utilities.
You should propose a base file, so we can start to throw in functions
respecting your specification.
I propose to start by putting, among other things, some routines from the
test folder (savevar is a good candidate), and lot of code from Roberto's book
(the DumpString, as I sent to the list, seems appropriate).

For the "obvious" code, taking only 2 or 3 lines, like the test/qp.lua
(convert quoted-printable encoded string), it should be put in a kind of FAQ or
snippet repository. The wiki is of course a good place for this.

PS.: [OT] I remember somebody posted an incorrect link to the bzip2 page
here. The correct one is: http://sources.redhat.com/bzip2/index.html
Easy to find with some searching, but easier if explicitely given :-)

Regards.

-- 
--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--

Sent through GMX FreeMail - http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Luiz Henrique de Figueiredo
>I would like to propose a standard lua library. Written in Lua.

This is a good idea, because as has been mentioned in previous posts, Lua does
lack wider library support for scripting.

Nevertheless, I suggest some other name be chosen to avoid confusion with the
"standard libraries" that come with Lua, that is liblualib.a in Unix-speak.

>How to include:
>dofile("stdlua.lua")
>
>stdlua.lua should only expose a single global variable "stdlua" and all
>functions should be members in stdlua.

I suggest a more flexible scheme: in stdlua.lua (or whatever the name is),
test whether a table called "stdlua" exists. If it does, then stdlua.lua should
define only those functions whose name appear in the table. In this way, users
can choose the functions they need.

Example:

stdlua={clone=1, strtrim=1}
dofile"stdlua.lua"

In "stdlua.lua":

local select=stdlua
local L=settag({},newtag())
settagmethod(tag(L),"settable", function (i,v)
  if not select or stdlua[i] then rawset(L,i,v) end
end)

function L.clone() ... end 
function L.strtrim() ... end 
function L.abort() ... end 

...

stdlua=L
return L

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

John Belmonte-2
> I suggest a more flexible scheme: in stdlua.lua (or whatever the
> name is), test whether a table called "stdlua" exists. If it does,
> then stdlua.lua should define only those functions whose name
> appear in the table. In this way, users can choose the functions
> they need.

I'm not sure how useful this will be in practice.  Is the point to shave
bytecodes?  Maybe it's not an issue for the intended audience.  Furthermore
in utility libraries I've written, functions often have interdependencies.
Allowing the user such control may break things depending on the
implementation.

-John



Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Erik Hougaard
In reply to this post by Luiz Henrique de Figueiredo
----- Original Message -----
> Nevertheless, I suggest some other name be chosen to avoid confusion with
the
> "standard libraries" that come with Lua, that is liblualib.a in
Unix-speak.

This should be the easies part, and will properly prove to be the hardest
:-)
Suggestions:
stdlua
sfl
stdlib
... Short and simple, thats the important parts.

> I suggest a more flexible scheme: in stdlua.lua (or whatever the name is),
> test whether a table called "stdlua" exists. If it does, then stdlua.lua
should
> define only those functions whose name appear in the table. In this way,
users
> can choose the functions they need.

This would work also, what I belive is important is the single line include
thing.. So if you just need some utility function just
dofile("thefinalname.lua") and you have all functions. If you want to
control what functions you get (power-users) you can choose to do so.

I think its very important to keep it simple. People should be able to use
it with the (wrong) knowlegde they have from other languages.. Example:

dofile("stdlua.lua")
Jack = stdlua.clone(William)

But if a poweruser wants to reduce exported functions he could do:

stdlua = {clone=1}
dofile("stdlua.lua")
Jack = stdlua.clone(William)

/erik


Reply | Threaded
Open this post in threaded view
|

RE: stdlua.lua

Philippe Lhoste
In reply to this post by Luiz Henrique de Figueiredo
> > I suggest a more flexible scheme: in stdlua.lua (or whatever the
> > name is), test whether a table called "stdlua" exists. If it does,
> > then stdlua.lua should define only those functions whose name
> > appear in the table. In this way, users can choose the functions
> > they need.
> 
> I'm not sure how useful this will be in practice.  Is the point to shave
> bytecodes?  Maybe it's not an issue for the intended audience.  
> Furthermore
> in utility libraries I've written, functions often have interdependencies.
> Allowing the user such control may break things depending on the
> implementation.

I may seem to cut hairs in four parts (as we say in French: "Couper des
cheveux en quatre"), by the length of course, but shaving bytecodes can be quite
hairy...
Sorry, I couldn't resist for the (bad) pun. I just come out of the
haircutter...

OK, more seriously, you are quite right.
Now, if this idea have some success, it can be necessary, some day, to break
the file in parts. A generic one, that can be used by various functions, a
file I/O one, a string one, an encoding/decoding one, etc.

Perhaps a generic file will load the required libraries, based on a table,
in a similar idea to Luiz' one.

I am not sure if it is a good idea: how to break down the file? What about
dependencies, as you indicate? We can force a dofile to be sure to have
required functions, but I wonder what happens if a.lua has a dofile("b.lua") and
b.lua has a dofile("a.lua")...
Anyway, the idea of loading a 100KB file to be able to dump a table for
debugging isn't so terrific either...

I can always cut/paste the code, but:
1) It will be frozen, ie. updates are quite hard to do, even more if used in
several scripts. At least, we can be sure it won't be broken by a hazardous
change...
2) We lose the interest of such a file, where we just have to type a line to
get a much used functionality.

Regards.

-- 
--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--

Sent through GMX FreeMail - http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

David Jones
In reply to this post by Luiz Henrique de Figueiredo
In message <200109271233.JAA22228@...>, Luiz Henrique d
e Figueiredo writes:
> >How to include:
> >dofile("stdlua.lua")
> >
> >stdlua.lua should only expose a single global variable "stdlua" and all
> >functions should be members in stdlua.
> 
> I suggest a more flexible scheme: in stdlua.lua (or whatever the name is),
> test whether a table called "stdlua" exists. If it does, then stdlua.lua shou
>>ld
> define only those functions whose name appear in the table. In this way, user
>>s
> can choose the functions they need.

Why not have spong.lua return an anonymous table.  Callers can then pull
out whatever functions they need or simple assign the table to the
variable spong.

drj

Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Reuben Thomas-4
In reply to this post by Philippe Lhoste
> Excellent idea, I suppose a lot of people already have a toolbox of small
> Lua snippets and utilities.

The process could go something like this:

1. Assemble a large file that is simply catted together from whatever
   people submit.

2. Someone (or people) can sort (or filter) it into categories: text
   processing, data structures &c.

3. As a result, we hopefully obtain a series of modules.

Ideas about naming:

1. Have a hierarchic name space.

2. Call the top of the hierarchy "std".

3. (Possibly contentious): I think it's worth adding a function so
   that you can allow bits of the hierarchy to be included in a
   natural way:

import("std") -- get the whole thing; the easy option for most scripts
import("std.data") -- get the data structures routines
import("std.io.socket.tcp") -- if you're being disciplined, and
-- perhaps developing a large project, it might be nice to import at a
-- fine granularity

It might be nice to be able to say

open("std.io.socket.tcp") too, to lift a namespace to the top level,
in a particular module.

You could set things up so that require("std") also gets the whole
thing (i.e. you don't need import).

Without getting too far off track, one useful thing this library
scheme could add to the base Lua system is the ability to bind Lua
libraries into a system in the same way as C libraries, so it's
available at startup; then, the entirety of "std" could be made
available by default (since it would all be under the "std" table,
this shouldn't be a problem). This would allow us to make standard
library available more easily (no need to load it) and flexibly (use
new functions like "import" and "open" without having to write them in
C).

> You should propose a base file, so we can start to throw in functions
> respecting your specification.

I've uploaded my util library (which James Hearn pointed out my GetOpt
library needed in any case) to the Lua-Users Wiki, and have started a
StandardLibraryProposal page.

> I propose to start by putting, among other things, some routines
> from the test folder (savevar is a good candidate), and lot of code
> from Roberto's book (the DumpString, as I sent to the list, seems
> appropriate).

Seems good.

> For the "obvious" code, taking only 2 or 3 lines, like the
> test/qp.lua (convert quoted-printable encoded string), it should be
> put in a kind of FAQ or snippet repository. The wiki is of course a
> good place for this.

I think the "obvious" code should be included in the library; no point
in having to work out 2 or 3 lines if it can be encapsulated as a
useful and reusable function.

-- 
http://sc3d.org/rrt/ | egrep, n.  a bird that debugs bison

Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Erik Hougaard
We should also think about documentation of the library functions. Each
function must be well documented and there should a simple example to each
function.

/e




Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

James Hearn
In reply to this post by Reuben Thomas-4
Sounds promising. Also - just over 4 hours from suggestion to starting work
on this idea! Impressive!

Go lua-users!

--James Hearn


Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Reuben Thomas-4
In reply to this post by Erik Hougaard
> We should also think about documentation of the library functions. Each
> function must be well documented and there should a simple example to each
> function.

I meant to say: each function should be LuaDoc documented (this
guarantees a good minimum documentation of inputs and outputs, and
gives the opportunity to write more). I've documented my utils in a
LuaDoc-compatible manner (without the proper tags at the moment, but
in the same structure).

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

Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Nick Trout-2
In reply to this post by John Belmonte-2
| > I suggest a more flexible scheme: in stdlua.lua (or whatever the
| > name is), test whether a table called "stdlua" exists. If it does,
| > then stdlua.lua should define only those functions whose name
| > appear in the table. In this way, users can choose the functions
| > they need.
|
| I'm not sure how useful this will be in practice.  Is the point to shave
| bytecodes?  Maybe it's not an issue for the intended audience.  Furthermore
| in utility libraries I've written, functions often have interdependencies.
| Allowing the user such control may break things depending on the
| implementation.

What about a library database type thing from which you import the code and then
execute it. eg. a library file could be formatted into sections (perhaps with
dependencies) and then sections read out of it, and executed. This would also
allow you to export just the bits you want for your particular project. There
would be a small overhead for parsing the "library database". The tool that
parses it might also strip out and create the docs and run a test suite? Just an
idea.



Reply | Threaded
Open this post in threaded view
|

Re: stdlua.lua

Luiz Henrique de Figueiredo
In reply to this post by Erik Hougaard
>What about a library database type thing from which you import the code and then
>execute it. eg. a library file could be formatted into sections (perhaps with

My gdbm binding contains a sample implementation of a repository of precompiled
code which might be useful for this. (Precompiling part is not essential.)
--lhf