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

Many of us have been 'trained' using standard data structures coursework material. In a way everybody does think arrays and hashes separately -- I think of them separately when using other languages. But that does not short-circuit my brain when I switch mental modes to coding Lua.

I wanted to express that I'm not coming from this angle. Lua is the first language I learned and I've stuck with it for 10 years. I've used some other languages, but it was almost always to make Lua bindings so I can get back to into it. However I've been using LuaJIT the last 5 years with FFI (so I don't have to get out of Lua). So with FFI I've gotten used to dealing with C types inside of Lua and just generally understanding how C works to better communicate with shared libraries or generate bindings for FFI.

Also I've never worked as a programmer and have a lot of freetime. So for me programming is only just for fun and a way of introducing some mental challenge into my daily life.

On Mon, Jan 22, 2018 at 3:36 AM, KHMan <keinhong@gmail.com> wrote:

On 1/22/2018 12:54 AM, Elias Hogstvedt wrote:

While this thread has altered my views on the issue a bit, I'm also starting to wonder if I'm just bored and looking for change.

Another bias I have that I should have mentioned is that I'm using LuaJIT (5.1~2) heavily with FFI so I'm also also seeing this as a future performance benefit. Perhaps it would only help LuaJIT to be a bit more predictable but not PUC Lua so much.

I read Dibyendu posts, they are very useful; eventually if one goes looking for performance, we will prefer or need certain things. But JIT is not one of Lua's design priority. If I wanted pedal-to-the-metal performance, I would make wholesale changes, no question.

It's the same with _javascript_. We threw metric truckloads of resources at it over the years, and amazing JIT implementations have been made. But not close enough to metal. asm.js pops up, then in comes WebAssembly. The dynamism of scripting languages is being steadily being eclipsed by the desire for performance. Maybe everything will end up moving to the kind of scheme we use for GPUs.

Compare stock Lua with these tech, plus a benchmarking culture, of course it will look dowdy. What chance does Lua have when compared to things backed by enormous amounts of resources? Lua is not going to win these kinds of performance benchmarks, but it will still perform very well for a dynamic, scripting language. At some point, it will cease being an apples-to-apples comparison. Which is the 'right' kind of scripting language? They are all good, for their target objectives.

I'd like to create my own language as well with my own ideas. Perhaps I'll learn a thing or two as to why certain desicions are made.

Here is another perspective on tables with more accessible wording: Many of us have been 'trained' using standard data structures coursework material. In a way everybody does think arrays and hashes separately -- I think of them separately when using other languages. But that does not short-circuit my brain when I switch mental modes to coding Lua.

Lua is scripting language, it is more dynamic and malleable than say, compiled languages or languages targeted towards JIT. Lua tables simply sits at a higher abstraction than traditional data structures. That's why I always think of the word 'lookup'. The data structures coursework, those are more at a for-compilation abstraction level (notably, with examples in C/C++/Java.)

Let's say, I have an idea of generational tables. So I implement tables using red-black trees as a back-end option to get always-sorted tables and a no-op when sorting the table. It doesn't change the abstraction that is the Lua table. But well, the table abstraction may not be the ideal thing if one wants (or expects) everything to be boiled down to run in lean and mean machine code close to metal.

On Sun, Jan 21, 2018 at 5:24 PM, Andrew Starks wrote:

Top posting to nobody in particular.

I was arguing something about lengths or arrays at some point.
Some helpful Lua List member kindly pointed something out to me:

Lua does not have sequences. It only has tables.

To put a positive spin on it: Lua has tables as it’s only data
structure, at least as of 5.4, which will eliminate the
limited ... (perhaps helped along by threads like this).

There is nothing that can’t be represented as a table and if
you want something fancy, you have userdata. Adding sequences
solves no problems.

“One data structure” is one of Lucas most important traits. I
recommend learning to enjoy it and to play with that beautiful
limitation.

-Andrew

On Sun, Jan 21, 2018 at 06:15 Petri Häkkinen wrote:

On 21 Jan 2018, at 12.33, Elias Hogstvedt wrote:

I don’t get it. Where’s the ambiguity in e. g. { 1,
2, 3, type = ”int16” } ?

I would say it's ambiguous because I'm not sure if this
is "safe" to do. I've personally never done this and
would put a new table inside the table to hold the
numbers. If this has no side effects then it's more or
less a shortcut for {array = {1, 2, 3}, type = "int16"}

It’s totally safe and there’s a similar example in
Programming in Lua. Section 3.6 in the 2nd edition (I
don’t have the latest edition yet):

polyline = { color=”blue”, thickness=2, npoints=4,
   {x=0, y=0},
   {x=-10, y=0}
   {x=-10, y=1}
   {x=0, y=1}
}

Produces less garbage because there’s no intermediate
table to hold the coordinates array.

Petri

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