A proposal for the confusing pseudo table ≈ array concept

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

A proposal for the confusing pseudo table ≈ array concept

Elias Hogstvedt
Lua was my first language and the language I've been using the most for 10~ years. I want to point this out becuase I don't want to be the guy who's coming from X language that want changes in Lua because it's different from his favorite language. I'm not really expecting any change but it's fun to think about language design and I'm looking for feedback.


I think there’s a need for arrays now, especially if we want to solve var args being a second class citizen. table.pack introduces the n field as a workaround for nil values in a table but this feels a bit like duct tape when we could just have an array type in Lua.

In my experience with teaching other people Lua, a lot of time is spent explaining the differences between tables and arrays. There’s confusion about the length operator, pairs vs ipairs, performance difference, holes in tables, etc. The entire table library also only makes sense on tables that are treated as arrays and causes undefined behavior when used on tables.

So to solve this I would simply add an array type to Lua which would help distinguish between tables and arrays. To distinguish our new array type from arrays in other languages that start from 0 and can only contain a certain type of value we can just call it a "list" instead.

Since all the table functions in Lua only work or make sense on tables that are treated as lists we simply rename _G.table to _G.list. The list object should __index to _G.list so it's possible to do “mylist:insert(2)”

Now that we have no table library we can create one with functions that only made sense on tables instead.
    table.get/setmetatable, table.rawget/set, table.rawequal, table.next, table.rawlen, table.pairs ( ? )
   
The length operator on tables would no longer work unless we set a metatable on the table with the length operator.

_G.ipairs would no longer be needed and so using pairs on lists would ensure correct order while on tables it would not. We can also put _G.pairs in _G.list.pairs to allow the syntax "for i,v in mylist:pairs() do"

The list object would be constructed with the syntax [a,b,c] instead of {a,b,c} and can contain any value. However list keys are strictly numbered and ordered.

"mylist = table.tolist(tbl)"  -  for converting table to list if the table is valid.
"mylist = []"  -  to create a dynamically sized list.
"mylist = [1,2,3,4,nil,6]"  -  to create a list that is 6 in length.

Var args become a list object. Because of this I think "..." should be replaced with @. Here are some lua examples with the old method on top.


mytbl.varargs = table.pack(...)
======================
function foo(@)
     mytbl.varargs = @
     print(mytbl.varargs[1])
end
foo(42)
=======================
>> 42


local x,y,z = ...
======================
function foo(@)
    local x,y,z = @:unpack()
    print(x,y,z)
end
test(1,nil,2)
=======================
>> 1 nil 2


select(“#, ...”)
=======================
function foo(a,b,c,@)
    print(#@)
end
foo(1,2,3,4,5,6,7,8,9)
=======================
>> 6


for i = 1, select(“#”, ...) do print(i, (select(i, ...))) end
=======================
function foo(@)
    for i,v in @:pairs() do
        print(i,v)
    end
end
test(1,nil,2)
=======================
>> 1 1
>> 2 nil
>> 3 3

I believe this would simplify and make the language easier to understand.
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

KHMan
On 1/19/2018 6:26 PM, Elias Hogstvedt wrote:
> Lua was my first language and the language I've been using the
> most for 10~ years. I want to point this out becuase I don't want
> to be the guy who's coming from X language that want changes in
> Lua because it's different from his favorite language. I'm not
> really expecting any change but it's fun to think about language
> design and I'm looking for feedback.
>
[snip snip snip]
>
> I believe this would simplify and make the language easier to
> understand.

'Simplify'.

Really?

(That's all I'm going to say, ha ha. :-p I'll leave it to others
to argue it out.)

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Dirk Laurie-2
In reply to this post by Elias Hogstvedt
2018-01-19 12:26 GMT+02:00 Elias Hogstvedt <[hidden email]>:

(a)
> Since all the table functions in Lua only work or make sense on tables that
> are treated as lists we simply rename _G.table to _G.list. The list object
> should __index to _G.list so it's possible to do “mylist:insert(2)”

(b)
> Now that we have no table library we can create one with functions that only
> made sense on tables instead.
>     table.get/setmetatable, table.rawget/set, table.rawequal, table.next,
> table.rawlen, table.pairs ( ? )

(c)
> The length operator on tables would no longer work unless we set a metatable
> on the table with the length operator.

(d)
> _G.ipairs would no longer be needed and so using pairs on lists would ensure
> correct order while on tables it would not. We can also put _G.pairs in
> _G.list.pairs to allow the syntax "for i,v in mylist:pairs() do"

(e)
> The list object would be constructed with the syntax [a,b,c] instead of
> {a,b,c} and can contain any value. However list keys are strictly numbered
> and ordered.

(f)
> "mylist = table.tolist(tbl)"  -  for converting table to list if the table
> is valid.
> "mylist = []"  -  to create a dynamically sized list.
> "mylist = [1,2,3,4,nil,6]"  -  to create a list that is 6 in length.

(g)
> Var args become a list object. Because of this I think "..." should be
> replaced with @. Here are some lua examples with the old method on top.

> I believe this would simplify and make the language easier to understand.

Seven breaking changes. Not merely breaking some programs that have
worked unchanged since Lua 2.1, breaking all of them.

Whatever you call this new language of yours, please don't include the
letters L,U,A consecutively anywhere in its name.

Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Elias Hogstvedt
Yes it will break everything, so I don't really expect this to be implemented. Perhaps a new language?

If you can imagine a new language or be okay with breaking changes, do you think these changes make sense?

On Fri, Jan 19, 2018 at 1:01 PM, Dirk Laurie <[hidden email]> wrote:
2018-01-19 12:26 GMT+02:00 Elias Hogstvedt <[hidden email]>:

(a)
> Since all the table functions in Lua only work or make sense on tables that
> are treated as lists we simply rename _G.table to _G.list. The list object
> should __index to _G.list so it's possible to do “mylist:insert(2)”

(b)
> Now that we have no table library we can create one with functions that only
> made sense on tables instead.
>     table.get/setmetatable, table.rawget/set, table.rawequal, table.next,
> table.rawlen, table.pairs ( ? )

(c)
> The length operator on tables would no longer work unless we set a metatable
> on the table with the length operator.

(d)
> _G.ipairs would no longer be needed and so using pairs on lists would ensure
> correct order while on tables it would not. We can also put _G.pairs in
> _G.list.pairs to allow the syntax "for i,v in mylist:pairs() do"

(e)
> The list object would be constructed with the syntax [a,b,c] instead of
> {a,b,c} and can contain any value. However list keys are strictly numbered
> and ordered.

(f)
> "mylist = table.tolist(tbl)"  -  for converting table to list if the table
> is valid.
> "mylist = []"  -  to create a dynamically sized list.
> "mylist = [1,2,3,4,nil,6]"  -  to create a list that is 6 in length.

(g)
> Var args become a list object. Because of this I think "..." should be
> replaced with @. Here are some lua examples with the old method on top.

> I believe this would simplify and make the language easier to understand.

Seven breaking changes. Not merely breaking some programs that have
worked unchanged since Lua 2.1, breaking all of them.

Whatever you call this new language of yours, please don't include the
letters L,U,A consecutively anywhere in its name.


Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Grey Knight-2
On Friday, January 19, 2018, 12:23:26 PM GMT, Elias Hogstvedt <[hidden email]> wrote:
> Yes it will break everything, so I don't really expect this to be
> implemented. Perhaps a new language?
> If you can imagine a new language or be okay with breaking changes, do you
> think these changes make sense?


Hi Elias,

I think that what you are looking for is a language with stronger typing than Lua has.  In such a language I think your expectations would be valid ones to have, it's just that Lua prefers to take a more "duck typing" approach to dealing with different interpretations of tables.

You mentioned the predominant "list" and "dictionary" interpretations of table, but we can also use them as objects, or classes, or even modules!

You should try some languages with stronger typing and see if they meet your needs well.

--
GK
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Elias Hogstvedt
In reply to this post by KHMan
Can you elaborate regardless? It introduces 1 more type, removes the vararg type and some functions that deals with var args. The end result are less lua functions and fewer exceptions to remember.

In a way we have 2 fundamental types already. The entire table library assumes that the table passed is treated as an array type. This separation has grown more since table.pack and table.unpack was introduced. Ipairs work on arrays and pairs work on everything else, now there're only pairs.

For those of us who have used Lua for a long time and understand the differences between arrays and tables, a change like this is something new we would have to learn. So in that sense not changing anything is more simple than learning something new. Is that what you mean?

Maybe I should have used a different subject in the email. I honestly don't expect this to be implemented in Lua, but I would definitely be interested in a change like this. I'm also wondering if for instance the introduction of [] as a constructor would cause issues with other syntax (backwards compatibility aside) or if these changes could make the C implementation more difficult.


On Fri, Jan 19, 2018 at 12:50 PM, KHMan <[hidden email]> wrote:
On 1/19/2018 6:26 PM, Elias Hogstvedt wrote:
Lua was my first language and the language I've been using the most for 10~ years. I want to point this out becuase I don't want to be the guy who's coming from X language that want changes in Lua because it's different from his favorite language. I'm not really expecting any change but it's fun to think about language design and I'm looking for feedback.

[snip snip snip]

I believe this would simplify and make the language easier to understand.

'Simplify'.

Really?

(That's all I'm going to say, ha ha. :-p I'll leave it to others to argue it out.)

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia



Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

KHMan
On 1/19/2018 10:45 PM, Elias Hogstvedt wrote:
> Can you elaborate regardless? It introduces 1 more type, removes
> the vararg type and some functions that deals with var args. The
> end result are less lua functions and fewer exceptions to remember.

Who uses @ as vararg? Who uses ... as vararg?

Why hasn't Perl 6 taken the world by storm?

How many coders have all of C++ at the tip of their fingers?

Cognitive loads.


> [snip]
>
> On Fri, Jan 19, 2018 at 12:50 PM, KHMan wrote:
>
>     On 1/19/2018 6:26 PM, Elias Hogstvedt wrote:
>
>         Lua was my first language and the language I've been using
>         the most for 10~ years. I want to point this out becuase I
>         don't want to be the guy who's coming from X language that
>         want changes in Lua because it's different from his
>         favorite language. I'm not really expecting any change but
>         it's fun to think about language design and I'm looking
>         for feedback.
>
>     [snip snip snip]
>
>
>         I believe this would simplify and make the language easier
>         to understand.
>
>
>     'Simplify'.
>
>     Really?
>
>     (That's all I'm going to say, ha ha. :-p I'll leave it to
>     others to argue it out.)


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia



Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Elias Hogstvedt
I honestly don't understand this response but I'll try.

I'm not familiar with Perl 6, does it use @ as var arg? We can use another symbol if the symbol is important, it was just the best I think of. Using "..." seems problematic if you want it to be treated as an object (...:unpack() looks strange)

A language doesn't have to take the world by storm. What I mainly like about Lua is its simple syntax, simple library and yet powerful expression. I've grown to love this principle about the language and I'm proposing an idea on how to take it even further in that direction. Some people prefer more syntax to write less code (see moonscript) but I assume people who like us like more of the opposite.

The core idea here is really to make the language have less cognitive load, less rules and easier to learn and understand. C++ on the other hand does not to have this goal so we don't expect people to know everything about C++ at their fingertips.




On Fri, Jan 19, 2018 at 4:02 PM, KHMan <[hidden email]> wrote:
On 1/19/2018 10:45 PM, Elias Hogstvedt wrote:
Can you elaborate regardless? It introduces 1 more type, removes the vararg type and some functions that deals with var args. The end result are less lua functions and fewer exceptions to remember.

Who uses @ as vararg? Who uses ... as vararg?

Why hasn't Perl 6 taken the world by storm?

How many coders have all of C++ at the tip of their fingers?

Cognitive loads.


[snip]

On Fri, Jan 19, 2018 at 12:50 PM, KHMan wrote:

    On 1/19/2018 6:26 PM, Elias Hogstvedt wrote:

        Lua was my first language and the language I've been using
        the most for 10~ years. I want to point this out becuase I
        don't want to be the guy who's coming from X language that
        want changes in Lua because it's different from his
        favorite language. I'm not really expecting any change but
        it's fun to think about language design and I'm looking
        for feedback.

    [snip snip snip]


        I believe this would simplify and make the language easier
        to understand.


    'Simplify'.

    Really?

    (That's all I'm going to say, ha ha. :-p I'll leave it to
    others to argue it out.)


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia




Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Advert Slaxxor
Seeing that integers were added, it's not too far fetched to see arrays as well.
But, it should be implemented nicely. Using '@' (at) where ... works fine, and has worked fine, seems like a major distraction for me. 

Simplification is a bad thing. You might as well say we should use + to concatenate strings now, too. That's simpler, right?

No. What we need is concisification™ (Yes, made up word. But you get the point). Using `..` for concatenation makes some amount of sense:  "some..thing" . Using `...` for varargs makes sense, to the same degree: "they did this, that, and then ..."

At "..." being problematic: It's not.

If we want ... as a list/array:
function foo(a, b, ...) local args = [...] end -- or what have you

- Advert

On Fri, Jan 19, 2018 at 3:36 PM, Elias Hogstvedt <[hidden email]> wrote:
I honestly don't understand this response but I'll try.

I'm not familiar with Perl 6, does it use @ as var arg? We can use another symbol if the symbol is important, it was just the best I think of. Using "..." seems problematic if you want it to be treated as an object (...:unpack() looks strange)

A language doesn't have to take the world by storm. What I mainly like about Lua is its simple syntax, simple library and yet powerful expression. I've grown to love this principle about the language and I'm proposing an idea on how to take it even further in that direction. Some people prefer more syntax to write less code (see moonscript) but I assume people who like us like more of the opposite.

The core idea here is really to make the language have less cognitive load, less rules and easier to learn and understand. C++ on the other hand does not to have this goal so we don't expect people to know everything about C++ at their fingertips.




On Fri, Jan 19, 2018 at 4:02 PM, KHMan <[hidden email]> wrote:
On 1/19/2018 10:45 PM, Elias Hogstvedt wrote:
Can you elaborate regardless? It introduces 1 more type, removes the vararg type and some functions that deals with var args. The end result are less lua functions and fewer exceptions to remember.

Who uses @ as vararg? Who uses ... as vararg?

Why hasn't Perl 6 taken the world by storm?

How many coders have all of C++ at the tip of their fingers?

Cognitive loads.


[snip]

On Fri, Jan 19, 2018 at 12:50 PM, KHMan wrote:

    On 1/19/2018 6:26 PM, Elias Hogstvedt wrote:

        Lua was my first language and the language I've been using
        the most for 10~ years. I want to point this out becuase I
        don't want to be the guy who's coming from X language that
        want changes in Lua because it's different from his
        favorite language. I'm not really expecting any change but
        it's fun to think about language design and I'm looking
        for feedback.

    [snip snip snip]


        I believe this would simplify and make the language easier
        to understand.


    'Simplify'.

    Really?

    (That's all I'm going to say, ha ha. :-p I'll leave it to
    others to argue it out.)


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia





Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Jean-Luc Jumpertz-2
In reply to this post by Elias Hogstvedt
Frankly, this proposal makes sense, and I thinks bashers should read it carefully before criticizing it with that much energy… :-)

- Yes, having a single type of structured data is intellectually elegant, but it brings lots of subtleties that are not easy to understand for Lua newcomers.
- Yes, tables with holes are hell (see the number of discussions on this list about ipairs or about the len operator ;-)
- Yes, the "table" library is only related to sequences.

So thanks, Elias for having taken the time to write this! :-)

> Le 19 janv. 2018 à 11:26, Elias Hogstvedt <[hidden email]> wrote:
>
> In my experience with teaching other people Lua, a lot of time is spent explaining the differences between tables and arrays. There’s confusion about the length operator, pairs vs ipairs, performance difference, holes in tables, etc. The entire table library also only makes sense on tables that are treated as arrays and causes undefined behavior when used on tables.
>
> So to solve this I would simply add an array type to Lua which would help distinguish between tables and arrays. To distinguish our new array type from arrays in other languages that start from 0 and can only contain a certain type of value we can just call it a "list" instead.
>
> Since all the table functions in Lua only work or make sense on tables that are treated as lists we simply rename _G.table to _G.list. The list object should __index to _G.list so it's possible to do “mylist:insert(2)”
>
> Now that we have no table library we can create one with functions that only made sense on tables instead.
>     table.get/setmetatable, table.rawget/set, table.rawequal, table.next, table.rawlen, table.pairs ( ? )
>    
> The length operator on tables would no longer work unless we set a metatable on the table with the length operator.
>
> _G.ipairs would no longer be needed and so using pairs on lists would ensure correct order while on tables it would not. We can also put _G.pairs in _G.list.pairs to allow the syntax "for i,v in mylist:pairs() do"
>
> I believe this would simplify and make the language easier to understand.


Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Elias Hogstvedt
In reply to this post by Advert Slaxxor
That's a good point to keep using "..."

The only minor issue I had with "..." is that it does not look like an object. Maybe it doesn't need to be and like you said local args = [...] is totally fine. Or that "..." is just an object so ...:unpack() or local args = ... is allowed. At that point we can also just do function(a,b,...=args) as it is in 5.4 at the moment (although I'm personally not a fan of this, I'd rather have local args = [...] than syntax shortcuts)

On Fri, Jan 19, 2018 at 4:42 PM, Advert Slaxxor <[hidden email]> wrote:
Seeing that integers were added, it's not too far fetched to see arrays as well.
But, it should be implemented nicely. Using '@' (at) where ... works fine, and has worked fine, seems like a major distraction for me. 

Simplification is a bad thing. You might as well say we should use + to concatenate strings now, too. That's simpler, right?

No. What we need is concisification™ (Yes, made up word. But you get the point). Using `..` for concatenation makes some amount of sense:  "some..thing" . Using `...` for varargs makes sense, to the same degree: "they did this, that, and then ..."

At "..." being problematic: It's not.

If we want ... as a list/array:
function foo(a, b, ...) local args = [...] end -- or what have you

- Advert

On Fri, Jan 19, 2018 at 3:36 PM, Elias Hogstvedt <[hidden email]> wrote:
I honestly don't understand this response but I'll try.

I'm not familiar with Perl 6, does it use @ as var arg? We can use another symbol if the symbol is important, it was just the best I think of. Using "..." seems problematic if you want it to be treated as an object (...:unpack() looks strange)

A language doesn't have to take the world by storm. What I mainly like about Lua is its simple syntax, simple library and yet powerful expression. I've grown to love this principle about the language and I'm proposing an idea on how to take it even further in that direction. Some people prefer more syntax to write less code (see moonscript) but I assume people who like us like more of the opposite.

The core idea here is really to make the language have less cognitive load, less rules and easier to learn and understand. C++ on the other hand does not to have this goal so we don't expect people to know everything about C++ at their fingertips.




On Fri, Jan 19, 2018 at 4:02 PM, KHMan <[hidden email]> wrote:
On 1/19/2018 10:45 PM, Elias Hogstvedt wrote:
Can you elaborate regardless? It introduces 1 more type, removes the vararg type and some functions that deals with var args. The end result are less lua functions and fewer exceptions to remember.

Who uses @ as vararg? Who uses ... as vararg?

Why hasn't Perl 6 taken the world by storm?

How many coders have all of C++ at the tip of their fingers?

Cognitive loads.


[snip]

On Fri, Jan 19, 2018 at 12:50 PM, KHMan wrote:

    On 1/19/2018 6:26 PM, Elias Hogstvedt wrote:

        Lua was my first language and the language I've been using
        the most for 10~ years. I want to point this out becuase I
        don't want to be the guy who's coming from X language that
        want changes in Lua because it's different from his
        favorite language. I'm not really expecting any change but
        it's fun to think about language design and I'm looking
        for feedback.

    [snip snip snip]


        I believe this would simplify and make the language easier
        to understand.


    'Simplify'.

    Really?

    (That's all I'm going to say, ha ha. :-p I'll leave it to
    others to argue it out.)


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia






Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

KHMan
In reply to this post by Jean-Luc Jumpertz-2
On 1/19/2018 11:53 PM, Jean-Luc Jumpertz wrote:
> Frankly, this proposal makes sense, and I thinks bashers should read it carefully before criticizing it with that much energy… :-)
>
> - Yes, having a single type of structured data is intellectually elegant, but it brings lots of subtleties that are not easy to understand for Lua newcomers.
> - Yes, tables with holes are hell (see the number of discussions on this list about ipairs or about the len operator ;-)
> - Yes, the "table" library is only related to sequences.
>
> So thanks, Elias for having taken the time to write this! :-)

I'm not real enthusiastic about an array type. My personal opinion
of course.

(I don't think there are perfect vararg schemes either. Dots are
fine.)

I think Lua newcomers should not be the ones dictating the shape
or direction of Lua. Do we need to mollycoddle Lua newcomers?
Coders can't handle complexity? They are coders?

They need free their minds of internal blockages. :-) :-)


>> Le 19 janv. 2018 à 11:26, Elias Hogstvedt wrote:
>>
>> In my experience with teaching other people Lua, a lot of time is spent explaining the differences between tables and arrays. There’s confusion about the length operator, pairs vs ipairs, performance difference, holes in tables, etc. The entire table library also only makes sense on tables that are treated as arrays and causes undefined behavior when used on tables.
>>
>> So to solve this I would simply add an array type to Lua which would help distinguish between tables and arrays. To distinguish our new array type from arrays in other languages that start from 0 and can only contain a certain type of value we can just call it a "list" instead.
>>
>> Since all the table functions in Lua only work or make sense on tables that are treated as lists we simply rename _G.table to _G.list. The list object should __index to _G.list so it's possible to do “mylist:insert(2)”
>>
>> Now that we have no table library we can create one with functions that only made sense on tables instead.
>>      table.get/setmetatable, table.rawget/set, table.rawequal, table.next, table.rawlen, table.pairs ( ? )
>>      
>> The length operator on tables would no longer work unless we set a metatable on the table with the length operator.
>>
>> _G.ipairs would no longer be needed and so using pairs on lists would ensure correct order while on tables it would not. We can also put _G.pairs in _G.list.pairs to allow the syntax "for i,v in mylist:pairs() do"
>>
>> I believe this would simplify and make the language easier to understand.
>


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia



Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Elias Hogstvedt
I do have a bias towards newcomers and being interested in a language that is easy to learn (as Lua is what I tend to teach)
But I think this is mostly an ambiguity problem not a complexity problem. At least I would think in Lua, complexity should come from the software you write and not the language itself.

On Fri, Jan 19, 2018 at 5:38 PM, KHMan <[hidden email]> wrote:
On 1/19/2018 11:53 PM, Jean-Luc Jumpertz wrote:
Frankly, this proposal makes sense, and I thinks bashers should read it carefully before criticizing it with that much energy… :-)

- Yes, having a single type of structured data is intellectually elegant, but it brings lots of subtleties that are not easy to understand for Lua newcomers.
- Yes, tables with holes are hell (see the number of discussions on this list about ipairs or about the len operator ;-)
- Yes, the "table" library is only related to sequences.

So thanks, Elias for having taken the time to write this! :-)

I'm not real enthusiastic about an array type. My personal opinion of course.

(I don't think there are perfect vararg schemes either. Dots are fine.)

I think Lua newcomers should not be the ones dictating the shape or direction of Lua. Do we need to mollycoddle Lua newcomers? Coders can't handle complexity? They are coders?

They need free their minds of internal blockages. :-) :-)


Le 19 janv. 2018 à 11:26, Elias Hogstvedt wrote:

In my experience with teaching other people Lua, a lot of time is spent explaining the differences between tables and arrays. There’s confusion about the length operator, pairs vs ipairs, performance difference, holes in tables, etc. The entire table library also only makes sense on tables that are treated as arrays and causes undefined behavior when used on tables.

So to solve this I would simply add an array type to Lua which would help distinguish between tables and arrays. To distinguish our new array type from arrays in other languages that start from 0 and can only contain a certain type of value we can just call it a "list" instead.

Since all the table functions in Lua only work or make sense on tables that are treated as lists we simply rename _G.table to _G.list. The list object should __index to _G.list so it's possible to do “mylist:insert(2)”

Now that we have no table library we can create one with functions that only made sense on tables instead.
     table.get/setmetatable, table.rawget/set, table.rawequal, table.next, table.rawlen, table.pairs ( ? )
     The length operator on tables would no longer work unless we set a metatable on the table with the length operator.

_G.ipairs would no longer be needed and so using pairs on lists would ensure correct order while on tables it would not. We can also put _G.pairs in _G.list.pairs to allow the syntax "for i,v in mylist:pairs() do"

I believe this would simplify and make the language easier to understand.



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia




Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Dirk Laurie-2
In reply to this post by Jean-Luc Jumpertz-2
2018-01-19 17:53 GMT+02:00 Jean-Luc Jumpertz <[hidden email]>:

> Frankly, this proposal makes sense, and I thinks bashers should read it carefully before criticizing it with that much energy… :-)

Frankly, Lua offers enough to address the need for lists,
and I think people who wish to change the language
should study the available mechanisms before proposing
breaking changes.

Let's ask ourselves what is possible with a list class. I'm doing it
in a live session; for the sake of those who want to experiment,
I append the module 'list' and the module 'dclass' on which it depends.

$ lua -l list
Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> x=list(1,2,3,nil,5,nil)
> x
list: 0x1efefc0
> #x
6
> x:concat" "
1 2 3 ⎕ 5 ⎕
> x:insert(5,'foo')
> x:concat" "
1 2 3 ⎕ foo 5

As you can see, this implements a fixed-length list with replacement of nil
by a string. _G.list is a shallow copy of _G.table with a __call metamethod
so that it can create a list object with _G.list as metatable.

(a)
> Since all the table functions in Lua only work or make sense on tables that
> are treated as lists we simply rename _G.table to _G.list. The list object
> should __index to _G.list so it's possible to do “mylist:insert(2)”

No need to tamper with tables. Just tell you newbie to use your custom
'list' class and not call any 'table' functions.

Also, the existing table functions are not well suited to work with
fixed-length lists. For example:

    x=list(1,2,3,nil,5,nil)
    x:remove(2)
2
    x:remove(3)

    x[6]=6
    x:concat" "
stdin:1: invalid value (nil) at index 5 in table for 'concat'

(b)
> Now that we have no table library we can create one with functions that only
> made sense on tables instead.
>     table.get/setmetatable, table.rawget/set, table.rawequal, table.next,
> table.rawlen, table.pairs (?)

No need to tamper with tables. Just tell your newbie to use your custom
'list' class and not call any 'table' functions.

(c)
> The length operator on tables would no longer work unless we set a metatable
> on the table with the length operator.

No need to tamper with tables. Just tell you newbie to use your custom
'list' class and not call any 'table' functions.

(d)
> _G.ipairs would no longer be needed and so using pairs on lists would ensure
> correct order while on tables it would not. We can also put _G.pairs in
> _G.list.pairs to allow the syntax "for i,v in mylist:pairs() do"

No need to tamper with tables. Just tell you newbie to use your custom
'list' class and not call any 'table' functions.

(e)
> The list object would be constructed with the syntax [a,b,c] instead of
> {a,b,c} and can contain any value. However list keys are strictly numbered
> and ordered.

Is [a] a one-element list? Will fct[a,b,c] call fct with the list
[a,b,c] as argument
or will it be necessary to write f([a,b,c])?

(f)
> "mylist = table.tolist(tbl)"  -  for converting table to list if the table
> is valid.
Rather
   mylist = list.copy(tbl)

> "mylist = []"  -  to create a dynamically sized list.
> "mylist = [1,2,3,4,nil,6]"  -  to create a list that is 6 in length.

So a fixed-length empty list can't be constructed?

(g)
> Var args become a list object. Because of this I think "..." should be
> replaced with @. Here are some lua examples with the old method on top.

Let's wait for Lua 5.4. The grapevine message is that '...' will be revamped.

Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Dirk Laurie-2
2018-01-19 19:46 GMT+02:00 Dirk Laurie <[hidden email]>:

> I append the module 'list' and the module 'dclass' on which it depends.

dclass.lua (2K) Download Attachment
list.lua (504 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Elias Hogstvedt
Dirk, I think you are msising the point here a little bit. Your entire reply is just "it can be done in lua already so there's no point" but that's not what this is about. I know that this can be done in Lua and it's personally not a very big deal for me that Lua behaves like this. If anything, it will be a burden if Lua changes its syntax because it means it'll break all the previous code I've written the last 10 years.

I'm trying to think "outside of the box" a little bit and see the language from a new perspective. It's more of a fun exercise than anything.

As for the array length, it should be dynamic because as you said fixed size would cause issues.

On Fri, Jan 19, 2018 at 6:48 PM, Dirk Laurie <[hidden email]> wrote:
2018-01-19 19:46 GMT+02:00 Dirk Laurie <[hidden email]>:

> I append the module 'list' and the module 'dclass' on which it depends.

Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

szbnwer@gmail.com
In reply to this post by KHMan
hi all! :)

i think lua have the shortest learning curve of all the languages that
im familiar with (except bf and whitespace :D however whenever youve
done with learning of the language everything else is just art and as
easy as pushing buttons - or maybe im wrong about it)

i think that lua is simple and easy with the right guidance for a
fresh meat in the world of codes, but mostly i suggest them to learn
something else before starting lua to see and appreciate the beauty of
the language. ive felt lucky with my previously achieved knowledge,
and made things cleaner for some stuffs ive learnt before.

i dont think that your proposal will make lua that much easier, maybe
a bit more easy to see the difference and find the right place for
whatever anyone is searching for. probably it can be a bit more
optimized. this can be good, but on the contrary maybe it can make
sometimes those stuffs harder that accept both lists and tables, like
a dump and like how we already have to count with nondefault
metatables for a lotsa things. so it can optimize and can make the
opposite all for speed size and readability, but in most cases i think
it can be good.

on the contrary i deeply like the flexibility that comes with this
combination. as i already told you 1-2 times back in time, that i came
from python land, where are array, tuple and dict types, and its fine
that i can instantly select the best for a special purpose. combining
them and making universal stuffs for them have never made my life
easier. we have to do something for this and that or convert on the
fly (i think thats expensive). whatever works on hash tables those
works on arrays, but with tuples dicts and arrays with different
usecases, handlers and rulesets making universal stuffs harder, and i
like those the most. it is still possible to make arrays accepted
everywhere where mainly hash tables are expected, but makes some
complexity in the implementation of lua itself i think. i balk
metamethods for the same reason til i have no reason to use any, even
if i really like that lua have this possibility, just i have the
intention that a lotsa ppl overusing them, however its totally legit
for much cases.

combined array and hash table is a selling point for me. i think
lua5.1 is enough for everything by its knowledge, like i dont feel it
needs anything more than optimization that luajit does well (the
best?!) however i like tablifying(?ftw) things around, and goto, id
even like to see preprocessor and func defs for lj ffi, but there is a
preprocessor out there that i dont know the quality, and just followed
some links from lj list i think (graphics binding) and found a tcc
binding, so it seems like everything is given. i was afraid for a long
while about floats as array keys and that they wont ever become
precise, but ive learnt that floats have an assembly lvl setup for
rounding (upwards downwards or nearest) so this way i understood why
its enough to floor(/ceil?) it to be the right array key instead of an
another one or a hash key - but correct me if im wrong about this! :)
and lj have cdata, so i have integers in case of need. so after all i
generally dont feel the need of change, but ive seen kinda good news
by the time, even stuffs like i disliked when came up. i think the
best is to not try to give it a different path but crystallizing what
it is already.

most proposals are like pushing lua into the direction of python like
give a fixed form for everything and give it a s#itload of sugar, and
i dont really like those. (its not straightly about python, just i
know that well enough to use for an example but i could have much
other examples as well, just weigh stoursoup for c++, ive seen a huge
amount of variations maybe for fibonacci or factorial in haskell, php
have a tool for everything (actually i like php too), and i believe
no1 ever read through msdn for c# nor java docs, ruby on rails,
moonscript and coffeescript have too much sugar for me - but i dont
see enough from these 3 to be sure that my words are legit for them,
and i dont know what to say about javascript, however i like that as
well, except when not :D ) so back to python (that have kinda much
everythin of those previously listed) i see them as opposed roadmaps,
and i like to use tools with batteries included, i liked python very
much back in time, before lua and before i couldnt find the perfect
toolset when the 2.x 3.x break happened, and i can understand how this
makes it popular... however i like such things only for working, but
not for myself. for myself i want flexible easy to use lightweight
powerful stuffs, and lua (or luajit) is the nearest to my hearth of
all the languages cuz the deepest simplicity in every aspect related
to others. the most im thinking about how it would be like with {} for
blocks, but that would make mess with tables, so its fine to have one
more char for the 'end'.

what im afraid the most is any change that would break compatibility
between lua versions, like now there are so much libs that can work
with lua5.1-5.3+lj2.0-2.1 and this is a very good stuff, but on the
contrary i think all this is mainly cuz lj still mostly at 5.1, but
the kawlest features from later lua versions are already available. im
very very interested where all these gonna lead the world of lua, and
im a bit afraid as well that it will take the path of python 2.x 3.x
break that still deeply dividing it... rip python.

btw i dont think its hard to explain the differences through a well
written set of dummy examples maybe with a one liner description

i wont read back what i wrote cuz i have to work, but probably i could
write some good thoughts, so feel free to ask back for any part of it,
and sorry!!!

and all the bests for every1 around! :)

Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Elias Hogstvedt
In reply to this post by Grey Knight-2
Hi Grey Knight, (your email is marked as spam here)

I'm not looking for a language replacement. Lua is working perfectly fine for me. This is a rough proposed change that would hopefully solve many of the confusion around tables while at the same time reduce the complexity of Lua. (by reducing the complexity around varargs and more subjectively perhaps the ambiguity around tables vs arrays)



On 19 Jan 2018 13:28, "Grey Knight" <[hidden email]> wrote:
On Friday, January 19, 2018, 12:23:26 PM GMT, Elias Hogstvedt <[hidden email]> wrote:
> Yes it will break everything, so I don't really expect this to be
> implemented. Perhaps a new language?
> If you can imagine a new language or be okay with breaking changes, do you
> think these changes make sense?


Hi Elias,

I think that what you are looking for is a language with stronger typing than Lua has.  In such a language I think your expectations would be valid ones to have, it's just that Lua prefers to take a more "duck typing" approach to dealing with different interpretations of tables.

You mentioned the predominant "list" and "dictionary" interpretations of table, but we can also use them as objects, or classes, or even modules!

You should try some languages with stronger typing and see if they meet your needs well.

--
GK

Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Dibyendu Majumdar
In reply to this post by Elias Hogstvedt
Hi Elias

On 19 January 2018 at 10:26, Elias Hogstvedt <[hidden email]> wrote:
> In my experience with teaching other people Lua, a lot of time is spent
> explaining the differences between tables and arrays. There’s confusion
> about the length operator, pairs vs ipairs, performance difference, holes in
> tables, etc. The entire table library also only makes sense on tables that
> are treated as arrays and causes undefined behavior when used on tables.
>
> So to solve this I would simply add an array type to Lua which would help
> distinguish between tables and arrays.

I think the Lua hybrid table/array concept is one of the defining
characteristics of Lua. Any change to that would I suspect be
unacceptable to the Lua team.

My personal view is that it would have been better to have distinct
array and table types. The syntactic simplicity of having only one way
of creating an aggregate type is of course very nice, but the price of
the simplicity in syntax is a more complex data type that is (I agree)
harder to understand and use correctly.

If you want an array type I am afraid you will have to create your own
fork of Lua or a new language.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: A proposal for the confusing pseudo table ≈ array concept

Jennifer Elliott
In reply to this post by Elias Hogstvedt
Why not? 


On Fri, Jan 19, 2018 at 5:23 AM, Elias Hogstvedt
Yes it will break everything, so I don't really expect this to be implemented. Perhaps a new language?

If you can imagine a new language or be okay with breaking changes, do you think these changes make sense?

On Fri, Jan 19, 2018 at 1:01 PM, Dirk Laurie <[hidden email]> wrote:
2018-01-19 12:26 GMT+02:00 Elias Hogstvedt <[hidden email]>:

(a)
> Since all the table functions in Lua only work or make sense on tables that
> are treated as lists we simply rename _G.table to _G.list. The list object
> should __index to _G.list so it's possible to do “mylist:insert(2)”

(b)
> Now that we have no table library we can create one with functions that only
> made sense on tables instead.
>     table.get/setmetatable, table.rawget/set, table.rawequal, table.next,
> table.rawlen, table.pairs ( ? )

(c)
> The length operator on tables would no longer work unless we set a metatable
> on the table with the length operator.

(d)
> _G.ipairs would no longer be needed and so using pairs on lists would ensure
> correct order while on tables it would not. We can also put _G.pairs in
> _G.list.pairs to allow the syntax "for i,v in mylist:pairs() do"

(e)
> The list object would be constructed with the syntax [a,b,c] instead of
> {a,b,c} and can contain any value. However list keys are strictly numbered
> and ordered.

(f)
> "mylist = table.tolist(tbl)"  -  for converting table to list if the table
> is valid.
> "mylist = []"  -  to create a dynamically sized list.
> "mylist = [1,2,3,4,nil,6]"  -  to create a list that is 6 in length.

(g)
> Var args become a list object. Because of this I think "..." should be
> replaced with @. Here are some lua examples with the old method on top.

> I believe this would simplify and make the language easier to understand.

Seven breaking changes. Not merely breaking some programs that have
worked unchanged since Lua 2.1, breaking all of them.

Whatever you call this new language of yours, please don't include the
letters L,U,A consecutively anywhere in its name.


1234