Lua 5.3 work1 Considering math.isinteger or type()

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

Lua 5.3 work1 Considering math.isinteger or type()

David Demelier
Hi,

As we have already discussed this, some of us on the lists think that
math.isfloat is great but should also reflect the opposite as
math.isinteger.

Joseph Manning and I thought this idea great as you only need to
remember there are math.is* to check the type. So you don't need to
think which one of the function is available.

This makes the library clear and adds a symmetry to the API.

However Thijs Schreijer also thougth about the functione type() that
should returns two values like this:

type(10) -> "number", "integer"
type(10.0) -> "number", "float"

This is not a bad idea, it will not break compatibility but adds a
second feature to determine the actual type of the integer. With this,
the discuss of keeping math.isfloat and adding math.isinteger will be
gone.

I just hope that one of these 2 solutions will be approved and added
for the final Lua 5.3

Regards,

--
Demelier David

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

steve donovan
On Wed, Jul 17, 2013 at 10:10 AM, David Demelier <[hidden email]> wrote:
type(10) -> "number", "integer"
type(10.0) -> "number", "float"

This is not a bad idea, it will not break compatibility but adds a
second feature to determine the actual type of the integer.

But such a change is a source of subtle errors - in the expression f(type(x)) the function f will be called with two values, and this may mess its little mind if it has optional arguments. Also, {type(x)} now has length 2.

(Saying this because string.gsub is always biting me this way)


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Roberto Ierusalimschy
> On Wed, Jul 17, 2013 at 10:10 AM, David Demelier
> <[hidden email]>wrote:
>
> > type(10) -> "number", "integer"
> > type(10.0) -> "number", "float"
> >
> > This is not a bad idea, it will not break compatibility but adds a
> > second feature to determine the actual type of the integer.

I do not think it is a good idea. If something is an integer, it must
be a number, so the first result is useless when you want the second.
And to simply check whether something is an integer you will need extra
local variables or 'select', to access that second result.


> (Saying this because string.gsub is always biting me this way)

That was not a good idea, either :)

We moved that functionality to a new function, debug.subtype, that
returns the following: integer, float, Cfunction, Luafunction,
lightudata, fulludata, string, boolean, nil, table, and thread.

Some of that functionality may not be strictly "debug", but anyway
it is something you should not be using every day, and we could not
find a better place to put that function; it may move to the global
space...

(In an ideal world, probably we should have a library with those
functions we do not use every day (maybe with rawget, rawset,
getmetatable, setmetatable, collectgarbage, and some others), but I do
not think the change is worth the trouble. Just imagine the endless
discussions about what functions should go there...)

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Duncan Cross
On Wed, Jul 17, 2013 at 2:26 PM, Roberto Ierusalimschy
<[hidden email]> wrote:
> (In an ideal world, probably we should have a library with those
> functions we do not use every day (maybe with rawget, rawset,
> getmetatable, setmetatable, collectgarbage, and some others), but I do
> not think the change is worth the trouble. Just imagine the endless
> discussions about what functions should go there...)
>
> -- Roberto

I hope you reconsider this. I have been thinking for some time that
such an "internals"/"raw" standard library, distinct from "debug"
which should not be used in production code, would be a valuable step
to take.

-Duncan

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Fidelis Assis-2
2013/7/17 Duncan Cross <[hidden email]>
On Wed, Jul 17, 2013 at 2:26 PM, Roberto Ierusalimschy
<[hidden email]> wrote:
> (In an ideal world, probably we should have a library with those
> functions we do not use every day (maybe with rawget, rawset,
> getmetatable, setmetatable, collectgarbage, and some others), but I do
> not think the change is worth the trouble. Just imagine the endless
> discussions about what functions should go there...)
>
> -- Roberto

I hope you reconsider this. I have been thinking for some time that
such an "internals"/"raw" standard library, distinct from "debug"
which should not be used in production code, would be a valuable step
to take.

I agree, perhaps move them to "introspection", "intro", "meta" or similar library name.

-- 
Fidelis Assis
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Duncan Cross
On Wed, Jul 17, 2013 at 3:37 PM, Fidelis Assis <[hidden email]> wrote:

> 2013/7/17 Duncan Cross <[hidden email]>
>>
>> On Wed, Jul 17, 2013 at 2:26 PM, Roberto Ierusalimschy
>> <[hidden email]> wrote:
>> > (In an ideal world, probably we should have a library with those
>> > functions we do not use every day (maybe with rawget, rawset,
>> > getmetatable, setmetatable, collectgarbage, and some others), but I do
>> > not think the change is worth the trouble. Just imagine the endless
>> > discussions about what functions should go there...)
>> >
>> > -- Roberto
>>
>> I hope you reconsider this. I have been thinking for some time that
>> such an "internals"/"raw" standard library, distinct from "debug"
>> which should not be used in production code, would be a valuable step
>> to take.
>
>
> I agree, perhaps move them to "introspection", "intro", "meta" or similar
> library name.
>
> --
> Fidelis Assis

Ohh dear... I already want to get in an argument with you about _all
three_ of your name suggestions, each for a different reason...
perhaps Roberto was right, and this idea really is just _too_
predisposed to interminable bike-shedding discussions to consider! ;)

-Duncan

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

David Demelier
In reply to this post by Roberto Ierusalimschy
2013/7/17 Roberto Ierusalimschy <[hidden email]>:

>> On Wed, Jul 17, 2013 at 10:10 AM, David Demelier
>> <[hidden email]>wrote:
>>
>> > type(10) -> "number", "integer"
>> > type(10.0) -> "number", "float"
>> >
>> > This is not a bad idea, it will not break compatibility but adds a
>> > second feature to determine the actual type of the integer.
>
> I do not think it is a good idea. If something is an integer, it must
> be a number, so the first result is useless when you want the second.
> And to simply check whether something is an integer you will need extra
> local variables or 'select', to access that second result.
>
>
>> (Saying this because string.gsub is always biting me this way)
>
> That was not a good idea, either :)
>
> We moved that functionality to a new function, debug.subtype, that
> returns the following: integer, float, Cfunction, Luafunction,
> lightudata, fulludata, string, boolean, nil, table, and thread.
>
> Some of that functionality may not be strictly "debug", but anyway
> it is something you should not be using every day, and we could not
> find a better place to put that function; it may move to the global
> space...
>
> (In an ideal world, probably we should have a library with those
> functions we do not use every day (maybe with rawget, rawset,
> getmetatable, setmetatable, collectgarbage, and some others), but I do
> not think the change is worth the trouble. Just imagine the endless
> discussions about what functions should go there...)
>
> -- Roberto
>
>

So math.isfloat and math.isinteger looks the better place to add these
functions IMHO :-)

Regards,

--
Demelier David

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Andrew Starks
In reply to this post by Roberto Ierusalimschy
On Wed, Jul 17, 2013 at 8:26 AM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> On Wed, Jul 17, 2013 at 10:10 AM, David Demelier
>> <[hidden email]>wrote:
>>
>> > type(10) -> "number", "integer"
>> > type(10.0) -> "number", "float"
>> >
>> > This is not a bad idea, it will not break compatibility but adds a
>> > second feature to determine the actual type of the integer.
>
> I do not think it is a good idea. If something is an integer, it must
> be a number, so the first result is useless when you want the second.
> And to simply check whether something is an integer you will need extra
> local variables or 'select', to access that second result.
>
>
>> (Saying this because string.gsub is always biting me this way)
>
> That was not a good idea, either :)
>
> We moved that functionality to a new function, debug.subtype, that
> returns the following: integer, float, Cfunction, Luafunction,
> lightudata, fulludata, string, boolean, nil, table, and thread.
>
> Some of that functionality may not be strictly "debug", but anyway
> it is something you should not be using every day, and we could not
> find a better place to put that function; it may move to the global
> space...
>
> (In an ideal world, probably we should have a library with those
> functions we do not use every day (maybe with rawget, rawset,
> getmetatable, setmetatable, collectgarbage, and some others), but I do
> not think the change is worth the trouble. Just imagine the endless
> discussions about what functions should go there...)
>
> -- Roberto
>
>

I hate to call it a different type, but could yo add to this list "not
declared"/"invalid key" (or similar) for values in a table that are
not  declared at all.

I don't wish to bring a prior thread (nil/empty) into this one, but
the distinction is just as real and some times as relevant as the
others that you've highlighted.

-Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Fidelis Assis-2
In reply to this post by Duncan Cross
2013/7/17 Duncan Cross <[hidden email]>
>
> I agree, perhaps move them to "introspection", "intro", "meta" or similar
> library name.
>
> --
> Fidelis Assis

Ohh dear... I already want to get in an argument with you about _all
three_ of your name suggestions, each for a different reason...
perhaps Roberto was right, and this idea really is just _too_
predisposed to interminable bike-shedding discussions to consider! ;)

Well, we have to make choices... But any that gives the idea is OK for me, what I don't like is "debug".

--
Fidelis Assis
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Justin Cormack
In reply to this post by Roberto Ierusalimschy


On 17 Jul 2013 14:27, "Roberto Ierusalimschy" <[hidden email]> wrote:
>
> > On Wed, Jul 17, 2013 at 10:10 AM, David Demelier
> > <[hidden email]>wrote:
> >
> > > type(10) -> "number", "integer"
> > > type(10.0) -> "number", "float"
> > >
> > > This is not a bad idea, it will not break compatibility but adds a
> > > second feature to determine the actual type of the integer.
>
> I do not think it is a good idea. If something is an integer, it must
> be a number, so the first result is useless when you want the second.
> And to simply check whether something is an integer you will need extra
> local variables or 'select', to access that second result.
>
>
> > (Saying this because string.gsub is always biting me this way)
>
> That was not a good idea, either :)
>
> We moved that functionality to a new function, debug.subtype, that
> returns the following: integer, float, Cfunction, Luafunction,
> lightudata, fulludata, string, boolean, nil, table, and thread.
>
> Some of that functionality may not be strictly "debug", but anyway
> it is something you should not be using every day, and we could not
> find a better place to put that function; it may move to the global
> space...
>
> (In an ideal world, probably we should have a library with those
> functions we do not use every day (maybe with rawget, rawset,
> getmetatable, setmetatable, collectgarbage, and some others), but I do
> not think the change is worth the trouble. Just imagine the endless
> discussions about what functions should go there...)

Why not gradually do this by adding eg rawget, setmetatable etc to table but leaving them in global for compatibility?

> -- Roberto
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Sean Conner
In reply to this post by Roberto Ierusalimschy
It was thus said that the Great Roberto Ierusalimschy once stated:
>
> (In an ideal world, probably we should have a library with those
> functions we do not use every day (maybe with rawget, rawset,
> getmetatable, setmetatable, collectgarbage, and some others), but I do
> not think the change is worth the trouble. Just imagine the endless
> discussions about what functions should go there...)

  Under lua.* of course!

  -spc (Being silly)


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Ralph Hempel-2
In reply to this post by David Demelier
David Demelier wrote:

> Hi,
>
> As we have already discussed this, some of us on the lists think that
> math.isfloat is great but should also reflect the opposite as
> math.isinteger.
>
> Joseph Manning and I thought this idea great as you only need to
> remember there are math.is* to check the type. So you don't need to
> think which one of the function is available.
>
> This makes the library clear and adds a symmetry to the API.
>
> However Thijs Schreijer also thougth about the functione type() that
> should returns two values like this:
>
> type(10) ->  "number", "integer"
> type(10.0) ->  "number", "float"

What about math.type( 10 )   -> "integer"
            math.type( 10.0 ) -> "float"
            math.type( "foo" ) -> string
            etc...

Or just return nil for not numbers..

Ralph

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Matthew Wild
On 17 July 2013 22:49, Ralph Hempel <[hidden email]> wrote:
> What about math.type( 10 )   -> "integer"
>            math.type( 10.0 ) -> "float"
>            math.type( "foo" ) -> string
>            etc...
>
> Or just return nil for not numbers..

I like this, if only for the parallel with io.type().

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Rena
In reply to this post by David Demelier

On 2013-07-17 4:10 AM, "David Demelier" <[hidden email]> wrote:
>
> Hi,
>
> As we have already discussed this, some of us on the lists think that
> math.isfloat is great but should also reflect the opposite as
> math.isinteger.
>
> Joseph Manning and I thought this idea great as you only need to
> remember there are math.is* to check the type. So you don't need to
> think which one of the function is available.
>
> This makes the library clear and adds a symmetry to the API.
>
> However Thijs Schreijer also thougth about the functione type() that
> should returns two values like this:
>
> type(10) -> "number", "integer"
> type(10.0) -> "number", "float"
>
> This is not a bad idea, it will not break compatibility but adds a
> second feature to determine the actual type of the integer. With this,
> the discuss of keeping math.isfloat and adding math.isinteger will be
> gone.
>
> I just hope that one of these 2 solutions will be approved and added
> for the final Lua 5.3
>
> Regards,
>
> --
> Demelier David
>

I really like the idea of having both math.isinteger and math.isfloat. To me they seem much more readable and easier to use than the alternatives. Consider:

if math.isinteger(x) then
if math.isfloat(x) then
Both are simple and clear. vs:

if not math.isinteger(x) -- x is not an integer, but what is it? A float? A table? nil? Even if this method throws an error if given a non-numeric value, that's something else you need to know; it's still less readable than the previous example. (Also, I think that behaviour would be quite silly; it should just answer the question and state that no, a table is not an integer.)

local _, tp = type(x)
if tp == 'integer' then
Now this is just ugly.

if math.type(x) == 'integer' then
Better, but still not as clean. (and what should math.type do with non-numeric values?)

In my opinion the first example is the clear winner - it's clear and readable and concise.

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Andrew Starks


On Wednesday, July 17, 2013, Rena wrote:

On 2013-07-17 4:10 AM, "David Demelier" <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;demelier.david@gmail.com&#39;);" target="_blank">demelier.david@...> wrote:
>
> Hi,
>
> As we have already discussed this, some of us on the lists think that
> math.isfloat is great but should also reflect the opposite as
> math.isinteger.
>
> Joseph Manning and I thought this idea great as you only need to
> remember there are math.is* to check the type. So you don't need to
> think which one of the function is available.
>
> This makes the library clear and adds a symmetry to the API.
>
> However Thijs Schreijer also thougth about the functione type() that
> should returns two values like this:
>
> type(10) -> "number", "integer"
> type(10.0) -> "number", "float"
>
> This is not a bad idea, it will not break compatibility but adds a
> second feature to determine the actual type of the integer. With this,
> the discuss of keeping math.isfloat and adding math.isinteger will be
> gone.
>
> I just hope that one of these 2 solutions will be approved and added
> for the final Lua 5.3
>
> Regards,
>
> --
> Demelier David
>

I really like the idea of having both math.isinteger and math.isfloat. To me they seem much more readable and easier to use than the alternatives. Consider:

if math.isinteger(x) then
if math.isfloat(x) then
Both are simple and clear. vs:

if not math.isinteger(x) -- x is not an integer, but what is it? A float? A table? nil? Even if this method throws an error if given a non-numeric value, that's something else you need to know; it's still less readable than the previous example. (Also, I think that behaviour would be quite silly; it should just answer the question and state that no, a table is not an integer.)

local _, tp = type(x)
if tp == 'integer' then
Now this is just ugly.

if math.type(x) == 'integer' then
Better, but still not as clean. (and what should math.type do with non-numeric values?)

In my opinion the first example is the clear winner - it's clear and readable and concise.

What about type member functions for cases like this:

type.integer(x)
Returns true if it's an integer. 
Since I don't think that a "nil" key is legal, perhaps it would need to be:

type.isnil(x)
type.isfloat(y)
type.isnumber(z)


This also leaves fertile territory for monkey patching type. 

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

Re: Lua 5.3 work1 Considering math.isinteger or type()

Miles Bader-2
In reply to this post by Duncan Cross
Duncan Cross <[hidden email]> writes:

>> (In an ideal world, probably we should have a library with those
>> functions we do not use every day (maybe with rawget, rawset,
>> getmetatable, setmetatable, collectgarbage, and some others), but I
>> do not think the change is worth the trouble. Just imagine the
>> endless discussions about what functions should go there...)
>
> I hope you reconsider this. I have been thinking for some time that
> such an "internals"/"raw" standard library, distinct from "debug"
> which should not be used in production code, would be a valuable
> step to take.

Yeah I agree.

I tend to think that a normal program should _never_ need debug (when
not debugging of course), and one should be able to delete the debug
library without causing problems.   I think sandboxes sometimes hide
the debug library entirely, so it's not just a theoretical thing.

I think Lua does need a "random system stuff" library...  A common
name for this is "sys."

Various things like rawget, etc, go in the global namespace for
historical reasons, and at least for some of them, because they're
quite often used, and more like "language features," but inevitably
there will be random stuff stuff that's occasionally useful but maybe
a little too rarely used to put in the global namespace (as of course
putting stuff in the global namespace is a little dangerous because of
the potential for conflict with user programs, and so shouldn't be
done too blithely).

-miles

--
Happiness, n. An agreeable sensation arising from contemplating the misery of
another.

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

D Burgess-4
In reply to this post by Roberto Ierusalimschy
That (as usual with Roberto) seems to be a good option.
If it "moves to global space" as "subtype()",  then I like it even more.

On Wed, Jul 17, 2013 at 11:26 PM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> On Wed, Jul 17, 2013 at 10:10 AM, David Demelier
>> <[hidden email]>wrote:
>>
>> > type(10) -> "number", "integer"
>> > type(10.0) -> "number", "float"
>> >
>> > This is not a bad idea, it will not break compatibility but adds a
>> > second feature to determine the actual type of the integer.
>
> I do not think it is a good idea. If something is an integer, it must
> be a number, so the first result is useless when you want the second.
> And to simply check whether something is an integer you will need extra
> local variables or 'select', to access that second result.
>
>
>> (Saying this because string.gsub is always biting me this way)
>
> That was not a good idea, either :)
>
> We moved that functionality to a new function, debug.subtype, that
> returns the following: integer, float, Cfunction, Luafunction,
> lightudata, fulludata, string, boolean, nil, table, and thread.
>
> Some of that functionality may not be strictly "debug", but anyway
> it is something you should not be using every day, and we could not
> find a better place to put that function; it may move to the global
> space...
>
> (In an ideal world, probably we should have a library with those
> functions we do not use every day (maybe with rawget, rawset,
> getmetatable, setmetatable, collectgarbage, and some others), but I do
> not think the change is worth the trouble. Just imagine the endless
> discussions about what functions should go there...)
>
> -- Roberto
>
>



--
David Burgess

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Fidelis Assis-2
In reply to this post by Roberto Ierusalimschy
2013/7/17 Roberto Ierusalimschy <[hidden email]>
 but I do
not think the change is worth the trouble. Just imagine the endless
discussions about what functions should go there...)

I see. Maybe the discussion should not be about "what should go there", but about what should not stay in debug, and move them gradually either to "there" or to global. "There" would become clearer in the proccess.

-- 
Fidelis Assis
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Roberto Ierusalimschy
> 2013/7/17 Roberto Ierusalimschy <[hidden email]>
>
> >  but I do
> > not think the change is worth the trouble. Just imagine the endless
> > discussions about what functions should go there...)
> >
>
> I see. Maybe the discussion should not be about "what should go there", but
> about what should not stay in debug, and move them gradually either to
> "there" or to global. "There" would become clearer in the proccess.

For me, the main problem is not debug versus "there". It is global
versus "there". (Not to mention a lot of incompatibilities for what
many may consider nitpicking.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Hisham
On 18 July 2013 14:16, Roberto Ierusalimschy <[hidden email]> wrote:

>> 2013/7/17 Roberto Ierusalimschy <[hidden email]>
>>
>> >  but I do
>> > not think the change is worth the trouble. Just imagine the endless
>> > discussions about what functions should go there...)
>> >
>>
>> I see. Maybe the discussion should not be about "what should go there", but
>> about what should not stay in debug, and move them gradually either to
>> "there" or to global. "There" would become clearer in the proccess.
>
> For me, the main problem is not debug versus "there". It is global
> versus "there". (Not to mention a lot of incompatibilities for what
> many may consider nitpicking.)

Well, my original suggestion was math.type() (and the parallel with
io.type() is indeed nice), but since we're throwing suggestions out
there, here's yet another one: if this is to be made more general than
just for math, then maybe just add the feature to type() itself, as in
type(v [, mode]) -- if given a second argument (true?) then type
returns the specific subtype, if not, the general type.

-- Hisham
http://hisham.hm/

1234