t[ nil ]

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

t[ nil ]

Mark Hamburg-4
What is the expected behavior if one indexes a table with a nil key? I had
thought it was to throw an exception. In fact I feel I've seen an exception
get thrown but maybe not. Now, however, I seem to be getting back nil.

The manual says that nil is an illegal key.

I certainly prefer the definition that says that t[ nil ] is always equal to
nil for any valid table. I just didn't realize that was the case.

Mark

Reply | Threaded
Open this post in threaded view
|

Re: t[ nil ]

Fabio Mascarenhas-2
Hi,

The implementation always returns nil if the key is nil (check luaH_get
in ltable.c).

--
Fabio Mascarenhas

On Fri, May 19, 2006 at 02:06:00PM -0700, Mark Hamburg wrote:

> What is the expected behavior if one indexes a table with a nil key? I had
> thought it was to throw an exception. In fact I feel I've seen an exception
> get thrown but maybe not. Now, however, I seem to be getting back nil.
>
> The manual says that nil is an illegal key.
>
> I certainly prefer the definition that says that t[ nil ] is always equal to
> nil for any valid table. I just didn't realize that was the case.
>
> Mark
>

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: t[ nil ]

Mike Pall-5-2
In reply to this post by Mark Hamburg-4
Hi,

Mark Hamburg wrote:
> What is the expected behavior if one indexes a table with a nil key? I had
> thought it was to throw an exception. In fact I feel I've seen an exception
> get thrown but maybe not. Now, however, I seem to be getting back nil.

Lua 4.x did not allow this. Lua 5.x does.

> The manual says that nil is an illegal key.

But this only means that a table cannot hold a nil key. This does
not imply anything about indexing behaviour.

Well, there's pseudo-code for index and newindex in the Lua 5.1
manual in section "2.8 Metatables". But it relies on the
definitions of rawget() and rawset().

Looking there, the description for rawget() does not match the
implementation. rawget(t, nil) just returns nil and does not
raise an error.

> I certainly prefer the definition that says that t[ nil ] is always equal to
> nil for any valid table. I just didn't realize that was the case.

I guess some existing Lua 5 code depends on this, too.

Another quirk: __index is called for nil keys, but __newindex is
not called before the error is raised (mentioned before on the
list). The latter behaviour does not match with the pseudo-code.

I guess this is the old problem with language definition vs.
implementation behaviour. There's no alternative implementation
of Lua 5.x, so there was never a need for a clear separation.

Bye,
     Mike
Reply | Threaded
Open this post in threaded view
|

Re: t[ nil ]

Roberto Ierusalimschy
> I guess this is the old problem with language definition vs.
> implementation behaviour. There's no alternative implementation
> of Lua 5.x, so there was never a need for a clear separation.

The absence of an alternative implementation is no excuse for a
poor definition. We consider a bug whenever the implementation does
not follow the manual. (Although the manual may left things undefined
intentionally).

In this particular case, the intended behavior is that t[nil] results in
nil and that the assignment to t[nil] is an error.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: t[ nil ]

David Jones-2
In reply to this post by Mike Pall-5-2

On May 19, 2006, at 22:49, Mike Pall wrote:
>
> I guess this is the old problem with language definition vs.
> implementation behaviour. There's no alternative implementation
> of Lua 5.x, so there was never a need for a clear separation.

Couldn't your own LuaJIT be considered an alternative implementation?

drj

Reply | Threaded
Open this post in threaded view
|

Re: t[ nil ]

Mike Pall-5-2
Hi,

David Jones wrote:
> On May 19, 2006, at 22:49, Mike Pall wrote:
> >I guess this is the old problem with language definition vs.
> >implementation behaviour. There's no alternative implementation
> >of Lua 5.x, so there was never a need for a clear separation.
>
> Couldn't your own LuaJIT be considered an alternative implementation?

Not really. At least not the current version. LuaJIT tries to
reuse as much as possible of the Lua core. It's closely tied to
the original implementation. The C code and its semantics are the
archetype for the generated machine code.

[
There are many obvious benefits to this approach, but is has
drawbacks, too. The internal structures of the Lua core are
optimized for execution by an interpreter and for maximum
portability. This puts heavy constraints on the design. These in
turn impact performance of JIT compiled code quite a bit.

If I had to implement a pure JIT compiler for Lua from scratch,
I'd use a completely different design.
]

Bye,
     Mike