Hacker News Reader

Comment by palish | Hacker News Reader

Certainly. I didn't mean to deride anyone's work with the comparison. I meant, some of the implementation decisions seem arbitrary, and seem like they were made "for the sake of being different".

For example, Lua's use of two dashes for line comments, and --[[ and --]] for block quotes. That lets you remove the first --[[ in a block quote without causing the program to break, because the "closing" block quote is commented out at that point (because --]] is a comment at that point). But really, that's so different from other languages that it seems like a liability rather than an asset. That's what I meant by "not necessarily beautiful". It is definitely beautiful in certain other aspects, though.

Also, if I were writing a scripting language, I'd love for it to be "like a prostitute". Even if nobody respected it, everyone would be using it.

View on HN

the [[ and ]] are used for literal/multiline strings, so they make sense in block quotes. and you don't have to end the block with --]]. ]] is fine, which is the only thing i've ever used since it would never have occurred to me, especially as an anemic commenter, to use that quoting trick

the [[ and ]] can be extended to nest strings/comments like so:

  --[==[
  function add( a, b )
      --[[
      return a + b
      ]]
      return a - b
  end
  ]==]

you can use [=[ ]=], [====[ ]====] etc

With the number of equals matching on the opening and closing comments.

> Even if nobody respected it, everyone would be using it.

By that metric, PHP is the scripting language for you. ;)

The double hyphen comment is used elsewhere. SQL comes to mind.

In that vein, don't array indexes start with 1, instead of 0? Erlang does that too, and it's a bit weird, but not a show stopper.

Right, exactly.

Lua doesn't even really have arrays per se, but rather "tables," which are a light, flexible data structure somewhat similar to Javascript's objects. You're free to index tables starting with 0 if you really want to, but the convention in Lua is to use 1.

This is slightly less true than it used to be. The table length "#" operator returns the index of the largest integer key continuously reachable from the index at 1. (i.e. there can be no integer keys with nil values in between). This, as well as a handful of standard library operators, rely on the index-from-1 convention.

Tables in Lua can be thought of as discrete mappings of any value as key, to any value as value. The reference implementation happens to have the property that if you index from 1 upwards by increments of 1 that all of those values are kept in a single C array which is then subscripted in the usual fashion. It's a handy thing to know when you decide how to lay out your data. The "dictionary" portion of the table only springs into existence when something is actually inserted into it.

Actually if I understand correctly, an empty Lua table is basically just a pointer to a minimal structure in memory, so it can be used for identity comparisons and so on where only uniqueness is necessary, rather than a full array+dict functionality with the associated memory overhead.

Lua tables are extremely flexible and powerful. Especially when combined with the "metatable" concept.

The table length "#" operator returns the index of the largest integer key continuously reachable from the index at 1. (i.e. there can be no integer keys with nil values in between). This, as well as a handful of standard library operators, rely on the index-from-1 convention.

That does not always hold true. The '#' operator is weird. Here is an example:

  Lua 5.1.3  Copyright (C) 1994-2008 Lua.org, PUC-Rio
  > x = {1,2,3}
  > x[1] = nil

ipairs() stops at the first nil, as expected:

  > for i,v in ipairs(x) do print(i,v) end

However #x is inaccurate now:

  > print(#x)
  3

Luckily, we can always see all the values with pairs():

  > for k,v in pairs(x) do print(k,v) end
  2     2
  3     3

And watch what happens when we add a single non-integer key to the array:

  > x.a = 10
  > print(#x)
  1
  >

Looking at http://www.lua.org/source/5.1/ltable.c.html#luaH_getn I think the problem lies in the assumption in luaH_getn that if the table doesn't have an 'hash' part then it also doesn't have any gaps.

   /*
   ** Try to find a boundary in table `t'. A `boundary' is an integer index
   ** such that t[i] is non-nil and t[i+1] is nil (and 0 if t[1] is nil).
   */
   int luaH_getn (Table *t) {
     unsigned int j = t->sizearray;
     if (j > 0 && ttisnil(&t->array[j - 1])) {
       /* there is a boundary in the array part: (binary) search for it */
       unsigned int i = 0;
       while (j - i > 1) {
         unsigned int m = (i+j)/2;
         if (ttisnil(&t->array[m - 1])) j = m;
         else i = m;
       }
       return i;
     }
     /* else must find a boundary in hash part */
     else if (t->node == dummynode)  /* hash part is empty? */
       return j;  /* that is easy... */
     else return unbound_search(t, j);
   }

I did not get the same behavior as you when I tried this just now - rather, I had:

  > x.a = 10
  > print(#x)
  0
  >

Which makes more sense than 1. At the same time, 3 is also a valid value of #x, because it is the integer index of a value directly preceding an index with a nil value.

This behavior has been hashed over on the mailing list multiple times... the exact wording of the documentation allows for it but it's not exactly what people expect of the length operator.

The length of a table t is defined to be any integer index n such that t[n] is not nil and t[n+1] is nil; moreover, if t[1] is nil, n can be zero. For a regular array, with non-nil values from 1 to a given n, its length is exactly that n, the index of its last value. If the array has "holes" (that is, nil values between other non-nil values), then #t can be any of the indices that directly precedes a nil value (that is, it may consider _any_ such nil value as the end of the array). -- From the manual

My expectation is that there will be some changes to the handling of the # operator in 5.2 increasing its usefulness and allowing it to be overridden via metatables for user-defined types.

In any case, this is one of the few currently ugly corners of the language itself. Another would be the handling of destructuring varargs via the select(...) function, which can be really funky.

I did not get the same behavior as you when I tried this just now

What version of lua did you use? Perhaps my version's # is buggy in addition to being weird.

This is one of the things expected to be fixed in 5.1.4, IIRC.

# works with an array-style table (consecutive integer keys, starting from 1) and not hash-style tables. Once you're familiar with Lua, you rarely confuse them -- they tend to be used very differently. Using the same variable type is mostly an efficiency trick.

I agree that counting from 1 is kind of annoying, but part of their reasoning was that Lua is targeted as a scripting language for niches that can include people who don't really program. They tried to keep "weird" programming stuff from obfuscating the tiny amount necessary for writing config or data files in Lua. It has coroutines, lexical scope, metatables, etc. when you use it for real programming, but they don't get in the way when you don't need them.

For example, from the data file for my laptop's wifi script:

   device="ral0"
   sudo=true

   Network { key="home", nwid="barbelith", wpa="..." }
   Network { key="sparrows", nwid="The Sparrows" }
   Network { key="schulers", nwid="schuler-alpine" }

  Lua 5.1.3  Copyright (C) 1994-2008 Lua.org, PUC-Rio
  >

This is using the Lua console installed by the the (excellent) Lua for Windows package.

personally i think 0-indexing is weird. it makes sense as a pointer offset in lower-level languages. but in higher-level languages we have the opportunity to index the first element by the number 1, the second by the number 2, and so on instead of having to do that little -1 every time which is something that has to be learned

There is a short note by Dijkstra about this

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...

that's really weird. was it written at a time when most programming was for scientific purposes? i don't know my comp history

if i parsed it correctly, he is saying that things should be 0-indexed because a particular mathematical notation corresponding to it is more sensical, but i don't see what mathematical notation has to do with programming notation, both of which are man-made, arbitrary, and for different purposes, such that reasoning about either with respect to the other is imo fallacious

he compares subscript ranges in a notation where 0-indexing appears to be better, but choosing a different notation (such as b in his examples) makes it look better for 1-indexing ( 0 < i <= N versus -1 < i <= N-1 )

Here is the important part:

    Extensive experience with Mesa has shown that 
    the use of the other three conventions has been
    a constant source of clumsiness and mistakes

0-based indexing is not something you can rigorously prove to be better.

One advantage of 0-based is that using array[mod(i, length)] works. It mostly seems to me like 0-based vs. 1-based is a relatively arbitrary decision, though. Each just leads to fencepost errors in different places.

if i read correctly, that's talking about the mathematical notations, not arrays or the indexing of such, of that programming language

and while we're considering sources of "clumsiness and mistakes," 0-indexing is an exceptional candidate, from my experiences helping a friend learn C++ and my own memories treading through those early days

i look at it from the perspective of usability

In C++ and C the iteration idiom almost always looks like:

  for (elementIndex = first-element; elementIndex < indexAfterLastElement; elementIndex++) {
  ... 
  }

That is, writing the equivalent of the mathematical notation:

  firstElementIndex <= elementIndex < indexAfterLastElement

Two advantages of that idiom:

The first one is that indexAfterLastElement - firstElementIndex equals the number of elements being scanned.

The second advantage (which is the most debatable, and personal) is that the initial boundary condition is trivial (it's the first element) and the end boundary condition is natural i.e. just look past the element you are looking at whether there is a next one. That's what Dijkstra is talking about when telling the example of the student who would not look past the end of the page.

I used the epithet natural because for most of the objects we interact with, the end is not part of the object, rather it is the transition in between the last element and nothingness.

Now that said (in too many words) if you compare 1-based arrays and 0-based arrays you have:

  for (i = 0; i < N; i++) {
  ...
  }

  for (i = 1; i < N + 1; i++) {
  ...
  }

Both would be acceptable. However 0 based arrays have the advantage of giving i two meanings:

  1. the index of the current element
  2. the number of elements scanned so far.

At the end of the iteration, i also conveniently contains the number of elements having been scanned. Which can be useful in algorithms where there is an extra condition which might let you leave the iteration early.

This to me is the most important part, zero-based indexing is more expressive.

These are some of the best arguments for 0-based indexing, and I agree that these are very useful properties. In my day-to-day programming though, the 1-based indexing has some (admittedly, less math-based) advantages too. For instance when I have an array my brain appreciates the simplicity of the "oh, this array has 10 elements. What's the last element? Number 10! Yay, that was easy" thought process.

In many cases I don't care about specifying boundary conditions at all; I will just use something along the lines of

  for i, v in ipairs(t) do something_interesting(i, v) end

or even just a map or fold or some other iteration technique where I'm not explicitly specifying boundary conditions. If I'm implementing a heap or some other data structure which uses calculations to interact with an array I will be double-checking my math anyway because I don't trust myself to get it right the first time, 0-based indexing or not ;)

The last element of an array is foo[-1] regardless of it's length. :-) And try implementing a circular buffer using an array of N elements with 1-based indexing and then 0-based. Sorry in advance for the loss of hair due to the former.

you mean like array[mod(i, length) + 1]

Reply on news.ycombinator.com