Future implementation of table support and Initializer List

[stefanos82]

In the following code

require 'io'
require 'iterators'

local a: []uint32 = {}

io.printf("type(a): %s\n", #[tostring(a.type)]#)

for k,v in ipairs(a) do
  io.printf("key: %3d <::> value: %3d\n", k, v)
end

can be seen the use of initializer list with an inferred sized array.

My question is, when table gets implemented, will there be a workaround to avoid ambiguity between table and initializer list?

For instance, in the above code we might have something like

require 'io'
require 'iterators'

local a: []uint32 = {}
local tbl: table = {} -- this should work as expected; it knows its type

-- how will this behave, assuming `table` has been implemented?
local tblauto : auto = {}

io.printf("type(a): %s\n", #[tostring(a.type)]#)

for k,v in ipairs(a) do
  io.printf("key: %3d <::> value: %3d\n", k, v)
end

[stefanos82]

By the way, is it possible to improve the output for -T, --more-timing?

The code above produces the following output

parsed tmp.nelua (2.3 ms)
preprocessed tmp.nelua (0.1 ms)
parsed /usr/local/lib/nelua/lib/io.nelua (2.6 ms)
preprocessed /usr/local/lib/nelua/lib/io.nelua (1.0 ms)
parsed /usr/local/lib/nelua/lib/filestream.nelua (2.3 ms)
preprocessed /usr/local/lib/nelua/lib/filestream.nelua (1.3 ms)
parsed /usr/local/lib/nelua/lib/stringbuilder.nelua (1.7 ms)
preprocessed /usr/local/lib/nelua/lib/stringbuilder.nelua (1.3 ms)
parsed /usr/local/lib/nelua/lib/span.nelua (0.4 ms)
preprocessed /usr/local/lib/nelua/lib/span.nelua (0.3 ms)
parsed /usr/local/lib/nelua/lib/iterators.nelua (0.4 ms)
preprocessed /usr/local/lib/nelua/lib/iterators.nelua (0.5 ms)
parsed /usr/local/lib/nelua/lib/memory.nelua (1.1 ms)
preprocessed /usr/local/lib/nelua/lib/memory.nelua (0.8 ms)
parsed /usr/local/lib/nelua/lib/allocators/default.nelua (0.1 ms)
preprocessed /usr/local/lib/nelua/lib/allocators/default.nelua (0.1 ms)
parsed /usr/local/lib/nelua/lib/allocators/gc.nelua (3.3 ms)
preprocessed /usr/local/lib/nelua/lib/allocators/gc.nelua (1.7 ms)
parsed /usr/local/lib/nelua/lib/allocators/general.nelua (0.2 ms)
preprocessed /usr/local/lib/nelua/lib/allocators/general.nelua (0.3 ms)
parsed /usr/local/lib/nelua/lib/allocators/allocator.nelua (1.2 ms)
preprocessed /usr/local/lib/nelua/lib/allocators/allocator.nelua (1.1 ms)
parsed /usr/local/lib/nelua/lib/hashmap.nelua (1.7 ms)
preprocessed /usr/local/lib/nelua/lib/hashmap.nelua (1.0 ms)
parsed /usr/local/lib/nelua/lib/hash.nelua (0.4 ms)
preprocessed /usr/local/lib/nelua/lib/hash.nelua (0.6 ms)
parsed /usr/local/lib/nelua/lib/vector.nelua (0.7 ms)
preprocessed /usr/local/lib/nelua/lib/vector.nelua (0.5 ms)
parsed /usr/local/lib/nelua/lib/string.nelua (7.5 ms)
preprocessed /usr/local/lib/nelua/lib/string.nelua (5.2 ms)
parsed /usr/local/lib/nelua/lib/sequence.nelua (1.0 ms)
preprocessed /usr/local/lib/nelua/lib/sequence.nelua (0.7 ms)
parsed /usr/local/lib/nelua/lib/detail/patternmatcher.nelua (3.5 ms)
preprocessed /usr/local/lib/nelua/lib/detail/patternmatcher.nelua (2.3 ms)
analyzed (107.1 ms)
analyzed (13.3 ms)
analyzed (11.2 ms)
analyzed (9.3 ms)
analyzed (16.5 ms)
analyzed (17.1 ms)
analyzed (8.7 ms)
type(a): array(uint32, 0)

The analyzed output is not clear at all which file was the heaviest and which the lightest.

Can we extend the aforementioned flag to include each analyzed file with pull path?

[stefanos82]

Yeah, but this output does not make any sense, thus some full path could help a bit:

analyzed (107.1 ms) -- which file is this?
analyzed ( 13.3 ms) -- what about this one?
analyzed ( 11.2 ms) -- or this one...?
analyzed (  9.3 ms) -- ...
analyzed ( 16.5 ms) -- etc...
analyzed ( 17.1 ms)
analyzed (  8.7 ms)

[edubart]

Yeah, but this output does not make any sense, thus some full path could help a bit:

analyzed (107.1 ms) -- all files
analyzed ( 13.3 ms) -- all files
analyzed ( 11.2 ms) -- all files
analyzed (  9.3 ms) -- all files
analyzed ( 16.5 ms) -- all files
analyzed ( 17.1 ms) -- all files
analyzed (  8.7 ms) -- all files

It is like this, to make clear.

[stefanos82]

Waaaaaaaaait a minute...

Is it like phase 1, phase 2, phase ...(N-1) until it analyzes all possible AST branching?

[edubart]

Is it like phase 1, phase 2, phase ...(N-1) until it analyzes all possible AST branching?

Yes.

[stefanos82]

Now I get it! Nice 💯

[edubart]

how will this behave, assuming table has been implemented?

When tables get implemented, the following will be equivalent:

local t = {}
local t: auto = {}
local t: table = {}

That is, untyped initializer lists will be assumed to be tables, thus we will have similar semantics as Lua when using {}.