all 24 comments

sorted by: hot top controversial new old
[–] 23 points 9 months ago (11 children)

i think the most interesting design detail of lua tables is just glossed over as "nil-holes" in this article. namely, that nil values do not exist. there is no table.delete(key) method, you just zero out the value and the key stops existing. the same thing is true for any variable, if you set it to nil it ceases to be. i find that implementation fascinating.

  • source
  • hideshow 11 child comments
  • [–] 5 points 9 months ago* (last edited 9 months ago) (5 children)

    Except it's ass if you want to do non-destructive data processing of arbitrary structures and your input and output might have null as a value. You can't just know about fields a, b, and c of the table and leave everything else as it is, you need to know the whole structure and make sure you write null in the output for fields that have nil in them.

    Or, more realistically, use libraries that implement null as custom user data.

    Iirc Roberto Ierusalimschy even considered introducing a null value in one of the recent versions, of course confusingly named ‘undefined’ — but changed his mind. Perhaps it's for the better than to have such a backwards name for it.

    To my knowledge, Lisps like Emacs Lisp implement this better: trying to get a value for a nonexistent key will get you nil, but you can still retrieve the list of all keys, including ones that are set to nil.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 9 months ago (4 children)

    yeah that's probably when you should drop down to C.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 3 points 9 months ago (3 children)

    Eh, dkjson implements null as an object with a metatable function that encodes it back as "null". Hopefully it's considered equal to itself in comparisons.

    Dkjson is fast enough for most scripting purposes. OTOH cjson's userdata null is supported by some other libraries that deal with data structures.

    Of course, there's a problem then that various libs may have their own nulls, not equal to each other. There's even a lib that tries to marry some of them.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 9 months ago (2 children)

    interesting! it should be equal since it's always just a pointer to that same table.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 9 months ago (1 child)

    I just never tried, so amn't entirely sure.

    Iirc I needed a json lib on Windows, or was just fed up with compiling things for some reason, and used dkjson instead of cjson. It turned out to be more than adequate, as is pretty typical for Lua-only code. Although it can use the LPeg lib to speed up parsing.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 9 months ago (4 children)

    I assume they did that for performance reasons, because removing entries is slow probably? From user perspective, it would have made it more sense to remove the key instead defining it as nil and then expecting the user to handle the nil. The key does not stop existing, right? I don't program in Lua.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 4 points 9 months ago* (2 children)

    Nil doesn't exist as a value in Lua, because a variable or a field that don't exist or are unassigned are indistinguishable from a nil value, since they all return nil when evaluating. In particular, this leads to the situation that you can't have a table where some of the fields are assigned nil as the value, because those fields effectively don't exist.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 9 months ago (1 child)

    Ah I see, that makes it clear. I guess it is a "good enough" solution where it doesn't matter in real world.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 9 months ago

    I'm guessing it's more of a stylistic choice. Lisps typically work the same way, except they can retrieve the full map structure even if some fields contain nil as the value.

    Unfortunately, Lua's approach hinders exchanging structures with null values with other environments: see my comment here.

  • source
  • parent
  • [–] 1 point 9 months ago

    the key does stop existing, insofar as referring to any name that is not defined in lua results in nil. which includes variables, since they are defined in a global table. i don't actually know what happens internally.

  • source
  • parent
  • [–] 8 points 9 months ago (5 children)

    Such a strange website. Pretty decent content, but just lying around as HTML/js/css files without a coherent layout to tie them all together? Reminds me of good ol' internet.

  • source
  • hideshow 5 child comments
  • [–] 6 points 9 months ago (1 child)

    wdym coherent layout? this thing looks more coherent than any reactwebbloatapp i have seen

    it is also very mobile friendly, no lag while scrolling because react is being the bloated garbage it is

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 9 months ago

    I'm guessing the author didn't want to mess with a framework every time they post, with different page layouts they might've evolved over the years. Though the absence of site-wide navigation is still baffling.

  • source
  • parent
  • [–] 5 points 9 months ago (5 children)

    Experience has shown that having a map as your only data structure is definitely a mistake. It's much better to support real arrays too. I doubt it would have made the implementation significantly more complex either (maybe even simpler for luajit).

  • source
  • hideshow 5 child comments
  • [–] 0 points 9 months ago* (4 children)

    Idk, PHP chugs on splendidly with arrays that combine both arrays and maps. I regret to say that PHP is considerably faster than some better languages like Python and Ruby, and arrays are the workhorse structure there.

    (Like, PHP's approach to FastCGI is that the script's runtime is destroyed after every request and then started anew for the next one, and it still outperforms Python's always-on approach. Of mainstream languages, only Node can compete.)

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 9 months ago (1 child)

    Right but it's fast(ish) in spite of that. It would still be better with separate types.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 9 months ago* (last edited 9 months ago)

    Weird choice of lifestyle to complain about the two fastest scripting languages being ‘fast-ish’. While you complain, the world is using Lua for embedded scripts and game programming, and PHP for the web.

    People straight up write libraries in Lua instead of C, because the performance difference is unnoticeable. But apparently it's only ‘fastish’.

  • source
  • parent