I dont understand all those discussions.

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

I dont understand all those discussions.

Ulrich Schmidt
Hello all.

I like the lua mailing list, because all the nice people around and all the
valuable discussions.

In the near past i read many discussion about a) new features requested and
b) trouble with tables.

I cant follow all the complains about table handling. If i know how tables
work ( and they work well from my point of view) then i write my own code in a
way my code keeps working. For me it looks like, people want to go from here
to there in a shortest way but there is a wall between. Now i can complain
about the wall again and again or i find the door in the wall and go thru the
door. The way to walk may be a little bit longer but i reach my destination.

I would like to discuss more the experience with existing lua versions than
dreaming about highly specialized features almost noons needs.

And i think its not the task of the lua language to work around badly written
functions and libraries.

Just my 2 cents. Sorry for the noise.

Ulrich.


Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Oliver Kroth
Hi all

I agree with Ulrich. Strongly.

I have to switch a lot between Lua and JavaScript, and their table/array
implementations.

And I have to say, I do favour the Lua implementation, where there is
only one data structure covering both, and especially only one literal
to initialize it. Makes storing data much easier!

If people need an iterator that jumps over holes when enumerating the
array part, why don't they make one?
Shouldn't be too complicated to make an inverse index table and use this
in a closure.

another 2 cents.

--

Oliver


Am 21.07.2016 um 20:27 schrieb Ulrich Schmidt:
> I cant follow all the complains about table handling. If i know how tables
> work ( and they work well from my point of view) then i write my own code in a
> way my code keeps working. For me it looks like, people want to go from here
> to there in a shortest way but there is a wall between. Now i can complain
> about the wall again and again or i find the door in the wall and go thru the
> door. The way to walk may be a little bit longer but i reach my destination.

Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Russell Haley
On Thu, Jul 21, 2016 at 1:21 PM, Oliver Kroth <[hidden email]> wrote:

> Hi all
>
> I agree with Ulrich. Strongly.
>
> I have to switch a lot between Lua and JavaScript, and their table/array
> implementations.
>
> And I have to say, I do favour the Lua implementation, where there is only
> one data structure covering both, and especially only one literal to
> initialize it. Makes storing data much easier!
>
> If people need an iterator that jumps over holes when enumerating the array
> part, why don't they make one?
> Shouldn't be too complicated to make an inverse index table and use this in
> a closure.

Perhaps posting an example for people to follow would help lessen some
of the "noise"? I've written some neat stuff in Lua but would have no
clue how to move forward with your suggestion. Maybe the people making
the noise aren't as experienced as you are?

However, to support your argument that this does not belong in the
base library, I have found that external packages are almost *more*
important than the base because Lua is so lean (which I think is a
good thing).

Russ

> another 2 cents.
>
> --
>
> Oliver
>
>
>
> Am 21.07.2016 um 20:27 schrieb Ulrich Schmidt:
>>
>> I cant follow all the complains about table handling. If i know how tables
>> work ( and they work well from my point of view) then i write my own code
>> in a
>> way my code keeps working. For me it looks like, people want to go from
>> here
>> to there in a shortest way but there is a wall between. Now i can complain
>> about the wall again and again or i find the door in the wall and go thru
>> the
>> door. The way to walk may be a little bit longer but i reach my
>> destination.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Sean Bolton-2
In reply to this post by Ulrich Schmidt
On Thu Jul 21 2016, Ulrich Schmidt wrote:
> I would like to discuss more the experience with existing lua
> versions than dreaming about highly specialized features almost noons
> needs.
[snip]
> Just my 2 cents. Sorry for the noise.

It's not noise, Ulrich, no need to apologize. My dream for Lua is
that we have a separate lua-bikeshedding-l list on which those
interested could discuss their dreams to their hearts' content, while
on this list we could concentrate on pragmatic discussion about this
already quite nice little language.

I gather that attempts at creating such a separation on other lists
have not been successful, the main problem being that one person's
bikeshed detail is another person's Fundamental Issue. So, I just
develop my habit of ignoring certain authors and certain topics.

But I hear you, my friend, I hear you....

-Sean

Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Oliver Kroth
In reply to this post by Russell Haley
Hi all (enumerated... :-)

OK, I will make an iterator function that does the trick.
The basic idea is that the table is enumerated once with pairs() to get
the maximum integer key being used. Then the iterator function gets this
as upvalue to correctly terminate. With each iteration it increments its
own index counter and returns the indx and value from table, if
existant, else the result of its (tail-)recursive recursion call.

For very sparse arrays, another approach might be faster:
at first run through the table with pairs() collecting all integer
indexes in a new index array, and sort that.
The iterator gets this as upvalue to walk through and pick the actual
array values using this index table.


give me a day or so...

--
Oliver

Am 21.07.2016 um 21:50 schrieb Russell Haley:
> Perhaps posting an example for people to follow would help lessen some
> of the "noise"? I've written some neat stuff in Lua but would have no
> clue how to move forward with your suggestion. Maybe the people making
> the noise aren't as experienced as you are? However, to support your
> argument that this does not belong in the base library, I have found
> that external packages are almost *more* important than the base
> because Lua is so lean (which I think is a good thing). Russ


Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Steve Litt
In reply to this post by Oliver Kroth
On Thu, 21 Jul 2016 21:21:05 +0200
Oliver Kroth <[hidden email]> wrote:
 

>
> Am 21.07.2016 um 20:27 schrieb Ulrich Schmidt:
> > I cant follow all the complains about table handling. If i know how
> > tables work ( and they work well from my point of view) then i
> > write my own code in a way my code keeps working. For me it looks
> > like, people want to go from here to there in a shortest way but
> > there is a wall between. Now i can complain about the wall again
> > and again or i find the door in the wall and go thru the door. The
> > way to walk may be a little bit longer but i reach my destination.  
>

> Hi all
>
> I agree with Ulrich. Strongly.
>
> I have to switch a lot between Lua and JavaScript, and their
> table/array implementations.

I agree with Oliver and Ulrich. In my view, one of Lua's greatest gifts
is that tables (and metatables) are the only complex data form, and you
can use them to make any data you want. All you have to do is get
really good at tables, and Lua becomes your faithful servant.

> And I have to say, I do favour the Lua implementation, where there is
> only one data structure covering both, and especially only one
> literal to initialize it. Makes storing data much easier!
>
> If people need an iterator that jumps over holes when enumerating the
> array part, why don't they make one?

I agree. There are probably ten different ways of doing it, and given
Lua's performance, they'll be fast even if they seem a little hokey.

If Lua's addons were as carefully curated as Python's, I'd use Lua
every day, because Lua's for sure the best language as a language. Why
people keep asking for more features in this beautifully simple
language is beyond me.

SteveT

Steve Litt
July 2016 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques

Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Russell Haley
On Thu, Jul 21, 2016 at 2:11 PM, Steve Litt <[hidden email]> wrote:

> On Thu, 21 Jul 2016 21:21:05 +0200
> Oliver Kroth <[hidden email]> wrote:
>
>>
>> Am 21.07.2016 um 20:27 schrieb Ulrich Schmidt:
>> > I cant follow all the complains about table handling. If i know how
>> > tables work ( and they work well from my point of view) then i
>> > write my own code in a way my code keeps working. For me it looks
>> > like, people want to go from here to there in a shortest way but
>> > there is a wall between. Now i can complain about the wall again
>> > and again or i find the door in the wall and go thru the door. The
>> > way to walk may be a little bit longer but i reach my destination.
>>
>
>> Hi all
>>
>> I agree with Ulrich. Strongly.
>>
>> I have to switch a lot between Lua and JavaScript, and their
>> table/array implementations.
>
> I agree with Oliver and Ulrich. In my view, one of Lua's greatest gifts
> is that tables (and metatables) are the only complex data form, and you
> can use them to make any data you want. All you have to do is get
> really good at tables, and Lua becomes your faithful servant.
>
>> And I have to say, I do favour the Lua implementation, where there is
>> only one data structure covering both, and especially only one
>> literal to initialize it. Makes storing data much easier!
>>
>> If people need an iterator that jumps over holes when enumerating the
>> array part, why don't they make one?
>
> I agree. There are probably ten different ways of doing it, and given
> Lua's performance, they'll be fast even if they seem a little hokey.
>
> If Lua's addons were as carefully curated as Python's, I'd use Lua
> every day, because Lua's for sure the best language as a language. Why
> people keep asking for more features in this beautifully simple
> language is beyond me.
<humour> Well, for the same reason we don't all write things in
assembly I suppose? ;) </humour>

Russ

Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Martin
In reply to this post by Russell Haley
On 16-07-21 12:50 PM, Russell Haley wrote:
> Perhaps posting an example for people to follow would help lessen some
> of the "noise"?

As stated somewhere earlier, to implement arrays with nils inside you
just need to define __len metamethod. This sketch demonstrates one of
possible implementations of this idea.

-----
local empty_func = function() end
--( Implement yourself:
local assert_table = empty_func
local is_number = function() return true end
local is_integer = function() return true end
--)

local get_max_idx =
  function(t)
    assert_table(t)
    local result
    for k, v in pairs(t) do
      if is_number(k) and is_integer(k) then
        if not result or (k > result) then
          result = k
        end
      end
    end
    return result
  end

local length_func =
  function(t)
    local mt = getmetatable(t)
    return mt.array_length
  end

local to_array =
  function(t, length)
    length = length or get_max_idx(t) or 0
    setmetatable(
      t,
      {
        is_array = true,
        array_length = length,
        __len = length_func,
      }
    )
  end

-- Demo:
local t = {nil, nil, 3, nil, 5}
to_array(t)
for i = 1, #t do
  print(i, t[i])
end
-----

Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Ulrich Schmidt
In reply to this post by Russell Haley
Am 21.07.2016 um 21:50 schrieb Russell Haley:
>
> Perhaps posting an example for people to follow would help lessen some
> of the "noise"? I've written some neat stuff in Lua but would have no
> clue how to move forward with your suggestion. Maybe the people making
> the noise aren't as experienced as you are?
>
My experience is below most of yours. But i try to find the door. Again:
1) try avoiding holes
2) if you cant because you did not write the code, try other modules or
   patch them.
3) if 1) and 2) cant help: rework the table you get and remove all holes.

This function should work for all tables:
--================================================================

function reworkTable(tbl)
  local result = {};
  local sorttbl = {};
  local lastIdx;
  for n, v in pairs(tbl) do
    if type(n) == "number" then
      if not lastIdx or (lastIdx + 1) ~= n then
        table.insert(sorttbl, {n,{v}});
      else
        table.insert(sorttbl[#sorttbl][2], v);
      end;
      lastIdx = n;
    else
      result[n] = v;
    end;
  end;
  table.sort(sorttbl, function(a,b) return a[1] < b[1]; end);
  for _, t in ipairs(sorttbl) do
    for _, v in ipairs(t[2]) do
      table.insert(result, v);
    end;
  end;
  return result;
end;

--================================================================

Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Philipp Janda
In reply to this post by Oliver Kroth
Am 21.07.2016 um 22:03 schröbte Oliver Kroth:
> Hi all (enumerated... :-)

Hi!

>
> OK, I will make an iterator function that does the trick.
> The basic idea is that the table is enumerated once with pairs() to get
> the maximum integer key being used.
>
>
> give me a day or so...

Before you start: Arrays with holes in it also can have holes at the
end, so the largest integer key with a non-nil value is not necessarily
the size of the array.

>
> --
> Oliver

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Tim Hill
In reply to this post by Ulrich Schmidt

> On Jul 21, 2016, at 2:37 PM, Ulrich Schmidt <[hidden email]> wrote:
>
> Am 21.07.2016 um 21:50 schrieb Russell Haley:
>>
>> Perhaps posting an example for people to follow would help lessen some
>> of the "noise"? I've written some neat stuff in Lua but would have no
>> clue how to move forward with your suggestion. Maybe the people making
>> the noise aren't as experienced as you are?
>>
> My experience is below most of yours. But i try to find the door. Again:
> 1) try avoiding holes
> 2) if you cant because you did not write the code, try other modules or
>   patch them.
> 3) if 1) and 2) cant help: rework the table you get and remove all holes.
>

Argh not table holes again! <j/k>

When I was discussing the issue of table holes in the recent thread, my perspective was much less about “yet another feature request”, it was actually much closer I think to Ulrich’s post. Personally, I admire Lua not only as a very practical language but also one which is aesthetically elegant. The reason I dislike the current “sequences cannot have holes” design is (a) it is peculiarly at odds with the clean simple design of the rest of the language (even the definition of sequence, though correct, is not intuitive), and (b) appears to confuse a pretty significant number of people judging by how often it comes up on this list.

—Tim



Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Dirk Laurie-2
2016-07-22 1:46 GMT+02:00 Tim Hill <[hidden email]>:

> Personally, I admire Lua not only as a very practical language but also
> one which is aesthetically elegant.

Hear, hear!

My take on these discussions (of which we have had an inordinate
number recently) is that they are very much like those between
supporters of a football team. The participants are talking about
something they love passionately and often know very well. They
critically evaluate the performance of the team, and each is absolutely
convinced of having got a brilliant idea that so far has completely
escaped the notice of the manager, captain etc.

The chance that any particular idea will actually be taken up by the
manager and captain is remote, but that does not deter the fans.
They are having fun, even if the arguments do get heated.

> The reason I dislike the current “sequences cannot have holes” design
> is (a) it is peculiarly at odds with the clean simple design of the rest
> of the language (even the definition of sequence, though correct,
> is not intuitive),

Oh, there is no design to it. The notion of a sequence is only the most
recent in a long series of attempts to disguise an implementation detail
as a concept. Don't blame the design; blame the documentation.

Here is some history from present to past.

5.3 The table library respects __index, i.e. accesses are no longer raw.
5.2.2 Illegal indices to table.insert and table.remove are flagged as
errors instead of silently causiing something silly.
5.2 The table library respects __len, and the notion of 'sequence' finds
its way into the manual. The word "hole" is not used.
5.1 The word 'length' is used for the result of the new # operator,
and the notion of "hole" is used to describe something that "regular
arrays" do not have.
5.0 Table manipulation is collected into the 'table' library. The "size"
of an array could be some hidden internal register that you can set
with 'setn',
4.0 'tinsert' and 'tremove' appear as global functions. The notion
of "size" of an array is used, which is either an explicit 'n' field
or the number of elements before the first hole (but the word "hole"
is not used).

"size", "length", "hole", "regular array", "sequence" -- from the
documentation you will get the impression that the table library
has been rewritten many times, but that is true only of the
way length is defined. The way that it is computed is almost
the same right through: there is a mechanism to set length
explicitly, otherwise the loop stops at a hole.

> and (b) appears to confuse a pretty significant number of people
> judging by how often it comes up on this list.

You can't blame folk for trying to read the manual :-) but in
this case most people would be better off with just a couple
of examples of what insert and remove do.

The subtle thing is the length operator, and it will stay subtle as
long as we want a faster than O(n) way of computing it. Personally
I found the definition in the Lua 5.1 manual very clear, and would
like to have it back. I don't object to the word "hole" either. It was
taken out of the manual more than five years ago, but everybody
still uses it.

Reply | Threaded
Open this post in threaded view
|

Re: I dont understand all those discussions.

Tim Hill

On Jul 21, 2016, at 9:44 PM, Dirk Laurie <[hidden email]> wrote:

5.3 The table library respects __index, i.e. accesses are no longer raw.
5.2.2 Illegal indices to table.insert and table.remove are flagged as
errors instead of silently causiing something silly.
5.2 The table library respects __len, and the notion of 'sequence' finds
its way into the manual. The word "hole" is not used.
5.1 The word 'length' is used for the result of the new # operator,
and the notion of "hole" is used to describe something that "regular
arrays" do not have.
5.0 Table manipulation is collected into the 'table' library. The "size"
of an array could be some hidden internal register that you can set
with 'setn',
4.0 'tinsert' and 'tremove' appear as global functions. The notion
of "size" of an array is used, which is either an explicit 'n' field
or the number of elements before the first hole (but the word "hole"
is not used).

Yes I too have watched it over the years. Personally, I found “setn” was the best so far, since it made length explicit, simple to understand (and also O(1), which was nice). This also aligns with pretty much every other language. However I don’t want to re-open this rats nest again.

—Tim