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

[Elias Hogstvedt <eliashogstvedt@...>]

> The phrase "an ambiguity problem" is wholly negative and sets the issue up for failure.

Yes because I believe it's an ambiguity problem for the reasons I've stated earlier. Where do you draw the lines between a bug, an ambiguity problem and a feature? It feels like you're just saying "Lua currently works well so everything in Lua right now is a feature, you must accept it."

You mentioned you don't like how Lua handles var args for instance. How would you personally deal with them? (honest question)

On Sat, Jan 20, 2018 at 4:21 AM, KHMan <keinhong@gmail.com> wrote:

On 1/20/2018 1:17 AM, Elias Hogstvedt wrote:

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.

Morpheus: You have to let it all go, Neo. Fear, doubt, and disbelief. Free your mind.

Cypher: Everybody falls the first time.


The phrase "an ambiguity problem" is wholly negative and sets the issue up for failure. You have a problem, your mind is not free. Your phrasing then transmits the concepts as 'problems' to those you teach. Hence it goes something like this: "My instructor keeps warning me about this thing, this ambiguity, so my word, he must mean that this Lua has a bad feature that we must swallow, and by golly, it will be tough to swallow..."


Coders should be able to break mental barriers. The table is part of the bedrock of Lua. It's a lookup. NoSQL is a lookup. Google is a lookup. Plenty of folks come around and say, it should be done this way, it should be done that way. Perhaps they have notions of how things should be done and wants to impose their mental limitations on this new thing they are learning.

Let's see. In the 1960s, Fortran and COBOL would be the two greatest computer languages in the whole wide world, the amazing, awesome 21st century future made live. Where does Fortran and COBOL stand now? Where would we be 50 years from now?

We must be able to break these mental barriers to move forward. Must all computer languages have separate types for arrays and hashes? Is it an inviolable design requirement that some coders expect? Free your mind. :-)

On Fri, Jan 19, 2018 at 5:38 PM, KHMan 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