[Bug] Wording

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug] Wording

Soni "They/Them" L.
The manual says "The type table implements associative arrays, that is,
arrays that can be indexed not only with numbers, but with any Lua value
except nil and NaN."

I believe this would be better worded as "The type table implements
associative arrays, that is, arrays that can have as indices not only
numbers, but any Lua value except nil and NaN."

The truth is, v=t[nil] and t[nil]=v both are valid Lua code, except the
latter errors because *a nil index cannot exist*. More specifically, you
cannot *create* a nil index, but you can check for its existence. Same
for NaN.

This wording more accurately represents the reference implementation,
and I believe this is intended behaviour.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: [Bug] Wording

Russell Haley
Can a table be used as an index? What 'value' does that have (i.e the serialized table?)

Curse my BlackBerry for not having lua! :)

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Soni L.
Sent: Tuesday, May 2, 2017 4:02 PM
To: Lua mailing list
Reply To: Lua mailing list
Subject: [Bug] Wording

The manual says "The type table implements associative arrays, that is,
arrays that can be indexed not only with numbers, but with any Lua value
except nil and NaN."

I believe this would be better worded as "The type table implements
associative arrays, that is, arrays that can have as indices not only
numbers, but any Lua value except nil and NaN."

The truth is, v=t[nil] and t[nil]=v both are valid Lua code, except the
latter errors because *a nil index cannot exist*. More specifically, you
cannot *create* a nil index, but you can check for its existence. Same
for NaN.

This wording more accurately represents the reference implementation,
and I believe this is intended behaviour.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.



Reply | Threaded
Open this post in threaded view
|

Re: [Bug] Wording

Charles Heywood
When a table is used as an index, the value is the reference to the table. You can't use `t = {[{1, 2}] = "hello world"}; print(t[{1, 2}])`, you have to use the same table when originally assigning the index.

On Tue, May 2, 2017 at 6:55 PM Russell Haley <[hidden email]> wrote:
Can a table be used as an index? What 'value' does that have (i.e the serialized table?)

Curse my BlackBerry for not having lua! :)

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Soni L.
Sent: Tuesday, May 2, 2017 4:02 PM
To: Lua mailing list
Reply To: Lua mailing list
Subject: [Bug] Wording

The manual says "The type table implements associative arrays, that is,
arrays that can be indexed not only with numbers, but with any Lua value
except nil and NaN."

I believe this would be better worded as "The type table implements
associative arrays, that is, arrays that can have as indices not only
numbers, but any Lua value except nil and NaN."

The truth is, v=t[nil] and t[nil]=v both are valid Lua code, except the
latter errors because *a nil index cannot exist*. More specifically, you
cannot *create* a nil index, but you can check for its existence. Same
for NaN.

This wording more accurately represents the reference implementation,
and I believe this is intended behaviour.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.



--
--

Software Developer / System Administrator
Reply | Threaded
Open this post in threaded view
|

Re: [Bug] Wording

Martin
In reply to this post by Soni "They/Them" L.
On 05/02/2017 04:01 PM, Soni L. wrote:
> The truth is, v=t[nil] and t[nil]=v both are valid Lua code, except the
> latter errors because *a nil index cannot exist*. More specifically, you
> cannot *create* a nil index, but you can check for its existence. Same
> for NaN.

Did you tried metatables to override this behavior?

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [Bug] Wording

Dirk Laurie-2
In reply to this post by Soni "They/Them" L.
2017-05-03 1:01 GMT+02:00 Soni L. <[hidden email]>:

> The manual says "The type table implements associative arrays, that is,
> arrays that can be indexed not only with numbers, but with any Lua value
> except nil and NaN."
>
> I believe this would be better worded as "The type table implements
> associative arrays, that is, arrays that can have as indices not only
> numbers, but any Lua value except nil and NaN."

This is a [Bug]??

Reply | Threaded
Open this post in threaded view
|

Re: [Bug] Wording

Jonathan Goble
On Wed, May 3, 2017 at 1:43 AM Dirk Laurie <[hidden email]> wrote:
2017-05-03 1:01 GMT+02:00 Soni L. <[hidden email]>:

> The manual says "The type table implements associative arrays, that is,
> arrays that can be indexed not only with numbers, but with any Lua value
> except nil and NaN."
>
> I believe this would be better worded as "The type table implements
> associative arrays, that is, arrays that can have as indices not only
> numbers, but any Lua value except nil and NaN."

This is a [Bug]??

Bugs are not restricted to only code. Documentation can also have bugs, such as when it is not clear on something or gives incorrect information.
Reply | Threaded
Open this post in threaded view
|

Re: [Bug] Wording

Oliver Kroth
In reply to this post by Russell Haley

> Can a table be used as an index? What 'value' does that have (i.e the serialized table?)
>
Yes. The value is the reference to the table; tostring() gives "table:
0x*****" with ** being the hexadecimal value of the memory address.

--
Oliver

Reply | Threaded
Open this post in threaded view
|

Re: [Bug] Wording

Dirk Laurie-2
In reply to this post by Jonathan Goble
2017-05-03 7:46 GMT+02:00 Jonathan Goble <[hidden email]>:

> On Wed, May 3, 2017 at 1:43 AM Dirk Laurie <[hidden email]> wrote:
>>
>> 2017-05-03 1:01 GMT+02:00 Soni L. <[hidden email]>:
>>
>> > The manual says "The type table implements associative arrays, that is,
>> > arrays that can be indexed not only with numbers, but with any Lua value
>> > except nil and NaN."
>> >
>> > I believe this would be better worded as "The type table implements
>> > associative arrays, that is, arrays that can have as indices not only
>> > numbers, but any Lua value except nil and NaN."
>>
>> This is a [Bug]??
>
>
> Bugs are not restricted to only code. Documentation can also have bugs, such
> as when it is not clear on something or gives incorrect information.

Well, if "index with" rather than "can have index" is deemed a bug,
then Nicolas Bourbaki is alive and well and hyperactive on Lua-L.

Reply | Threaded
Open this post in threaded view
|

Re: [Bug] Wording

Gé Weijers

On Wed, May 3, 2017 at 1:26 AM, Dirk Laurie <[hidden email]> wrote:
2017-05-03 7:46 GMT+02:00 Jonathan Goble <[hidden email]>:
> Bugs are not restricted to only code. Documentation can also have bugs, such
> as when it is not clear on something or gives incorrect information.

Well, if "index with" rather than "can have index" is deemed a bug,
then Nicolas Bourbaki is alive and well and hyperactive on Lua-L.


Not all behavior HAS to be defined. Almost all programming language definitions (like C's) leave things undefined or implementation defined. This allows the implementation some freedom. So if you want defined behavior from associative arrays in Lua don't use nil or any of the NaN values as an index. Lua 5.3.5 could behave differently without breaking the spec.

Other things are not fully defined either: if you use the '#' operator on a table you get a 'border'. If more than one border exists the implementation can give you *any* border. There's no requirement that two runs of the same program produce the same results. You will likely see different behaviors depending on which version of the C compiler and/or standard libraries you're using, the settings of the Lua garbage collector, and plenty more things.

I would not call this a bug.

--
--