Virgin tables

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

Re: Standard libraries (was Re: Virgin tables)

Greg Falcon
> I quite like the proposed array interface (and might end up just
> implementing it in a library of my own), though array(...) somewhat
> irks me - wouldn't array{...} be much more efficient in most cases?

Part of the point here is to support "holes".  You want
   array(nil, nil, nil)
to make a three-element array containing all nils.  Compare to
   array{nil, nil, nil}
which can't possibly be made to work.

Greg F

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Mark Hamburg
In reply to this post by Rena
On Dec 30, 2010, at 12:17 PM, HyperHacker wrote:

> I quite like the proposed array interface (and might end up just
> implementing it in a library of my own), though array(...) somewhat
> irks me - wouldn't array{...} be much more efficient in most cases?
> You might provide a check (which can be toggled by something like
> array.debug.ValidateInput = true if performance is a concern) that the
> table can be used as an array (no holes or non-numeric args).
>
> Of course, one great thing about Lua is that it could support both by
> checking if the first parameter is a table... unless of course you
> wanted to construct an array of tables. (Maybe if first param is table
> and no additional params?)

I thought about taking a table instead of varargs and opted for varargs because:

* It avoids worrying about needing a table that hasn't been modified elsewhere.

* It avoids worrying about tables that don't look like arrays.

* It makes the length well-defined even in the presence of holes -- e.g., it works with varargs as array( ... ) in a way that array{ ... } would not.

* It makes it easy to create arrays of objects (which are often going to be made of tables).

* The cost didn't seem to be that high -- either the client creates the table or the library does and I didn't have an example in mind for where the client would be likely to carry around a table for a while and then want to turn it into an array.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Dirk Laurie
In reply to this post by Greg Falcon
On Thu, Dec 30, 2010 at 07:25:39PM +0200, Greg Falcon wrote:

> On Thu, Dec 30, 2010 at 11:46 AM, Dirk Laurie <[hidden email]> wrote:
> > Standard table functions don't destroy the pristine property
> > and updating (b) is trivial.
>
> This is incorrect.  For array t={1,2,3}, both
>   table.insert(t, 1, nil)
> and
>   table.insert(t, -42, 'x')
> destroy your "pristine" property.
>
You shock me.

The reference manual says:

    Most functions in the table library assume that the table
    represents an array or a list.
...
and under 'insert',
    shifting up other elements to open space, if necessary.

In both your examples, I can't see why it is necessary to shift
up the other elements, since there should be no distinction
between t[1]=nil and t[1] absent.

Thus, these examples expose what one could describe charitably
as unintended behaviour of table.insert.

Even so, in both cases, the loss of pristineness can be diagnosed
in O(1) time, so this detail does not destroy my argument.

Dirk


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Dirk Laurie
In reply to this post by Greg Falcon
On Thu, Dec 30, 2010 at 10:25:22PM +0200, Greg Falcon wrote:
>
> Part of the point here is to support "holes".  You want
>    array(nil, nil, nil)
> to make a three-element array containing all nils.  
Your own post, fifteen minutes later, says that the real problem
is that people can't accept that nil is not a first-class value,
and that if one tried making it into that, the result would be
very different from Lua.

I agree with Greg II, not with Greg I.

Dirk




Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Greg Falcon
On Thu, Dec 30, 2010 at 4:16 PM, Dirk Laurie <[hidden email]> wrote:

> On Thu, Dec 30, 2010 at 10:25:22PM +0200, Greg Falcon wrote:
>>
>> Part of the point here is to support "holes".  You want
>>    array(nil, nil, nil)
>> to make a three-element array containing all nils.
> Your own post, fifteen minutes later, says that the real problem
> is that people can't accept that nil is not a first-class value,
> and that if one tried making it into that, the result would be
> very different from Lua.
>
> I agree with Greg II, not with Greg I.

This will be my last reply, because this thread is generating a crazy
amount of heat.  I should have stayed out of it entirely.  But if you
actually read my message in question, you would have seen:

"Lorenzo Donati got it exactly right -- if you want an
array-with-holes, build one out of tables and metamethods."

Here Mark Hamburg is proposing an API for an array-with-holes built
out of tables and metamethods.  I can't for the life of me figure out
why you think my discussing how it should support nil is in any way
inconsistent or contradictory.

Have fun,
Greg F

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Dirk Laurie
On Thu, Dec 30, 2010 at 11:34:44PM +0200, Greg Falcon wrote:
> But if you actually read my message in question, you would have seen:
>
> "Lorenzo Donati got it exactly right -- if you want an
> array-with-holes, build one out of tables and metamethods."
>
I saw that, and agree with it.  In fact, in general I think that
do-it-yourself using existing tools is the solution to 99.9 per
cent of the things people want Lua to be changed into doing.

> Here Mark Hamburg is proposing an API for an array-with-holes built
> out of tables and metamethods.  I can't for the life of me figure out
> why you think my discussing how it should support nil is in any way
> inconsistent or contradictory.
>
Whatever.  Let's rather focus on what we agree on.  Such as your
conclusion in the later message:
| Or you could try to make nil first-class, but that's a broad change
| with major and sweeping implications.  The end result would look like
| quite a different language than what we have today!

Dirk


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Javier Guerra Giraldez
On Thu, Dec 30, 2010 at 5:21 PM, Dirk Laurie <[hidden email]> wrote:
> I think that
> do-it-yourself using existing tools is the solution to 99.9 per
> cent of the things people want Lua to be changed into doing.

+1

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Axel Kittenberger
In reply to this post by Dirk Laurie
> I saw that, and agree with it.  In fact, in general I think that
> do-it-yourself using existing tools is the solution to 99.9 per
> cent of the things people want Lua to be changed into doing.

Honestly, this is a strawman-argument.

Meaning, you are creating a strawman of an argument to shoot that one
down. No one ever said you cannot do these things with Lua. The
argument is if a) about speed, that some things are faster when done
in core, like the "was always strict linear" flag, or b) a hugh
pitfall even on this very List I see again and again people fall for
it, in an otherwise so userfriendly language that starts arrays even
with 1.

If I take your strawman seriously, lets just remove # completly from
Lua, since its 2 functions: to count itself to a list, and
table.insert() can easily be done by a do-it-yourself using existing
tools.

Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Roberto Ierusalimschy
In reply to this post by KHMan
> On 12/31/2010 2:39 AM, Greg Falcon wrote:
> >On Thu, Dec 30, 2010 at 12:56 AM, Dirk Laurie wrote:
> >>All the trouble people have with the table length function and
> >>the table library, well over 100 posts by now, come down to one
> >>thing, and one thing only:
> >>
> >>    The functions designed for use on tables without holes
> >>    don't actually give an error message when applied to
> >>    tables with holes.
> >
> >I disagree with this assessment.  In Lua, nil isn't truly a
> >first-class object, because it can't be stored in tables at all,
> >either as a key or a value.  The real problem, as I see it, is the
> >widespread refusal to accept this fact.
> >[snip]
>
> Two thumbs up from me for the whole post. :-) Obliged to give this
> some show of support. Having said that, I'll quickly disappear from
> this thread now...

I make your words mine.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

kevin beckford
In reply to this post by Axel Kittenberger
What an odd thread.

You do not need standard libraries like Python, you need  a "Lua
Cookbook" like Perl's  "Perl Cookbook", and even then "Programming in
Lua"  is quite helpful with that sort of thing.

"Do-it-yourself":  Good for learning, but automation and abstraction
are always welcome.

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Dac Chartrand
On 2011-01-01, at 1:03 PM, kevin beckford wrote:

> [...] you need  a "Lua Cookbook" like Perl's  "Perl Cookbook",

This would be great.

I have both Perl and PHP Cookbooks. Flamewars aside, these are invaluable resources. The style in the way both these books are written is great. Theory is covered, but practical solutions to everyday problems emphasized.

I am new to Lua (using it to script Renoise) and find it very elegant. A few hurdles to overcome, obviously. But this could easily be the same for anyone who learns Lua first ,then tries Perl or PHP. If a Lua Cookbook in the same style as the above O'Reilly  classics existed, I would buy it immediately. I own "Programming in Lua, 2nd Edition" and it's OK, but there is something to be said about the cookbook format.

Regards,

--
http://www.renoise.com/
Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

David Manura
On Sat, Jan 1, 2011 at 1:42 PM, Dac Chartrand <[hidden email]> wrote:
> On 2011-01-01, at 1:03 PM, kevin beckford wrote:
>> [...] you need  a "Lua Cookbook" like Perl's  "Perl Cookbook",
> This would be great.  [...] If a Lua Cookbook in the same style as the above O'Reilly
> classics existed, I would buy it immediately. I own "Programming in Lua, 2nd
> Edition" and it's OK, but there is something to be said about the cookbook format.

Some of the more topic orientated wiki pages somewhat mirror this
style, although abbreviated.  For example, [1] and [2] kind-of mirror
Chapter 1 "Strings" and Chapter 3 "Dates and Times" of the Perl
Cookbook.

There's also the Lua Gems book, but that's not fully in the same mold.
 Everyday Perl Cookbook topics like "inverting a hash" or "difference
of two dates" are not the type of sections you see in gems.

In terms of books, I personally think it may be useful for someone to
write a comprehensive book on the internals of the VM
implementation(s) and patching techniques [3,4].

[1] http://lua-users.org/wiki/StringRecipes
[2] http://lua-users.org/wiki/DateAndTime
[3] http://lua-users.org/lists/lua-l/2007-09/msg00051.html
[4] http://lua-users.org/lists/lua-l/2008-03/msg00118.html

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Dac Chartrand

On 2011-01-01, at 3:01 PM, David Manura wrote:

> There's also the Lua Gems book, but that's not fully in the same mold.

Ok, I just glanced Lua Gems TOC for the first time. Thanks for the tip.

I avoided this book because I thought it was something like Ruby Gems, a package manager for libraries. (like CPAN in Perl, or PECL/PEAR in PHP)

For my purposes, I only want "Lua standard" and I thought "Gems" would confuse that goal.

Maybe there's something to be said about looking on the other side of the fence before naming things? Optionally, cookbook is a good word. Heh.

Regards,

--
http://www.renoise.com/








 





Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Chris Babcock
In reply to this post by kevin beckford
On Sat, Jan 1, 2011 at 11:03 AM, kevin beckford <[hidden email]> wrote:
> You do not need standard libraries like Python, you need  a "Lua
> Cookbook" like Perl's  "Perl Cookbook", and even then "Programming in
> Lua"  is quite helpful with that sort of thing.
>
> "Do-it-yourself":  Good for learning, but automation and abstraction
> are always welcome.

I've scripted an SMTP dialog before... There are some things you do
not want to learn. :)

Something like a standard library is necessary for a cookbook. You
can't create a recipe for "How-to use Lua with Protocol X" without
either a recognized abstraction layer for Protocol X or so much domain
specific knowledge that the cookbook becomes a ten volume set.

I honestly don't understand the resistance to a standard library. This
is a requirement for Lua to be competitive as a mainstream language,
but the people who would use this facility understand that Lua is a
scripting language and an embedding language first. The qualities that
make Lua appropriate for those applications also make it a desirable
language for the applications that require this kind of abstraction
layer. Those who want a standard library are generally talking about
comparatively high level code that isn't going to have much impact on
those applications or even compete much with them for developer time.

I think the problem is that the Lua maintainers are too successful at
maintaining the illusion that the feature set of Lua is responsive to
democratic process. There's an irrational fear that the 'ballot box'
will be stuffed with feature requests from former Pythonistas who,
like a plague of Calfornians, bring with them the causes of the taxes
they are fleeing. We need to get past that somehow.

My friend Henning quoting me in his appeal for a core change was
singularly unhelpful. Thanks, dude - not. :)

Chris
--
51st century guy

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Sean Conner
It was thus said that the Great Chris Babcock once stated:

> On Sat, Jan 1, 2011 at 11:03 AM, kevin beckford <[hidden email]> wrote:
> > You do not need standard libraries like Python, you need  a "Lua
> > Cookbook" like Perl's  "Perl Cookbook", and even then "Programming in
> > Lua"  is quite helpful with that sort of thing.
> >
> > "Do-it-yourself":  Good for learning, but automation and abstraction
> > are always welcome.
>
> I've scripted an SMTP dialog before... There are some things you do
> not want to learn. :)

  I never fond SMTP to be that difficult myself (this from someone who has
hacked sendmail.cf, so your milage may vary).

> Something like a standard library is necessary for a cookbook. You
> can't create a recipe for "How-to use Lua with Protocol X" without
> either a recognized abstraction layer for Protocol X or so much domain
> specific knowledge that the cookbook becomes a ten volume set.
>
> I honestly don't understand the resistance to a standard library.

  Where do you stop?  At the minimal end, you have Lua (where we are now).
At the other end you have Perl + all of CPAN (or maybe Java now that I think
about it).  And what's useful *now* doesn't mean it's useful *later*---just
look at Common Lisp.  Huge function set, but lacks a lot of functionality
that's now considered *standard* like threads, sockets and XML/JSON support,
but didn't even exist (or wasn't in widespread use) when the standard was
created.

> This
> is a requirement for Lua to be competitive as a mainstream language,

  Is Lua a mainstream language?  Do the creators consider Lua a mainstream
language?  Is that even a goal for Lua?

> Those who want a standard library are generally talking about
> comparatively high level code that isn't going to have much impact on
> those applications or even compete much with them for developer time.

  The one syslog interface in Lua I found didn't offer the appropriate
functionality I wanted (for instance, hard coded paramters to the C function
openlog(); took only numeric constants for the levels instead of a string,
etc).  The getopt functions I found were also lacking.  That's another issue
with a "standard" library---they require *very* careful planning or they're
annoying to use.  

> I think the problem is that the Lua maintainers are too successful at
> maintaining the illusion that the feature set of Lua is responsive to
> democratic process. There's an irrational fear that the 'ballot box'
> will be stuffed with feature requests from former Pythonistas who,
> like a plague of Calfornians, bring with them the causes of the taxes
> they are fleeing. We need to get past that somehow.

  Anybody that uses Microsoft Word on average uses only 20% of the features.
The problem is---that 20% is different from person to person, and thus, you
end up with a bloated application.  

  I like Lua *precicely* becuase it doesn't have a bloated standard library,
and for features that are missing, I've been able to find bindings or create
my own.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Axel Kittenberger
IMHO there is no problem with someone stepping up and doing some
"standard" library. I dont even see the problems with multiple
efforts, as long they dont .debug hack the metalibs of string or nil
or so. One applaudable effort is penlight. Personally I wonder if this
strong focus to Python-like is a good idea, but this is just a far
away general consideration, nothing I could now prove close up. The
Lua core team has not to worry much about it, or?

So what would you expect from a standard library?

On Sat, Jan 1, 2011 at 11:58 PM, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Chris Babcock once stated:
>> On Sat, Jan 1, 2011 at 11:03 AM, kevin beckford <[hidden email]> wrote:
>> > You do not need standard libraries like Python, you need  a "Lua
>> > Cookbook" like Perl's  "Perl Cookbook", and even then "Programming in
>> > Lua"  is quite helpful with that sort of thing.
>> >
>> > "Do-it-yourself":  Good for learning, but automation and abstraction
>> > are always welcome.
>>
>> I've scripted an SMTP dialog before... There are some things you do
>> not want to learn. :)
>
>  I never fond SMTP to be that difficult myself (this from someone who has
> hacked sendmail.cf, so your milage may vary).
>
>> Something like a standard library is necessary for a cookbook. You
>> can't create a recipe for "How-to use Lua with Protocol X" without
>> either a recognized abstraction layer for Protocol X or so much domain
>> specific knowledge that the cookbook becomes a ten volume set.
>>
>> I honestly don't understand the resistance to a standard library.
>
>  Where do you stop?  At the minimal end, you have Lua (where we are now).
> At the other end you have Perl + all of CPAN (or maybe Java now that I think
> about it).  And what's useful *now* doesn't mean it's useful *later*---just
> look at Common Lisp.  Huge function set, but lacks a lot of functionality
> that's now considered *standard* like threads, sockets and XML/JSON support,
> but didn't even exist (or wasn't in widespread use) when the standard was
> created.
>
>> This
>> is a requirement for Lua to be competitive as a mainstream language,
>
>  Is Lua a mainstream language?  Do the creators consider Lua a mainstream
> language?  Is that even a goal for Lua?
>
>> Those who want a standard library are generally talking about
>> comparatively high level code that isn't going to have much impact on
>> those applications or even compete much with them for developer time.
>
>  The one syslog interface in Lua I found didn't offer the appropriate
> functionality I wanted (for instance, hard coded paramters to the C function
> openlog(); took only numeric constants for the levels instead of a string,
> etc).  The getopt functions I found were also lacking.  That's another issue
> with a "standard" library---they require *very* careful planning or they're
> annoying to use.
>
>> I think the problem is that the Lua maintainers are too successful at
>> maintaining the illusion that the feature set of Lua is responsive to
>> democratic process. There's an irrational fear that the 'ballot box'
>> will be stuffed with feature requests from former Pythonistas who,
>> like a plague of Calfornians, bring with them the causes of the taxes
>> they are fleeing. We need to get past that somehow.
>
>  Anybody that uses Microsoft Word on average uses only 20% of the features.
> The problem is---that 20% is different from person to person, and thus, you
> end up with a bloated application.
>
>  I like Lua *precicely* becuase it doesn't have a bloated standard library,
> and for features that are missing, I've been able to find bindings or create
> my own.
>
>  -spc
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Chris Babcock
In reply to this post by Sean Conner

On Saturday, January 1, 2011, Sean Conner <[hidden email]> wrote:
> It was thus said that the Great Chris Babcock once stated:
>> On Sat, Jan 1, 2011 at 11:03 AM, kevin beckford <[hidden email]> wrote:
>> > You do not need standard libraries like Python, you need  a "Lua
>> > Cookbook" like Perl's  "Perl Cookbook", and even then "Programming in
>> > Lua"  is quite helpful with that sort of thing.
>> >
>> > "Do-it-yourself":  Good for learning, but automation and abstraction
>> > are always welcome.
>>
>> I've scripted an SMTP dialog before... There are some things you do
>> not want to learn. :)
>
>  I never fond SMTP to be that difficult myself (this from someone who has
> hacked sendmail.cf, so your milage may vary).

I prefer Postfix, myself, but the problem isn't whether SMTP is or isn't difficult, but whether everyone who uses it in Lua is going to have their own buggy half implementation.

>> Something like a standard library is necessary for a cookbook. You
>> can't create a recipe for "How-to use Lua with Protocol X" without
>> either a recognized abstraction layer for Protocol X or so much domain
>> specific knowledge that the cookbook becomes a ten volume set.
>>
>> I honestly don't understand the resistance to a standard library.
>
>  Where do you stop?  At the minimal end, you have Lua (where we are now).
> At the other end you have Perl + all of CPAN (or maybe Java now that I think
> about it).  And what's useful *now* doesn't mean it's useful *later*---just
> look at Common Lisp.  Huge function set, but lacks a lot of functionality
> that's now considered *standard* like threads, sockets and XML/JSON support,
> but didn't even exist (or wasn't in widespread use) when the standard was
> created.

You stop where the will to maintain it stops. Just don't sap that will by joining the "how can we do this" discussion with the "why do you want to" argument. I understand that's not your use case for the language. If the discussion dies on its own then I need to choose between spending more time on development or more money on hardware. If there's a product from this discussion then you'll have to ignore questions about the standard library. (Which, I'll say again, I think is a misnomer for our purposes.)

>> This
>> is a requirement for Lua to be competitive as a mainstream language,
>
>  Is Lua a mainstream language?  Do the creators consider Lua a mainstream
> language?  Is that even a goal for Lua?

This isn't constitutional law. The street finds its own uses. I may or may not be able to make a case on the basis of what code they've published, but I think I'll wait until they're gone before I risk speaking to their intentions.

>> Those who want a standard library are generally talking about
>> comparatively high level code that isn't going to have much impact on
>> those applications or even compete much with them for developer time.
>
>  The one syslog interface in Lua I found didn't offer the appropriate
> functionality I wanted (for instance, hard coded paramters to the C function
> openlog(); took only numeric constants for the levels instead of a string,
> etc).  The getopt functions I found were also lacking.  That's another issue
> with a "standard" library---they require *very* careful planning or they're
> annoying to use.

I don't think it has to be quite that top down.

>> I think the problem is that the Lua maintainers are too successful at
>> maintaining the illusion that the feature set of Lua is responsive to
>> democratic process. There's an irrational fear that the 'ballot box'
>> will be stuffed with feature requests from former Pythonistas who,
>> like a plague of Calfornians, bring with them the causes of the taxes
>> they are fleeing. We need to get past that somehow.
>
>  Anybody that uses Microsoft Word on average uses only 20% of the features.
> The problem is---that 20% is different from person to person, and thus, you
> end up with a bloated application.
>
>  I like Lua *precicely* becuase it doesn't have a bloated standard library,
> and for features that are missing, I've been able to find bindings or create
> my own.
>
>  -spc

Except to use Microsoft Word, you have to have the whole thing. There's no reason to do that here.

Chris

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

steve donovan
In reply to this post by kevin beckford
On Sat, Jan 1, 2011 at 8:03 PM, kevin beckford <[hidden email]> wrote:
> You do not need standard libraries like Python, you need  a "Lua
> Cookbook" like Perl's  "Perl Cookbook",

A cookbook would be a fantastic thing, especially if we got a little
gang together to write it and spread the workload.  In the meantime,
the wiki continues to be a good place to keep little articles, and I
hope to revive the snippets/recipes site soon.

You don't need a 'standard' library[1], yes, but you do need to show
how to use library code. As Chris says, how to work with a protocol is
a natural topic for a cookbook, but nasty without the right library.

steve d.

[1] 'standard' is not the right word, because www.lua.org will not
endorse it. And life is too short for yet another ISO committee ;)

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Alexander Gladysh
On Sun, Jan 2, 2011 at 08:46, steve donovan <[hidden email]> wrote:
> On Sat, Jan 1, 2011 at 8:03 PM, kevin beckford <[hidden email]> wrote:
>> You do not need standard libraries like Python, you need  a "Lua
>> Cookbook" like Perl's  "Perl Cookbook",

> A cookbook would be a fantastic thing, especially if we got a little
> gang together to write it and spread the workload.  In the meantime,
> the wiki continues to be a good place to keep little articles, and I
> hope to revive the snippets/recipes site soon.

I, maybe, can help with some recipes, especially on Sandboxing, DSL
and codegeneration.

As for the organization, I like the way ProGit book is done:

https://github.com/progit/progit

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Alexander Gladysh
On Sun, Jan 2, 2011 at 09:17, Alexander Gladysh <[hidden email]> wrote:
> On Sun, Jan 2, 2011 at 08:46, steve donovan <[hidden email]> wrote:
>> On Sat, Jan 1, 2011 at 8:03 PM, kevin beckford <[hidden email]> wrote:
>>> You do not need standard libraries like Python, you need  a "Lua
>>> Cookbook" like Perl's  "Perl Cookbook",

>> A cookbook would be a fantastic thing, especially if we got a little
>> gang together to write it and spread the workload.  In the meantime,
>> the wiki continues to be a good place to keep little articles, and I
>> hope to revive the snippets/recipes site soon.

> I, maybe, can help with some recipes, especially on Sandboxing, DSL
> and codegeneration.

Although these topics are, maybe, a bit too big for a cookbook format.

Anyway, one can start with a list of topics (maybe along with a way
for authors to commit for one or more and for potential readers to
express their interest). We can setup a project on GH and use its wiki
for this.

I like writing, and I'm due for some Lua articles for a long time, so
I'm willing to help. If I'll see a list of topics, I'll do a few where
I'll know what to write.

Anyone else want to step up? :-)

Alexander.

1234