Virgin tables

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

Re: Virgin tables

Lorenzo Donati-2
Luiz Henrique de Figueiredo wrote:
>> Has it been pointed out, if/why it would be costly to throw an error for
>> #t if a list t ever had holes?
>
> The message by uki before yours says it all: "there is absolutely no way to
> check if the table has holes, except by iterating through the whole table."
>
>
>
Things keep repeating here.
As a Lua newbie I was hit more than once by the unusual behaviour of
tables, but I kept learning and, keeping it simple, now I can avoid most
blunders most of the times.

I'm not saying that a more complex/feature-rich/safe data structure is
never needed, but, as I said some time ago in another thread (but I was
not the only one), maybe the problem with all this fuss over holes in
tables and the like is that most people seem to see Lua tables as an
high level data structure (some time ago I thought it too). Indeed they
are, if compared with basic data structure of most common languages
(C/C++ arrays, Java arrays, for example).
But in a Lua perspective, IMHO, tables are best viewed as a low-level
facility (even if very powerful), on which to build more
complex/safe/user-friendly data structures.

The fact that a newbie can do amazing things with tables doesn't mean
that they should be "idiotproof", as some Java data structures are (well
at least a more clever idiot enters the game :-) )

Since it is the only data structure of Lua, the balance between ease of
use, efficiency and readability attained is a benefit I wouldn't
forfait. And as I learned reading this list, Lua authors have spent
years to achieve that.

Instead of pushing for changing such a cleverly crafted aspect of the
language, I would really spend time in advocating a standard collection
of general-purpose library. I think that newbies (if they are the target
of this thread) would better be served by an "almost endorsed" library
with all the basic tools one usually find in other languages (say pure
arrays, maps, sets, string manipulation functions, etc.).

This would smooth considerably their learning curve. I think that for a
newbia is more frustrating to have the usual (on this mailing list)
reply "but you can do that with these two lines of Lua code..." followed
by some idiom that leaves one puzzled for a while (see tricks with 'gsub
' or 'match') (please don't beat me with a stick, I actually got to love
some of these tricks _now_ ;-) :-) )


Best Regards

--
Lorenzo

Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Axel Kittenberger
In reply to this post by Luiz Henrique de Figueiredo
IMHO "if ever had" instead of has is simply a bit you can set whenever
there is a non-linear insertion/omission.

t[3]=3, t[2]=2, t[1]=1

table.hadeverholes(t) --> true

also believe this will raise complaints, as some people sure rely on
#t to be defined 3 in this case.

I'm personally do no longer care what # results on non-lists, but my
impression of Lua presentation was to provide less easy to do
undefined behaviors (whereas in C they are very easy to do). And thus
I think any # that always results the same for the same set of keys
(no matter in in which way created) would be preferable, as many
non-expert coders try their Lua code out, and if it works they suppose
it will work anytime, not aware that the result of # on a non-list
might differ depending on the lua core, jit or nonjit, or phase of the
moon. On non-lists the one and only use of # I see is insertion. Its
great that table.insert uses it, but thats all there is to it.

On Thu, Dec 30, 2010 at 3:41 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> Has it been pointed out, if/why it would be costly to throw an error for
>> #t if a list t ever had holes?
>
> The message by uki before yours says it all: "there is absolutely no way to
> check if the table has holes, except by iterating through the whole table."
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Lorenzo Donati-2
In reply to this post by Lorenzo Donati-2
Lorenzo Donati wrote:
[snip]
> This would smooth considerably their learning curve. I think that for a
> newbia is more frustrating to have the usual (on this mailing list)
> reply "but you can do that with these two lines of Lua code..." followed
> by some idiom that leaves one puzzled for a while (see tricks with 'gsub
> ' or 'match') (please don't beat me with a stick, I actually got to love
> some of these tricks _now_ ;-) :-) )
>
And as for the names: virgin, holes, etc., well the adjective
'inappropriate' is an euphemism.

I know several female colleagues of mine who would rightfully beat with
a stick whoever forced them to use such idioms, even in a programming
environment.

--
Lorenzo


Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Mark Hamburg
In reply to this post by steve donovan
On Dec 30, 2010, at 12:28 AM, steve donovan wrote:

> On Thu, Dec 30, 2010 at 8:26 AM, Mark Hamburg <[hidden email]> wrote:
>> A simpler answer is to provide an array namespace....arrays have an explicit length (stored somewhere) and appropriate metamethods to maintain it.
>
> It's a question of using the appropriate data structure for the job.
> [1] is a reasonably robust array with bounds-checking, where setting
> nil is prohibited so that no holes can happen. It uses newproxy() to
> make the object so that the table functions cannot be used on it.

Ah. But I would have designed array specifically to allow holes while still having a length value that would satisfy those who want holes in their arrays.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Dirk Laurie
In reply to this post by Luiz Henrique de Figueiredo
On Thu, Dec 30, 2010 at 01:23:19PM +0200, Luiz Henrique de Figueiredo wrote:

> > *   It's an O(1) function.  Virginity is lost by t[k]=nil for
> >     k<#t and by t[k]=non_nil for k>#t+1, both easy to test.
>
> How is it O(1)? Do you have a sample implementation?
>
> > *   #t would be O(1) for all virgin tables.  (At present, many
> >     numeric entries may actually reside in the hash part of the
> >     table, and then #t takes O(log n) time.)
>
> Like I said before, full arrays can have part of their data stored
> in the hash part:
> http://lua-users.org/lists/lua-l/2010-12/msg00400.html
>

Since the term "virgin" seems to prevent the suggestion from
being taken seriously, I'll replace it by "pristine".

I am not proposing any change in the language, not even in the
meaning of #t.  I am only proposing the visibility of a flag
that would be useful to the implementation.

I assume that accessing a specific key in the hash part is O(1),
at least on average.

Keep two fields for every table:
(a) boolean - is the table pristine?
(b) number - if it is pristine, what is the largest numeric index?
    Equivalently, what is #t?  Otherwise, it does not matter,
    I suggest the most recent value returned for #t.

table.pristine(t) would simply return (a).
#t would for a pristine table simply return (b).  For other tables,
    it might check whether (b) still works, and if not, go through
    the present binary search.

Updating (a): once (a) is false, it stays that way.

__newindex:
While (a) is true, a hole is created by:
    1. Storing a nil at an index less than #t.
    2. Storing a non-nil at an index greater than #t+1.
Either of these is tested in O(1) time.
If no hole is created, (b) stays the same except when a nil
is stored at #t or a non-nil at #t+1.

Standard table functions don't destroy the pristine property
and updating (b) is trivial.

When a table constructor is scanned, we need to examine every
entry anyway.  In the process we count the number of distinct
positive integer indices and keep track of the highest such
index at O(1) operations per item.  If these are the same,
the table is pristine when constructed.  So even a constructor
like {[4]=4, [1]=1, [3]=3, [2]=2} can be recognized as giving a
pristine table.  Other indices are just ignored for this purpose.

Admittedly a table can lose the pristine property and later
return to having no holes, but this is fortuitous, and such
a table is not pristine.

Having the pristine flag available to the implementation
will save time for #t in the common cases where either the
table is pristine or the previous #t still works.

The proposed function table.pristine will enable code to check
array integrity.

Dirk


Reply | Threaded
Open this post in threaded view
|

Re: Sparse tables (was: Virgin tables)

Henning Diedrich
In reply to this post by Lorenzo Donati-2
On 12/30/10 4:40 PM, Lorenzo Donati wrote:
maybe the problem ... is that most people seem to see Lua tables as an high level data structure

I think that's an encouraged view.

That you can benefit so much from understanding the deeper level, combined with the elegance of the upper, is the shockingly great thing about Lua to me. An eye opener I think. But it works because both levels are that elegant.

Now the table is so intelligently designed underneath that the core principle that things make sense on both levels is violated by #. Maybe beyond a certain smartness that can't be avoided.

I know I will acquaint people with Lua and it will cost time and nerves and people will make that mistake. Or, worse, break code that otherwise ran using #, by inadvertently poking holes in tables, breaking #.

So throwing an error, even if people will complain about that one, too, and have a hard time to understand it, or protest it (e.g. for t[3]=3, t[2]=2, t[1]=1) would still be seconded. Even in the face of an unfortunate but minor performance loss. That's the toughest thing in my view.

Mind you, even if you got it a long time ago, if you ever lead a Lua project, the thing may still bite you badly, because somebody else in your team is falling in that trap. Even if you warned them. Or worse, two people messing each others' stuff up by it.

On 12/30/10 4:53 PM, Lorenzo Donati wrote:
And as for the names: virgin, holes, etc., well the adjective 'inappropriate' is an euphemism.

I know several female colleagues of mine who would rightfully beat with a stick whoever forced them to use such idioms, even in a programming environment.


Also for the religous, |holy == not virgin| won't do, so let's drop it already.

I would like to talk about [0] now.

Just kidding.
Henning
Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Greg Falcon
In reply to this post by Dirk Laurie
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.

Greg F

Reply | Threaded
Open this post in threaded view
|

Standard libraries (was Re: Virgin tables)

Mark Hamburg
In reply to this post by Lorenzo Donati-2
On Dec 30, 2010, at 7:40 AM, Lorenzo Donati wrote:

> I'm not saying that a more complex/feature-rich/safe data structure is never needed, but, as I said some time ago in another thread (but I was not the only one), maybe the problem with all this fuss over holes in tables and the like is that most people seem to see Lua tables as an high level data structure (some time ago I thought it too). Indeed they are, if compared with basic data structure of most common languages (C/C++ arrays, Java arrays, for example).
> But in a Lua perspective, IMHO, tables are best viewed as a low-level facility (even if very powerful), on which to build more complex/safe/user-friendly data structures.
>
> The fact that a newbie can do amazing things with tables doesn't mean that they should be "idiotproof", as some Java data structures are (well at least a more clever idiot enters the game :-) )
>
> Since it is the only data structure of Lua, the balance between ease of use, efficiency and readability attained is a benefit I wouldn't forfait. And as I learned reading this list, Lua authors have spent years to achieve that.
>
> Instead of pushing for changing such a cleverly crafted aspect of the language, I would really spend time in advocating a standard collection of general-purpose library. I think that newbies (if they are the target of this thread) would better be served by an "almost endorsed" library with all the basic tools one usually find in other languages (say pure arrays, maps, sets, string manipulation functions, etc.).
>
> This would smooth considerably their learning curve. I think that for a newbia is more frustrating to have the usual (on this mailing list) reply "but you can do that with these two lines of Lua code..." followed by some idiom that leaves one puzzled for a while (see tricks with 'gsub ' or 'match') (please don't beat me with a stick, I actually got to love some of these tricks _now_ ;-) :-) )

The more I think about it, the more I think the appropriate agenda here (if there is one) is not to change the behavior of Lua's core constructs (at least not initially), but to:

1. Define a set of standard higher-level constructs. I concur with Lorenzo that tables feel like high-level structures but they really are the CONS-cells of Lua -- i.e., the basic building blocks and highly-useful in themselves but "basic". So, start wrapping them up into high-level structures like arrays (which can be hole friendly), sets, etc..

2. Start encouraging use of these constructs.

3. While trying not to warp the language, start tuning the implementation and/or the language to make using such constructs clearer more efficient both from a textual standpoint and from a runtime standpoint. For example, "mySet[ x ]" is going to be a faster test for membership than "mySet:hasElement( x )" but it relies on the internal implementation of the set construct and won't work for sets that need to include nil or NaN. Can the implementation of Lua elide the runtime costs associated with the method dispatch (I'm pretty sure LuaJIT can)? Are there things that should be done syntactically to make this easier? For example, an __index metamethod could allow the syntax mySet[ x ] and could even work for nil and NaN, but then we get the wrong result when one wants to add the string "iterateElements" to the set assuming that sets have a method named "iterateElements". To make that work, we need to actually treat the colon operator as a real feature of the implementation (OP_SELF essentially makes it one anyway) rather than simply syntactic sugar.

Unfortunately, the process of defining standard libraries runs into the ground whenever it comes up. Since this seems to be beyond the scope of what the core Lua team wants to tackle, what would be good is if they could at least settle on some designated individual or two on whom they could apply some form of official blessing. This choice might be based in part on submitted proposals or code as opposed to simply blessing someone. But the point would be that the resulting libraries had been discussed within the Lua inner sanctum in addition to being discussed on more public forums like this list and through that they gained more specific approval and support.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Mark Hamburg
Having pushed for standard libraries, I do think that they should hold to a few principles:

1. They should be optional. You should be able to use Lua just like you can today at the "primitive" level of tables, etc.. In fact, they could enable Lua to get smaller by removing some functionality to optional additional libraries. Small languages with large mandatory class libraries are not simple or small even if the core language is simple.

2. There should be relatively few items in the standard libraries for similar reasons. This is not about adding batteries to Lua. This is about providing standard/recommended ways of dealing with some very common cases. The libraries might end up defining a style for other additions, but those should not lead to a big ball of mud even if it is optional.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

steve donovan
On Thu, Dec 30, 2010 at 8:13 PM, Mark Hamburg <[hidden email]> wrote:
> Having pushed for standard libraries, I do think that they should hold to a few principles:

Both of these principles are good starting places.  Naturally we've
been here before [1]. That thread was entertaining, because we could
not agree on what a standard map() function would look like, other
than the obvious point that it should take some sequence and create
another sequence by applying a function. 'sequence' is not a Lua term,
so we had various options - work on tables, work on iterators, etc.

I know the standard library itch, since scratching it produced
Penlight, which honestly is too eccentric to be a 'standard' library -
it is a collection of my favourite idioms.  But the motivation was to
make it easy to do easy things, and wrap up any magical bits so that
users of the libraries did not have to use magic for ordinary purposes
[2]

steve d.

[1] http://lua-users.org/lists/lua-l/2009-12/msg00644.html
[2] in the fantasy literature around magic, this is a common theme;
that magic should be used sparingly, if at all. Le Guin speaks of not
upsetting the balance, and Pratchett claims that actual cost of magic
is always more than you're prepared to spend.  In software terms, use
of magic adds to 'technical debt'.  Harry Potter would make a poor
software engineer, using magic to fix his glasses!

Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Greg Falcon
In reply to this post by Dirk Laurie
On Thu, Dec 30, 2010 at 12:56 AM, Dirk Laurie <[hidden email]> 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.

Now if you're only going to have a single data structure type in a
language, associative arrays are an excellent choice: they have nice
performance characteristics and are a powerful building block.  One
very useful set of keys are the positive integers, and Lua
acknowledges this with convenient syntax and optimized handling of
that use case.  But a table being used as an array is still a table
and still can't store nil.

The length operator's definition is nifty: no matter how tables are
implemented, the length can be efficiently calculated with an
unbounded binary search.  If you're using a table as an array, the
"length" matches your intuition.  If you're not, it doesn't, but don't
do that.

There have been complaints in these threads about the result of the
length operator not being deterministic -- that the same Lua code can
return different answers on different implementations -- but this is a
red herring.  The length operator could easily be made deterministic
by specifying precisely how the unbounded binary search must be
performed.  Then the answer would no longer be nondeterministic, but
it would still be *arbitrary*.  It still wouldn't be very useful for
non-array tables, and all of the complaints in these threads would
continue.

Lorenzo Donati got it exactly right -- if you want an
array-with-holes, build one out of tables and metamethods, just as you
would if you wanted a queue or a multiset or classes.  He's also right
that if there were a well-accepted common implementation of this, you
could point people to it and end these threads quickly.  What doesn't
feel wise to me is the plan of expanding the size of every table, and
increasing the performance cost of every table modification, just to
make # do something less confusing when you're using it on a non-array
table.

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!

Greg F

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Steve Litt
In reply to this post by Mark Hamburg
On Thursday 30 December 2010 13:13:45 Mark Hamburg wrote:
> Having pushed for standard libraries, I do think that they should hold to a
>  few principles:
>
> 1. They should be optional. You should be able to use Lua just like you can
>  today at the "primitive" level of tables, etc.. In fact, they could enable
>  Lua to get smaller by removing some functionality to optional additional
>  libraries. Small languages with large mandatory class libraries are not
>  simple or small even if the core language is simple.

I've used Lua only two weeks so what do I know, but I agree wholeheartedly
with Mark. The reason I like Lua so much is that you can do almost anything
with a very few features. Tables, with their "everything is a key value pair"
philosophy, make this such an understandable language, and I wouldn't want to
lose that or have to require something to get it.

There's been some discussion of #tab being wrong and maybe it should be fixed.
I haven't run across the need yet. In C or Pascal you use the equivalent of
#tab as an upper limit in a loop, but when you have pairs(), ipairs() and
next() this isn't necessary in that context. And if it ever becomes necessary,
the programmer can always add a table entry corresponding to the number of
entries, or the number of a certain kind of entries. Only in an incredibly
complex and versatile functionality would you need to know #tab on an
arbitrary table.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt


Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

KHMan
In reply to this post by Greg Falcon
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...

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Mark Hamburg
In reply to this post by Mark Hamburg
So, here is my rough proposal for an array type. No implementation provided at this time (because I tend to work from APIs to implementations rather than the other way arround).

a = array( ... )
        -- constructs an array with the provided var args elements
        -- the length of the array is equal to the length of the varargs

#a -- the length of the array

a[ idx ] = value
        -- idx must be a positive integer
        -- stores value at the given index
        -- adjusts the length to max( #a, idx )

a[ idx ]
        -- returns the value at the given index
        -- idx should be a positive integer.
        -- Q: Signal errors if idx is invalid or simply return nil? I'm inclined toward signaling errors.

a:insert( [ idx, ] value )
        -- inserts value at idx shifting values after idx rightward
        -- the length is adjusted to be equal to max( idx, #a + 1 )
        -- if idx is not supplied, it is taken to be #a + 1
        -- returns a

a:remove( [ idx ] )
        -- idx must be a positive integer
        -- returns a[ idx ] before adjustment
        -- if idx is less than or equal to #a, then the elements to the right of idx are shifted down and #a is decremented
        -- Note: This definition says it is acceptable to remove elements from off the end of the array. Should this instead throw an error?

a:sort( [ comp ] )
        -- Sort the elements in the array using the comparison function comp if supplied

a:ipairs()
        -- Returns an iterator for the array that returns elements of the form idx, value where the index values are increasing.

a:unpack()
        -- Evaluates to the contents of the array

array.test( a )
        -- Returns true if a is an array and false otherwise


array.check( a [, msg ] )
        -- Check that a is an array throwing an error (using msg in some way) if not

The array methods are stored in the table array -- the constructor is based on a __call metamethod -- and can be extended by extending this table. (I am not really fond of intermixing "class methods" likes array.test and array.check with instance methods, but I don't have a better proposal at this time.)

Net result:

arrays are just like tables except that they can have holes and those holes are accounted for in the length and they disallow non-array-like indices.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Mark Hamburg
On Dec 30, 2010, at 11:40 AM, Mark Hamburg wrote:

> array.test( a )
> -- Returns true if a is an array and false otherwise
>
>
> array.check( a [, msg ] )
> -- Check that a is an array throwing an error (using msg in some way) if not
>
> The array methods are stored in the table array -- the constructor is based on a __call metamethod -- and can be extended by extending this table. (I am not really fond of intermixing "class methods" likes array.test and array.check with instance methods, but I don't have a better proposal at this time.)

I'm going to amend that. Assume the introduction of a new additional module: types.

        types.test( array, a )
                -- returns a if a is an array. returns nil otherwise.

        types.check( array, a [ , msg ] )
                -- throws an error if a is not an array (using msg in some way if supplied). returns a otherwise.

        types.istypeerror( err )
                -- returns true if err is a message that could have been thrown by types.check

        types.register( key )
                -- throws if key has already been registered
                -- returns a weak table to hold values of the given type if it has not been registered

The implementation of array would therefore do the following:

        local types = require "types"

        local arraymt = { }
        local array = setmetatable( { }, arraymt )

        local types_array = types.register( array )

        function arraymt.__call( _, ... )
                local result
                -- construct result appropriately
                types_array[ result ] = true -- mark it as an array for the types module
                return result
        end

It might also be nice to allow types[ array ] to access a function or table that would do one of test or check though I'm not sure which one. Or there need to be ways to get the function versions so that one can optimize away the lookups if doing a lot of type-checking.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Renato Maia
In reply to this post by Mark Hamburg
On 30 Dec 2010, at 16:08, Mark Hamburg wrote:

> Unfortunately, the process of defining standard libraries runs into  
> the ground whenever it comes up. Since this seems to be beyond the  
> scope of what the core Lua team wants to tackle, what would be good  
> is if they could at least settle on some designated individual or  
> two on whom they could apply some form of official blessing.


Such kind of blessing shouldn't come from the Lua team but from the  
community itself. Afterall, what good would be to bless libraries that  
does not seem to get acceptance from the potential users?

--
Renato Maia
Computer Scientist
Tecgraf/PUC-Rio
__________________________
http://www.inf.puc-rio.br/~maia/


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Tomás Guisasola-2
In reply to this post by Mark Hamburg
  Hi Mark

> Unfortunately, the process of defining standard libraries runs into
> the ground whenever it comes up. Since this seems to be beyond the scope
> of what the core Lua team wants to tackle, what would be good is if they
> could at least settle on some designated individual or two on whom they
> could apply some form of official blessing. This choice might be based
> in part on submitted proposals or code as opposed to simply blessing
> someone. But the point would be that the resulting libraries had been
> discussed within the Lua inner sanctum in addition to being discussed
> on more public forums like this list and through that they gained more
> specific approval and support.
  I think this "official blessing" is a dream which will never
come true :-)  Besides, it is not necessary since there are successful
initiatives from the community without any approval from the Lua team
(I mean LuaSocket, LuaJIT and others).

  Regards,
  Tomás
Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Henning Diedrich
In reply to this post by Greg Falcon
On 12/30/10 7:39 PM, Greg Falcon wrote:
On Thu, Dec 30, 2010 at 12:56 AM, Dirk Laurie [hidden email] 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.

Well, no, I think we were talking about what # does.

That # can be made better is probably mostly discussed
 in the hope to change its current behavior to something more
satisfactorily or intuitive, if it should be changed at all.

Which can't work, as has been shown, because the price would be
to high. So it should probably simply throw an error.

I'd perfectly seriously second eliminating it from the language or
at least from the text books as second best option ...

It really boils down to what audience Lua is for.

A language that starts arrays with 1, mind you.
Reply | Threaded
Open this post in threaded view
|

Re: Virgin tables

Axel Kittenberger
In reply to this post by Greg Falcon
> There have been complaints in these threads about the result of the
> length operator not being deterministic -- that the same Lua code can
> return different answers on different implementations -- but this is a
> red herring.  The length operator could easily be made deterministic
> by specifying precisely how the unbounded binary search must be
> performed.  Then the answer would no longer be nondeterministic, but
> it would still be *arbitrary*.  It still wouldn't be very useful for
> non-array tables, and all of the complaints in these threads would
> continue.

Defining the binary search is not what I ment. I ment I dont care if #
for a non-list is number of elements, last key of ipairs(), largest
key, nil or even error. But any would IMHO make Lua a better language
with one pitfall less for the not-so-much-expert coder. And from the
notion of e.g. using "or" and "and" instead of || and &&, or defining
the sequence of calculation of op1() + op2() it was my imperssion it
tries to do that.

Its all cool that table.insert() uses #, but this is as far I can see
the one and only use of # on non-lists. So table.insert() could become
a C-implementation and # for non-lists any else meaning. Heck I might
not even miss the # operator that much. As has been argued against any
# proposals that its easier to code in Lua whatever you want it to
mean, you might also keep the length of lists yourself if you need it.

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Rena
In reply to this post by Tomás Guisasola-2
On Thu, Dec 30, 2010 at 13:04, Tomas Guisasola Gorham
<[hidden email]> wrote:

>        Hi Mark
>
>> Unfortunately, the process of defining standard libraries runs into
>> the ground whenever it comes up. Since this seems to be beyond the scope
>> of what the core Lua team wants to tackle, what would be good is if they
>> could at least settle on some designated individual or two on whom they
>> could apply some form of official blessing. This choice might be based
>> in part on submitted proposals or code as opposed to simply blessing
>> someone. But the point would be that the resulting libraries had been
>> discussed within the Lua inner sanctum in addition to being discussed
>> on more public forums like this list and through that they gained more
>> specific approval and support.
>
>        I think this "official blessing" is a dream which will never
> come true :-)  Besides, it is not necessary since there are successful
> initiatives from the community without any approval from the Lua team
> (I mean LuaSocket, LuaJIT and others).
>
>        Regards,
>                Tomás

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?)

As far as standard libraries go I wouldn't count on much of anything
receiving an official blessing - probably your best bet is to just
write a lot of small libraries, trying to avoid creating
incompatibilities with other peoples' libraries, offer downloads of
each individual library plus the entire bundle, and if they're good
enough they'll become widely-used enough to be a de-facto standard at
least. (That term bugs me a bit thinking of how IE did similar - but
then, it did so in the face of some existing standards.)

At some point I'll have to clean up my own little set of "standard"
libraries and release them somewhere... I suspect a lot of us have
decent collections of modules we've been keeping to ourselves because
they're messy...

--
Sent from my toaster.

1234