new "empty" value/type in Lua?

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

Re: new "empty" value/type in Lua?

Hisham
On 1 July 2013 15:04, Roberto Ierusalimschy <[hidden email]> wrote:
>> Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
>> nil but introducing two new functions to the table library called
>> "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
>> deletion via assigning nil?
>
> At last something new and worth a discussion. Does anyone see problems/
> incompatibilities/etc. with this?

If I'm following correctly, code that uses t[k] = nil to clean up
parts of a table would behave the same, but take up more memory,
unless modified to use table.delete() ? If so, that would turn a
"standard practice" into a compatible, but "bad practice"... I agree
with Javier that this would be a major change. I don't know if I like
the whole proposal or not, but this point I raised does sound like a
problem to me.

-- Hisham
http://hisham.hm/

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Coda Highland
On Mon, Jul 1, 2013 at 12:16 PM, Hisham <[hidden email]> wrote:

> On 1 July 2013 15:04, Roberto Ierusalimschy <[hidden email]> wrote:
>>> Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
>>> nil but introducing two new functions to the table library called
>>> "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
>>> deletion via assigning nil?
>>
>> At last something new and worth a discussion. Does anyone see problems/
>> incompatibilities/etc. with this?
>
> If I'm following correctly, code that uses t[k] = nil to clean up
> parts of a table would behave the same, but take up more memory,
> unless modified to use table.delete() ? If so, that would turn a
> "standard practice" into a compatible, but "bad practice"... I agree
> with Javier that this would be a major change. I don't know if I like
> the whole proposal or not, but this point I raised does sound like a
> problem to me.
>
> -- Hisham
> http://hisham.hm/
>

This is a valid point and it makes me wonder if perhaps there needs to
be an opt-in mechanism similar to creating a weak table.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Tim Hill
In reply to this post by Coda Highland
I would say that from a CS perspective, table.has() and an "empty" sentinel are the same thing in different form; both introduce an extra bit of information about an element in the table, since you now have two possibilities when faced with t[k] = nil: one with table.has() true, one with table.has() false. Logically you could define:

function empty(t, k) return t[k] == nil and table.has(t,k) end

--Tim

On Jul 1, 2013, at 12:13 PM, Coda Highland <[hidden email]> wrote:

> On Mon, Jul 1, 2013 at 12:11 PM, Tim Hill <[hidden email]> wrote:
>>>> That could be useful, but also a bit confusing as it means a key set to nil
>>>> and a key that was never set (or was deleted) are different things, but both
>>>> have a nil value.
>>> You can tell the difference with table.has().
>> Depending on how # behaved, you might also be able to tell with just (i <=
>> #t) ?
>
> table.has() is a generic mechanism for all tables, not just arrays --
> a sparse array or a freeform table could still have nil-valued entries
> as distinct from nonexistent entries.
>
> /s/ Adam
>


Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Coda Highland
>From a CS perspective, all computable algorithms can be expressed by a
Turing machine. That doesn't mean there aren't comparative merits
between them.

/s/ Adam

On Mon, Jul 1, 2013 at 12:35 PM, Tim Hill <[hidden email]> wrote:

> I would say that from a CS perspective, table.has() and an "empty" sentinel are the same thing in different form; both introduce an extra bit of information about an element in the table, since you now have two possibilities when faced with t[k] = nil: one with table.has() true, one with table.has() false. Logically you could define:
>
> function empty(t, k) return t[k] == nil and table.has(t,k) end
>
> --Tim
>
> On Jul 1, 2013, at 12:13 PM, Coda Highland <[hidden email]> wrote:
>
>> On Mon, Jul 1, 2013 at 12:11 PM, Tim Hill <[hidden email]> wrote:
>>>>> That could be useful, but also a bit confusing as it means a key set to nil
>>>>> and a key that was never set (or was deleted) are different things, but both
>>>>> have a nil value.
>>>> You can tell the difference with table.has().
>>> Depending on how # behaved, you might also be able to tell with just (i <=
>>> #t) ?
>>
>> table.has() is a generic mechanism for all tables, not just arrays --
>> a sparse array or a freeform table could still have nil-valued entries
>> as distinct from nonexistent entries.
>>
>> /s/ Adam
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Eike Decker
In reply to this post by Roberto Ierusalimschy
Am 01.07.2013 20:44 schrieb "Roberto Ierusalimschy" <[hidden email]>:


>
> > Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
> > nil but introducing two new functions to the table library called
> > "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
> > deletion via assigning nil?
>
> At last something new and worth a discussion. Does anyone see problems/
> incompatibilities/etc. with this?

* Any former deletion of keys would not release memory thus creating
memory leaks. This could be subtle and unexpected and thus hard to
find.

* Next to that, unexpected behavior that used to work when dealing
with arrays could lead to new bug discoveries (but I would regard such
former code as bugged anyway) that would require attention.

* Also problematic could be regarded the behavior for weak tables. The
case for weak keys would be simple: If the key gets collected, the key
is deleted. For weak value tables, it's ambiguous - the key could be
deleted or the value could be set to nil. I don't know what would make
sense in that case. Maybe it only requires a decision and RTFM
messages when someone stumbles over it.

* Furthermore, iteration of deleted values would behave differently as
the values can actually be nil - so any pairs(t) call on tables can
all of a sudden return nils in case that the table is assigning nil
values for deletion.


Apart from that not much is crossing my mind that would be changed.
Deletion of keys was not often part of my code as in most cases I used
to throw away the entire table. I don't know how often values get
deleted from tables in other people code. But yes, any such behavior
needs to be revisited.

I still would think that an explicit deletion command would be more
clean because the nil assignment can be done unwantingly:

t[a],t[b] = t[b] -- deletion of t[b] afterwards - wanted or incomplete swap?

t[idx] = val -- if val is nil => deletion with all kind of wicked
consequences like "Why does iteration stop after 30 elements though
there should be 1000?" - this keeps happening all the time



>
> (But what is "[to]"?)

[to] would be used for ranged deleted but I now realize, that it would
not work as intended (regarding arrays and holes...), so I think it
should just be table.delete(t, key) as arguments.

>
> Keep in mind that #t would still be undefined for arrays with holes,
> but holes would be much less frequent...

True. But hole punching would not break the length operator any more,
which I would regard a great win.

Next to that, it might be useful in this context to consider reviving
an old table creation function that allowed specifying length of the
array part of a table... It would pre allocate an array with n nil
values and would provide means for more efficient table filling.

>
> -- Roberto


2013/7/1 Roberto Ierusalimschy <[hidden email]>:

>> Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
>> nil but introducing two new functions to the table library called
>> "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
>> deletion via assigning nil?
>
> At last something new and worth a discussion. Does anyone see problems/
> incompatibilities/etc. with this?
>
> (But what is "[to]"?)
>
> Keep in mind that #t would still be undefined for arrays with holes,
> but holes would be much less frequent...
>
> -- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Pierre Chapuis
In reply to this post by Roberto Ierusalimschy
>> Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
>> nil but introducing two new functions to the table library called
>> "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
>> deletion via assigning nil?
>
> At last something new and worth a discussion. Does anyone see problems/
> incompatibilities/etc. with this?

Couldn't we not just finally add a real sequential type to the language?
Something that has a well-defined length *all the time*, no issue with
holes and can be detected just by using type() on it?

I don't really care if it is implemented with a table, a field called
"n" and a few sanity checks on insertion, and I don't really care
what syntax would be used, but it would solve so many issues I don't see
any reason not to do it.

--
Pierre Chapuis



Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Tim Hill
In reply to this post by Coda Highland
Completely agree.

On Jul 1, 2013, at 12:38 PM, Coda Highland <[hidden email]> wrote:

>> From a CS perspective, all computable algorithms can be expressed by a
> Turing machine. That doesn't mean there aren't comparative merits
> between them.
>
> /s/ Adam
>
> On Mon, Jul 1, 2013 at 12:35 PM, Tim Hill <[hidden email]> wrote:
>> I would say that from a CS perspective, table.has() and an "empty" sentinel are the same thing in different form; both introduce an extra bit of information about an element in the table, since you now have two possibilities when faced with t[k] = nil: one with table.has() true, one with table.has() false. Logically you could define:
>>
>> function empty(t, k) return t[k] == nil and table.has(t,k) end
>>
>> --Tim
>>
>> On Jul 1, 2013, at 12:13 PM, Coda Highland <[hidden email]> wrote:
>>
>>> On Mon, Jul 1, 2013 at 12:11 PM, Tim Hill <[hidden email]> wrote:
>>>>>> That could be useful, but also a bit confusing as it means a key set to nil
>>>>>> and a key that was never set (or was deleted) are different things, but both
>>>>>> have a nil value.
>>>>> You can tell the difference with table.has().
>>>> Depending on how # behaved, you might also be able to tell with just (i <=
>>>> #t) ?
>>>
>>> table.has() is a generic mechanism for all tables, not just arrays --
>>> a sparse array or a freeform table could still have nil-valued entries
>>> as distinct from nonexistent entries.
>>>
>>> /s/ Adam
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Roberto Ierusalimschy
In reply to this post by Hisham
> If I'm following correctly, code that uses t[k] = nil to clean up
> parts of a table would behave the same, but take up more memory,
> unless modified to use table.delete() ?

Currently, t[k] = nil does not clean up anything, so that would not be
a big difference. (OK, t[k]=nil opens the door for a future clean up,
but that depends on other things; I guess few programs actually go
to the stage of a clean up...)

Much more serious, for me, is the incompatibility that t[#t] = nil will
not "pop" elements form a list (and. of course, the extra complexity).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Dirk Laurie-2
2013/7/1 Roberto Ierusalimschy <[hidden email]>:

> Much more serious, for me, is the incompatibility that t[#t] = nil will
> not "pop" elements form a list (and. of course, the extra complexity).

Exactly. Deletion by assigning nil is too ingrained in existing Lua
programs to be replaced now.

The need is not for nil to change its nature. The need is for table keys
to be classifiable as legal or illegal before they are used. The length
function would work on legal keys, not on keys in use. The proposed 'has'
function would simply distinguish between legal and illegal keys.

One possible mechanism could be a metatable entry '__has'. If this
is nil, we are back in the present situation, so no incompatibility.
If this is present, __newindex will not assign and __index will not
retrieve illegal keys.

If `__has` is a table, then 'has(tbl)' looks in it for the key. If it
is a function, 'has(tbl)' calls it and returns the result. If it is
a number, 'has' accepts all integer keys between 1 and `__has` and
# returns `__has`. To create a fixed-size, no-holes table that can
take 100 entries, all you need to do is

   tbl=setmetatable({},{__has=100})

By all means offer syntactic sugar `tbl=array(100)` for this.  The
array part would be allocated to take 100 entries. Nil would still
be used to identify currently unused keys, but the array would not be
shrunk even if less than half full.

The proposed 'delete' function does not seem to be as useful. Just
deleting the present value can be done by assigning nil, and permanently
changing the legality of a key should not be as easy as calling a
standard library function. It should require explicit reassigning of
`getmetatable(tbl).__has`.

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Eike Decker
In reply to this post by Tim Hill
2013/7/1 Tim Hill <[hidden email]>:
> I would say that from a CS perspective, table.has() and an "empty" sentinel are the same thing in different form; both introduce an extra bit of information about an element in the table, since you now have two possibilities when faced with t[k] = nil: one with table.has() true, one with table.has() false. Logically you could define:
>
> function empty(t, k) return t[k] == nil and table.has(t,k) end
>
> --Tim
>

The difference that matters to me considering your feature wish is,
that no additional value type that can be (ab-)used is required for
the proposal that I made, while still achieving a compatible solution
since you can then explicitly demand the existence of a nil value in a
table and have nils in arrays.
Because if a value does exists, it can also be nil, if it doesn't
exist, it's still nil but you can check that. You can of course not
pass "empty" to a function this way, which your idea allows, but that
can get easily around this if required through additional parameters
or functions in the API that you define yourself.

In my opinion, it is less intrusive than your proposal because it
doesn't add something completely new but changes the behavior of
something old that might make things more consistent - though I am not
the one to judge that in the end, I think that my proposal is in fact
making things more consistent. The behavior of the length operator is
something that I believe no one is truly happy about... and that is
what my suggestion would at least improve a bit. (Of course you can
still argue that this can also be achieved with a new empty type - as
you have shown, it can be emulated with empty but as many here argue,
at a cost of introducing a new value that many appear not to be happy
with for (in my opinion valid) reasons that have already been
discussed in great length)


Cheers & good night,
Eike

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Coda Highland
In reply to this post by Dirk Laurie-2
On Mon, Jul 1, 2013 at 3:00 PM, Dirk Laurie <[hidden email]> wrote:

> 2013/7/1 Roberto Ierusalimschy <[hidden email]>:
>
>> Much more serious, for me, is the incompatibility that t[#t] = nil will
>> not "pop" elements form a list (and. of course, the extra complexity).
>
> Exactly. Deletion by assigning nil is too ingrained in existing Lua
> programs to be replaced now.
>
> The need is not for nil to change its nature. The need is for table keys
> to be classifiable as legal or illegal before they are used. The length
> function would work on legal keys, not on keys in use. The proposed 'has'
> function would simply distinguish between legal and illegal keys.
>
> One possible mechanism could be a metatable entry '__has'. If this
> is nil, we are back in the present situation, so no incompatibility.
> If this is present, __newindex will not assign and __index will not
> retrieve illegal keys.
>
> If `__has` is a table, then 'has(tbl)' looks in it for the key. If it
> is a function, 'has(tbl)' calls it and returns the result. If it is
> a number, 'has' accepts all integer keys between 1 and `__has` and
> # returns `__has`. To create a fixed-size, no-holes table that can
> take 100 entries, all you need to do is
>
>    tbl=setmetatable({},{__has=100})
>
> By all means offer syntactic sugar `tbl=array(100)` for this.  The
> array part would be allocated to take 100 entries. Nil would still
> be used to identify currently unused keys, but the array would not be
> shrunk even if less than half full.
>
> The proposed 'delete' function does not seem to be as useful. Just
> deleting the present value can be done by assigning nil, and permanently
> changing the legality of a key should not be as easy as calling a
> standard library function. It should require explicit reassigning of
> `getmetatable(tbl).__has`.
>

I'll be honest, that sounds somewhat overengineered, and the number of
lookups that introduces sounds like a performance drain because you're
making the dot operator itself more expensive. A "sticky keys" tag
akin to the "weak values" sounds a lot cleaner because it limits the
scope of the effect and can be handled within the VM itself instead of
needing to inspect Lua-side data or invoke Lua-side functions.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Xavier Wang
In reply to this post by Roberto Ierusalimschy
this will be easy to implement in pure lua, if you need a C interface, also easy implement in C. (with current Lua implement).

just use a empty table/function as empty value, and modify type function to return "empty" if called with this value.

table.has only check this empty value, and table.delete just put this empty value to place.

IMHO, what Tim want is just a "standard way" to something, in this topic, the "empty value" in array, but in facts, there are so many thing in Lua that indeed need a standard way. what about exception? what about OO?

the real question is, how to define a standard way, makes all Luaer works with it, but not affect the simply of Lua?

maybe we need something like lua manual, it's a standard, but not the Lua language, it's for the Lua usage, e.g. return nil, errmsg[, others] for error case, etc. and this empty value can put in this standard document.

or, some "std library", disturbed with Lua source, as a part of Lua language, but description of it is at other place (maybe it's the standard lua usage document).



2013/7/2 Roberto Ierusalimschy <[hidden email]>
> Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
> nil but introducing two new functions to the table library called
> "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
> deletion via assigning nil?

At last something new and worth a discussion. Does anyone see problems/
incompatibilities/etc. with this?

(But what is "[to]"?)

Keep in mind that #t would still be undefined for arrays with holes,
but holes would be much less frequent...

-- Roberto




--
regards,
Xavier Wang.
Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Tim Hill
In reply to this post by Coda Highland
Completely agree.

On Jul 1, 2013, at 12:38 PM, Coda Highland <[hidden email]> wrote:

Turing machine. That doesn't mean there aren't comparative merits
between them.

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Tim Hill
In reply to this post by Eike Decker
Agreed, and you suggest an interesting approach. Is the end-game of this an array that is (in effect), of a declared size? In this model, that is just what # returns all the time, and you can do all you like with nils and use whatever integer indexes you like (less than or greater than #), but not alter #. Of course, at that point # is just a fancy way of the old-style "n" field and thus has deteriorated to not being much use. Not sure I like this much.

The flip side here is subtle changes to the behavior of "nil", a more complex table API, and some boundary cases that might be a bit messy, but I agree that avoiding the introduction of a new type is worthy.

On Jul 1, 2013, at 3:01 PM, Eike Decker <[hidden email]> wrote:

The difference that matters to me considering your feature wish is,
that no additional value type that can be (ab-)used is required for
the proposal that I made, while still achieving a compatible solution
since you can then explicitly demand the existence of a nil value in a
table and have nils in arrays.
Because if a value does exists, it can also be nil, if it doesn't
exist, it's still nil but you can check that. You can of course not
pass "empty" to a function this way, which your idea allows, but that
can get easily around this if required through additional parameters
or functions in the API that you define yourself.

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Sean Conner
In reply to this post by Tim Hill
It was thus said that the Great Tim Hill once stated:
>
> Think about booleans in C; they don't exist as a 1st class type, but they
> DO have an agreed-upon standard representation (that compilers
> understand). If we didn't have that, every project would define it's own
> arbitrary true and false, and each project, by itself, would work fine.
> But then each 3rd party library you use would have a different standard,
> and you would have to have conversion logic to transition between their
> arbitrary boolean and yours; for each and every library. Urgh!

  Actually, I've seen plenty of C code improperly define the value for true.
In C, a value of 0 is considered false, and *anything but 0* is considered
true, so (in my not so humble opinion) the best definition of TRUE and FALSE
would be:

#define FALSE 0
#define TRUE !FALSE

But I've seen code that does:

#define TRUE 1
#define FALSE 0

which mostly works, but can fail in some obscure cases.  

  C99 solves that issue with _Bool (or bool, if you include <stdbool.h>) and
constants for true and false, so maybe there is something to this.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Philipp Janda
In reply to this post by Coda Highland
Am 01.07.2013 21:05 schröbte Coda Highland:

> On Mon, Jul 1, 2013 at 11:36 AM, Rena <[hidden email]> wrote:
>> On Jul 1, 2013 2:05 PM, "Roberto Ierusalimschy" <[hidden email]>
>> wrote:
>>>
>>>> Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
>>>> nil but introducing two new functions to the table library called
>>>> "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
>>>> deletion via assigning nil?
>>>
>>> At last something new and worth a discussion. Does anyone see problems/
>>> incompatibilities/etc. with this?
>>>
>>> (But what is "[to]"?)
>>>
>>> Keep in mind that #t would still be undefined for arrays with holes,
>>> but holes would be much less frequent...
>>>
>>> -- Roberto
>>>
>>
>> This seems like a good idea, but I feel like it might complicate the
>> internals a bit. Are you proposing that nil is able to be stored in tables,
>> and keys can be removed only by table.delete()? (In that case, why is #t
>> still undefined when holes are present? Or are nil keys no longer holes?)
>
> Under this proposal, nils are no longer holes.

... but holes are nils. Or stated differently: There are explicit nils,
which are part of a table, and implicit (deleted or never assigned)
nils, which are still holes. One question is: Should accessing explicit
nils invoke __(new)index metamethods?

I'd argue that if you want nils as part of tables, then go all the way,
and remove nil as a default value. Throw an error when accessing a
non-existing field instead. No need for strict.lua any more, yay! You
could simulate the old behavior using a nil-returning __index metamethod.
Anything in between seems messy, IMHO ...

>
>> That could be useful, but also a bit confusing as it means a key set to nil
>> and a key that was never set (or was deleted) are different things, but both
>> have a nil value.
>
> You can tell the difference with table.has().

table.has() and table.delete() would be essential functions not limited
to arrays, so they should go into the base library ...

>
> /s/ Adam
>

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Philipp Janda
In reply to this post by Sean Conner
Am 02.07.2013 01:20 schröbte Sean Conner:

>    Actually, I've seen plenty of C code improperly define the value for true.
> In C, a value of 0 is considered false, and *anything but 0* is considered
> true, so (in my not so humble opinion) the best definition of TRUE and FALSE
> would be:
>
> #define FALSE 0
> #define TRUE !FALSE
>
> But I've seen code that does:
>
> #define TRUE 1
> #define FALSE 0
>
> which mostly works, but can fail in some obscure cases.

For a conforming ISO C90+ compiler both cases are equivalent:

3.3.3.3 Unary arithmetic operators
[...]
The result of the logical negation operator ! is 0 if the value of
its operand compares unequal to 0, 1 if the value of its operand
compares equal to 0.  The result has type int .


Philipp




Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Tim Hill
In reply to this post by Sean Conner
omg DON'T get me started on *that* mess (grin).

Even the !FALSE trick doesn't work:

if (x == TRUE)…
if (x) …

Still give different results, since !FALSE to the compiler is !0 which is 1, so the first if is really "if (x == 1) …" for most compilers.


On Jul 1, 2013, at 4:20 PM, Sean Conner <[hidden email]> wrote:

 Actually, I've seen plenty of C code improperly define the value for true. 
In C, a value of 0 is considered false, and *anything but 0* is considered
true, so (in my not so humble opinion) the best definition of TRUE and FALSE
would be:

#define FALSE 0
#define TRUE !FALSE

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Rena
In reply to this post by Sean Conner

On Jul 1, 2013 7:20 PM, "Sean Conner" <[hidden email]> wrote:
>
> It was thus said that the Great Tim Hill once stated:
> >
> > Think about booleans in C; they don't exist as a 1st class type, but they
> > DO have an agreed-upon standard representation (that compilers
> > understand). If we didn't have that, every project would define it's own
> > arbitrary true and false, and each project, by itself, would work fine.
> > But then each 3rd party library you use would have a different standard,
> > and you would have to have conversion logic to transition between their
> > arbitrary boolean and yours; for each and every library. Urgh!
>
>   Actually, I've seen plenty of C code improperly define the value for true.
> In C, a value of 0 is considered false, and *anything but 0* is considered
> true, so (in my not so humble opinion) the best definition of TRUE and FALSE
> would be:
>
> #define FALSE   0
> #define TRUE    !FALSE
>
> But I've seen code that does:
>
> #define TRUE    1
> #define FALSE   0
>
> which mostly works, but can fail in some obscure cases.
>
>   C99 solves that issue with _Bool (or bool, if you include <stdbool.h>) and
> constants for true and false, so maybe there is something to this.
>
>   -spc
>
>

Some C compilers are so confident in their assumption that true=1, false=0 that other values can be both true and false at the same time: http://markshroyer.com/2012/06/c-both-true-and-false

Reply | Threaded
Open this post in threaded view
|

Re: new "empty" value/type in Lua?

Sean Conner
In reply to this post by Tim Hill
It was thus said that the Great Tim Hill once stated:
> omg DON'T get me started on *that* mess (grin).
>
> Even the !FALSE trick doesn't work:
>
> if (x == TRUE)…
> if (x) …
>
> Still give different results, since !FALSE to the compiler is !0 which is
> 1, so the first if is really "if (x == 1) …" for most compilers.

  Well ... darn.  

  I know I used to do this (before I converted over to C99) ... perhaps I
only ever compared against FALSE ...

  -spc (sigh)


123456