What is this list for?
Dirk Laurie
we're not allowed to dicuss on the list, but eventually we would like
to offer something useful.
And that's not going to be Roberto saying with tears in his eyes,
sorry boys that I accused you of vanity, what beautiful core patches,
I've been wrong for the last five years, they're going straight into
Lua 5.3.
Here are some deliberately controversial aims.
1. The table library sucks. Instead of telling Roberto to change it,
provide alternatives. My code proposal uses the model of
constructors like list{}, array{}, set{}, heap{}, dict{}, each of
which overrides whatever is needed from __len, __newindex, __pairs
etc and is associated with its own library. I'm willing to listen
to other ideas.
2. The reference manual is not for newbies, neither is PiL. If the
concern for newbies is what drives us, we should be willing to invest
some time in writing a Lua primer aimed at people that have never
programmed in any earnest. Professional like, ahem, ourselves,
of course don't need that.
3. Despite point 1, maybe we should draw up a list of deficiencies of
the table library on which we all agree and submit that to Roberto
and his team, signed as the consensus of this group.
(a) The behaviour of table functions when abused is not defined in
the reference manual, so changing that behaviour cannot break any
existing well-validated code.
(b) Inserting nil should always do nothing.
(c) Removing an element not in the range 1 to #t should do the
same as setting it to nil.
(d) Inserting an element at a non-positive index should be the
same as assigning it.
None of this will have any effect on code in which the table library
is used only for the purpose for which it was designed.
Dirk
Henning Diedrich
On Jan 17, 12:13 pm, Dirk Laurie <d...@sun.ac.za> wrote:
> [snip]
> sorry boys that I accused you of vanity, what beautiful core patches,
> I've been wrong for the last five years, they're going straight into
> Lua 5.3.
target I think.
I would not expect that to happen but it makes sense as a direction.
And I do think the know full well that it's not good as it is. There
are other
constraints that kept it like it is I'd say.
> 2. The reference manual is not for newbies, neither is PiL. If the
> concern for newbies is what drives us, we should be willing to invest
> some time in writing a Lua primer aimed at people that have never
> programmed in any earnest.
I would be interested in that but does it make sense, i.e., isn't
simply
duplicating what exists?
> 3. Despite point 1, maybe we should draw up a list of deficiencies of
> the table library on which we all agree and submit that to Roberto
> and his team, signed as the consensus of this group.
anyway, again to have direction, not actually to think that it is
going
to change anything.
For that special occasion, maybe the irony of 'vanity' should be
avoided
and we'd call us The Penitents. Sounds like petition, so that's
somehow
right. Also, we might still find where the flaws of our thinking might
lie.
> (a) The behaviour of table functions when abused is not defined in
> the reference manual, so changing that behaviour cannot break any
> existing well-validated code.
> (b) Inserting nil should always do nothing.
> (c) Removing an element not in the range 1 to #t should do the
> same as setting it to nil.
> (d) Inserting an element at a non-positive index should be the
> same as assigning it.
too complicated, or, irregular and counter-intuitive to the name
'insert',
in my view,
Axel Kittenberger
> Well, it is a sort of cyberpub where we can all chat about the stuff
> we're not allowed to dicuss on the list, but eventually we would like
> to offer something useful.
Exactly, this list is to discuss in open what some didnt want to read
anymore on lua-l. Its up to the participants to control what it
yields. For me it can be anything from the natural end of discussion
that would have come with no intervention (like it happened to the
Lambda discussion), or a library, or a (power)patch to the lua core,
up until a dialect.
> And that's not going to be Roberto saying with tears in his eyes,
> sorry boys that I accused you of vanity, what beautiful core patches,
> I've been wrong for the last five years, they're going straight into
> Lua 5.3.
Well I suppose he isn't that closed against real patches. In my
opinion he considers current # his (or Luiz) genius stroke and is
snupped, because we (and the quite a number on the list) keep dissing
it.
> 1. The table library sucks. Instead of telling Roberto to change it,
> provide alternatives. My code proposal uses the model of
> constructors like list{}, array{}, set{}, heap{}, dict{}, each of
> which overrides whatever is needed from __len, __newindex, __pairs
> etc and is associated with its own library. I'm willing to listen
> to other ideas.
I like this a lot. One can argue, and that will be argued, if one has
to say at construction time what a table will mostly do, it makes
things not simpler.
> 2. The reference manual is not for newbies, neither is PiL. If the
> concern for newbies is what drives us, we should be willing to invest
> some time in writing a Lua primer aimed at people that have never
> programmed in any earnest. Professional like, ahem, ourselves,
> of course don't need that.
I don't know if (yet another) "coding introduction for the total
newbie" only this time with pure Lua as core makes much sense. Lua has
no batteries, and it makes more sense to introduce people within a
specific framework they are interested in.
Some pitfalls ignored, lua is simple and beside the smallness and
speed this makes it the ideal pick for the gaming industry. They
expect their artists and not their core coding team to code Lua! Thats
why (I suppose) they are useing it after all and not code everything
in C(++). The same applies to wireshark and nmap, and eventually why I
picked Lua for Lsyncd. Mostly someone wanting to write World of
Warcraft extensions, wants an Intro centered around that, and I
believe they exist.
This has been touched on the list, if a coding intro with a gameish
framework like Logo and its Turtle.
> 3. Despite point 1, maybe we should draw up a list of deficiencies of
> the table library on which we all agree and submit that to Roberto
> and his team, signed as the consensus of this group.
To come up with a list of deficiencies is a good idea, but we should
only submit when we have a solution (a patch, library, etc.) ready. As
far I understood this was Robertos main point.
> (a) The behaviour of table functions when abused is not defined in
> the reference manual, so changing that behaviour cannot break any
> existing well-validated code.
indeed.
> (b) Inserting nil should always do nothing.
> (c) Removing an element not in the range 1 to #t should do the
> same as setting it to nil.
> (d) Inserting an element at a non-positive index should be the
> same as assigning it.
> None of this will have any effect on code in which the table library
> is used only for the purpose for which it was designed.
Hmm, I'm not convinced. Personally I like code that errors() whenever
something not strictly within the defined interface happens than doing
anything. This can save you days and weeks of debugging and even as
customer I like a clear crash with dump more than strange behavior.
I suggest following data structure. I call it in the meantime "hog" to
not conflict with list or array.
* "Hog "has a defined length n, which it stores it somewhere.
* All keys that are positive integers are within 1 and n.
* All other numeric keys are just plain keys for which the same rules
hold true as if they were e.g. strings.
* Setting any positive integer larger than n will result in an error()
and if not catched in termination of the script.
* This includes n + 1.
* Any key from 1 to n has a value, for which nil is allowed and
nothing more special than 0.
* hog.append(hog, value) will increase n of "hog" by 1 and set hog[n]
= value. Value can be nil.
* hog.insert(hog, pos, value): pos must be a positive integer <= n,
otherwise error(), it will increase n by 1 shift right all elements
>pos, and set hog[pos| = value. pos can be n+1 in which it is
identical to append.
* hog.remove(hog, pos): pos must a positive integer <= n, otherwise
error(), it will descrease n by 1 and shift left all elements > pos.
* ipairs(hog) will produce n key value pairs, where key goes from 1 to
n and where value can be nil!
* pairs(hog) will produce as many key value pairs as there are, this
includes all numeric keys that are not positive integer. value will
never be nil.
* #hog will return n.
* setting hog[#hog] = nil. Will not alter the length. Its a first
class value in this regard, its just has nil as last elemgt.
This is, in my opinion, simple, intuative and effective in coding.
This does not need to differ between array and list. As far I realize
this is mostly what you had in mind with "array" right?.
Ideally one would still be able to set a (second?) metatable to "hog"
and thus remove the need for a different list. So if the user wants to
forbid nils within or want it to translate into a remove the user can
do very simply via the metatable.
Not exactly a metatable in the current sense, as it would need a
function to be called when setting any value without the need for yet
another proxy.
Kind regards, Axel
steve donovan
> (a) The behaviour of table functions when abused is not defined in
> the reference manual, so changing that behaviour cannot break any
> existing well-validated code.
A good approach to take; extending the defined domain of these
functions further.
> (b) Inserting nil should always do nothing.
Even David K. likes this one. But I bet you there are some people out
there relying on table.insert(T,idx,nil) actually inserting a hole.
That can happen so easily by accident that I agree that the needs of
these few should be offset by the needs of the many - that it should
always do nothing. (One can still insert holes by inserting a non-nil
and setting that slot to nil explicitly.)
> (c) Removing an element not in the range 1 to #t should do the
> same as setting it to nil.
What weirdness currently happens?
steve d.
Henning Diedrich
> I call it in the meantime "hog" to not conflict with list or array.