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
|

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

Andrew Starks


On Thursday, July 18, 2013, Hisham wrote:
On 18 July 2013 14:16, Roberto Ierusalimschy <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;roberto@inf.puc-rio.br&#39;)">roberto@...> wrote:
>> 2013/7/17 Roberto Ierusalimschy <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;roberto@inf.puc-rio.br&#39;)">roberto@...>
>>
>> >  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/


Hisham, 

Sorry To repeat myself... I'd be interested in your critique of:

type.isfloat(x); type.isnil(x)

Etc. 
 
Reply | Threaded
Open this post in threaded view
|

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

Hisham
On 18 July 2013 21:39, Andrew Starks <[hidden email]> wrote:

>
>
> On Thursday, July 18, 2013, Hisham wrote:
>>
>> 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/
>>
>
> Hisham,
>
> Sorry To repeat myself... I'd be interested in your critique of:
>
> type.isfloat(x); type.isnil(x)

It doesn't look bad as APIs go, but it's a half-dozen functions at
least and an extra library, plus the incompatibility of turning type()
from a function into a table (yes, it could be made into a callable
table via metatable magic but it's extra complication). For these
reasons it doesn't strike me as something that would make into the Lua
standard library. The Lua team seems to always favor minimalistic and
generic approaches (case in point, them turning the issue of telling
apart floats and integers into a single general subtyping function
that also handles userdata and function differences, etc).

-- Hisham
http://hisham.hm/

Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks


On Thursday, July 18, 2013, Hisham wrote:
On 18 July 2013 21:39, Andrew Starks <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;andrew.starks@trms.com&#39;)">andrew.starks@...> wrote:
>
>
> On Thursday, July 18, 2013, Hisham wrote:
>>
>> On 18 July 2013 14:16, Roberto Ierusalimschy <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;roberto@inf.puc-rio.br&#39;)">roberto@...>
>> wrote:
>> >> 2013/7/17 Roberto Ierusalimschy <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;roberto@inf.puc-rio.br&#39;)">roberto@...>
>> >>
>> >> >  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/
>>
>
> Hisham,
>
> Sorry To repeat myself... I'd be interested in your critique of:
>
> type.isfloat(x); type.isnil(x)

It doesn't look bad as APIs go, but it's a half-dozen functions at
least and an extra library, plus the incompatibility of turning type()
from a function into a table (yes, it could be made into a callable
table via metatable magic but it's extra complication). For these
reasons it doesn't strike me as something that would make into the Lua
standard library. The Lua team seems to always favor minimalistic and
generic approaches (case in point, them turning the issue of telling
apart floats and integers into a single general subtyping function
that also handles userdata and function differences, etc).

-- Hisham
http://hisham.hm/


Thanks for that. I was thinking a functable with is[typename] was more generic than a mode signified by true/false. I'll have to think on that. 
Reply | Threaded
Open this post in threaded view
|

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

Hisham
On 18 July 2013 22:33, Andrew Starks <[hidden email]> wrote:

>
>
> On Thursday, July 18, 2013, Hisham wrote:
>>
>> On 18 July 2013 21:39, Andrew Starks <[hidden email]> wrote:
>> >
>> >
>> > On Thursday, July 18, 2013, Hisham wrote:
>> >>
>> >> 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/
>> >>
>> >
>> > Hisham,
>> >
>> > Sorry To repeat myself... I'd be interested in your critique of:
>> >
>> > type.isfloat(x); type.isnil(x)
>>
>> It doesn't look bad as APIs go, but it's a half-dozen functions at
>> least and an extra library, plus the incompatibility of turning type()
>> from a function into a table (yes, it could be made into a callable
>> table via metatable magic but it's extra complication). For these
>> reasons it doesn't strike me as something that would make into the Lua
>> standard library. The Lua team seems to always favor minimalistic and
>> generic approaches (case in point, them turning the issue of telling
>> apart floats and integers into a single general subtyping function
>> that also handles userdata and function differences, etc).
>>
>> -- Hisham
>> http://hisham.hm/
>>
>
> Thanks for that. I was thinking a functable with is[typename] was more
> generic than a mode signified by true/false. I'll have to think on that.

Well, my suggestion of sticking debug.subtype() inside type() was
meant to sidestep the issue of where to put it, while keeping the API
function count low. I'm not strongly advocating it, just contributing
an idea.

-- Hisham
http://hisham.hm/

Reply | Threaded
Open this post in threaded view
|

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

Tangent 128
In reply to this post by Sean Conner
On 07/17/2013 04:33 PM, Sean Conner wrote:

> 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)
>
>

I was going to second "meta.*", but this actually does make a good deal
of sense! ;P

Reply | Threaded
Open this post in threaded view
|

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

Pierre Chapuis
In reply to this post by Hisham
> Well, my suggestion of sticking debug.subtype() inside type() was
> meant to sidestep the issue of where to put it, while keeping the API
> function count low. I'm not strongly advocating it, just contributing

For what it's worth, I agree with that idea.
I really don't like the idea of putting subtype() in debug.

--
Pierre Chapuis


Reply | Threaded
Open this post in threaded view
|

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

Philipp Janda
Am 19.07.2013 10:00 schröbte Pierre Chapuis:
>> Well, my suggestion of sticking debug.subtype() inside type() was
>> meant to sidestep the issue of where to put it, while keeping the API
>> function count low. I'm not strongly advocating it, just contributing
>
> For what it's worth, I agree with that idea.
> I really don't like the idea of putting subtype() in debug.

I'm fine with `debug.subtype`, although I probably would call it
`debug.type`, just like `debug.setmetatable` provides a superset of
functionality compared to plain `setmetatable`.

But do we need that function at all? Are there any use cases where you
want to know the actual subtype of functions or userdata in Lua code, or
is this just for the sake of completeness?

At the moment, my preferred solution would be math.type (like io.type,
lpeg.type, etc.):
*   no new global variables
*   no new names
*   no unfamiliar calling conventions
*   if people remove debug functions, they probably won't make an
exception for harmless functions like (sub)type
*   the only reason to remove `math` is if you don't have floats in
which case this function becomes obsolete anyway

Philipp



Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
In reply to this post by Hisham
2013/7/19 Hisham <[hidden email]>:

> 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.

Or type could return typename,subtypename, where subtypename
could be obj:type() if typename is not 'number'.

   print(type(io.stdin))
userdata    file
   print(type(1))
number    integer

Reply | Threaded
Open this post in threaded view
|

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

steve donovan
On Fri, Jul 19, 2013 at 6:01 PM, Dirk Laurie <[hidden email]> wrote:
   print(type(1))
number    integer

Ah, but suddenly a function which has only returned one value returns two .. here again I'm reminded of the special care one must take with string.gsub.  Better it be a different function, then.
 

Reply | Threaded
Open this post in threaded view
|

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

Joshua Jensen-2
----- Original Message -----
From: steve donovan
Date: 7/19/2013 10:25 AM
On Fri, Jul 19, 2013 at 6:01 PM, Dirk Laurie <[hidden email]> wrote:
   print(type(1))
number    integer

Ah, but suddenly a function which has only returned one value returns two .. here again I'm reminded of the special care one must take with string.gsub.  Better it be a different function, then.
 

print(type(1, 'subtype'))
number    integer

???

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

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

Andrew Starks


On Friday, July 19, 2013, Joshua Jensen wrote:
----- Original Message -----
From: steve donovan
Date: 7/19/2013 10:25 AM
On Fri, Jul 19, 2013 at 6:01 PM, Dirk Laurie <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;dirk.laurie@gmail.com&#39;);" target="_blank">dirk.laurie@...> wrote:
   print(type(1))
number    integer

Ah, but suddenly a function which has only returned one value returns two .. here again I'm reminded of the special care one must take with string.gsub.  Better it be a different function, then.
 

print(type(1, 'subtype'))
number    integer

???

-Josh

Or the possibly buggy approach of:

types(1)
number, integer

I think subtype is very nice, but I overload type to work with hierarchies of types (more than two). Subtype could be used in the same way, but it struck me as singular, like type is. 

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

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

Eric Wing
In reply to this post by Hisham
On 7/18/13, Hisham <[hidden email]> wrote:
> if this is to be made more general than just for math,

I know there are considerable implications to the module ecosystem
that need to be carefully considered, but as a more general
application, consider returning the metatable name of userdata as the
subtype.

There have been some occasions I really wanted to know the "subtype"
of the userdata so I could do special or different handling.

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

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 Philipp Janda
2013/7/19 Philipp Janda <[hidden email]>:

> Am 19.07.2013 10:00 schröbte Pierre Chapuis:
>
>>> Well, my suggestion of sticking debug.subtype() inside type() was
>>> meant to sidestep the issue of where to put it, while keeping the API
>>> function count low. I'm not strongly advocating it, just contributing
>>
>>
>> For what it's worth, I agree with that idea.
>> I really don't like the idea of putting subtype() in debug.
>
>
> I'm fine with `debug.subtype`, although I probably would call it
> `debug.type`, just like `debug.setmetatable` provides a superset of
> functionality compared to plain `setmetatable`.
>
> But do we need that function at all? Are there any use cases where you want
> to know the actual subtype of functions or userdata in Lua code, or is this
> just for the sake of completeness?
>
> At the moment, my preferred solution would be math.type (like io.type,
> lpeg.type, etc.):
> *   no new global variables
> *   no new names
> *   no unfamiliar calling conventions
> *   if people remove debug functions, they probably won't make an exception
> for harmless functions like (sub)type
> *   the only reason to remove `math` is if you don't have floats in which
> case this function becomes obsolete anyway
>

Yes, math.type looks absolutely the best solution!

Regards,

--
Demelier David

Reply | Threaded
Open this post in threaded view
|

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

Ralph Hempel-2
David Demelier wrote:

>> At the moment, my preferred solution would be math.type (like io.type,
>> lpeg.type, etc.):
>> *   no new global variables
>> *   no new names
>> *   no unfamiliar calling conventions
>> *   if people remove debug functions, they probably won't make an exception
>> for harmless functions like (sub)type
>> *   the only reason to remove `math` is if you don't have floats in which
>> case this function becomes obsolete anyway
>
> Yes, math.type looks absolutely the best solution!

Actually, you don't necessarily remove math[] if you don't have floats.

For my Programmable Brick Lua (pbLua) for LEGO MINDSTORMS NXT based on
Lua 5.2 I set the default number type to int, but implemented a single
precision float library so that pbLua could have basic trig and log
functions that gave single precision float output.

However, handling the float results resulted in a special userdata type
which was a general pain in the neck to use.

I am about to build a new version based on Lus 5.3 Work 1 that will (I
think) be a huge improvement, and will simplify the handling of mixed
numerical types.

I'm looking forward to playing with that!

Ralph


Reply | Threaded
Open this post in threaded view
|

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

John Hind
In reply to this post by David Demelier
Still seems to me that a second return value from type() is by far the most
straight forward solution to this. Anyone who does not like this can easily
front it with a wrapper in Lua to do it however they wish.

This could also be usefully extended by a new '__type' metatable key. If
present, its value would be returned as the second return from type(). So
classes/types created from table or userdata type could easily be set up to
return an appropriate sub-type.

> Date: Mon, 22 Jul 2013 09:04:59 +0200
> From: David Demelier <[hidden email]>
> Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()
> To: Lua mailing list <[hidden email]>
> Message-ID:
> <CAO+PfDfs6ke3Gpko8n4NTU6imm2-
> [hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
> 2013/7/19 Philipp Janda <[hidden email]>:
> > Am 19.07.2013 10:00 schrC6bte Pierre Chapuis:
> >
> >>> Well, my suggestion of sticking debug.subtype() inside type() was
> >>> meant to sidestep the issue of where to put it, while keeping the
> >>> API function count low. I'm not strongly advocating it, just
> >>> contributing
> >>
> >>
> >> For what it's worth, I agree with that idea.
> >> I really don't like the idea of putting subtype() in debug.
> >
> >
> > I'm fine with `debug.subtype`, although I probably would call it
> > `debug.type`, just like `debug.setmetatable` provides a superset of
> > functionality compared to plain `setmetatable`.
> >
> > But do we need that function at all? Are there any use cases where
> you
> > want to know the actual subtype of functions or userdata in Lua code,
> > or is this just for the sake of completeness?
> >
> > At the moment, my preferred solution would be math.type (like
> io.type,
> > lpeg.type, etc.):
> > *   no new global variables
> > *   no new names
> > *   no unfamiliar calling conventions
> > *   if people remove debug functions, they probably won't make an
> exception
> > for harmless functions like (sub)type
> > *   the only reason to remove `math` is if you don't have floats in
> which
> > case this function becomes obsolete anyway
> >
>
> Yes, math.type looks absolutely the best solution!
>


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 David Demelier
"John Hind" <[hidden email]> writes:
> Still seems to me that a second return value from type() is by far the most
> straight forward solution to this. Anyone who does not like this can easily
> front it with a wrapper in Lua to do it however they wish.


I disagree, I think the current math.isinteger (with a possible
math.isfloat alternative) is better.

In general I think predicates are more useful than "type()" type
operators, because they avoid the need to partition the input space,
and correspond more exactly with what the user typically wants to
know:  does this objects have <interface/behavior X>.

So basically I think the existing interface in 5.3-work1 is fine, and
a good model to follow.

-miles


p.s. I _also_ think that a similar model (isfunction(), istable(),
etc) would be better for general Lua type inquiries than type(); see
various long past threads on this mailing list... :]

--
"An atheist doesn't have to be someone who thinks he has a proof that
there can't be a god.  He only has to be someone who believes that the
evidence on the God question is at a similar level to the evidence on
the werewolf question."  [John McCarthy]

Reply | Threaded
Open this post in threaded view
|

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

Rena

On Jul 22, 2013 9:59 PM, "Miles Bader" <[hidden email]> wrote:
> p.s. I _also_ think that a similar model (isfunction(), istable(),
> etc) would be better for general Lua type inquiries than type(); see
> various long past threads on this mailing list... :]
I'd long wished for isindexable() and iscallable(), so that tables, functions, and userdata with the appropriate metamethods can be interchanged. Right now even if I have __call and __index on a userdata, many libraries won't accept it because they check the type explicitly.

Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks


On Tuesday, July 23, 2013, Rena wrote:

On Jul 22, 2013 9:59 PM, "Miles Bader" <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;miles@gnu.org&#39;);" target="_blank">miles@...> wrote:
> p.s. I _also_ think that a similar model (isfunction(), istable(),
> etc) would be better for general Lua type inquiries than type(); see
> various long past threads on this mailing list... :]
I'd long wished for isindexable() and iscallable(), so that tables, functions, and userdata with the appropriate metamethods can be interchanged. Right now even if I have __call and __index on a userdata, many libraries won't accept it because they check the type explicitly.

I like this too, except that I think that the "is__" functions should all be members of type. 

type.isfloat(x)

It seems that all types should have that interface, if some do, and "type" is the logical spot to put them. 

Continuing the current approach of checking to see if the name of the type is equal to a string has limitations. But, tradition as it is...

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

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

steve donovan
In reply to this post by Rena
On Tue, Jul 23, 2013 at 12:32 PM, Rena <[hidden email]> wrote:

I'd long wished for isindexable() and iscallable(), so that tables, functions, and userdata with the appropriate metamethods can be interchanged. Right now even if I have __call and __index on a userdata, many libraries won't accept it because they check the type explicitly.

However, indexable checks aren't exported; is_callable is exported, as well as the inevitable extended type function ;)

https://github.com/stevedonovan/Penlight/blob/master/lua/pl/utils.lua#L265

Reply | Threaded
Open this post in threaded view
|

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

Thijs Schreijer
In reply to this post by David Demelier
Being the one that opted for the two return values, I must say that I agree with Steve and Roberto that having to create a local for just accessing the second return value is a bad practice. 

Then I would rather have a single type() function and replace its 'number' return value with the new types. Big incompatibility but the new integer division operator already is. Incompatible but clean. 

Thijs




-------- Original message --------
From: John Hind <[hidden email]>
Date:
To: [hidden email]
Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()


Still seems to me that a second return value from type() is by far the most
straight forward solution to this. Anyone who does not like this can easily
front it with a wrapper in Lua to do it however they wish.

This could also be usefully extended by a new '__type' metatable key. If
present, its value would be returned as the second return from type(). So
classes/types created from table or userdata type could easily be set up to
return an appropriate sub-type.

> Date: Mon, 22 Jul 2013 09:04:59 +0200
> From: David Demelier <[hidden email]>
> Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()
> To: Lua mailing list <[hidden email]>
> Message-ID:
>        <CAO+PfDfs6ke3Gpko8n4NTU6imm2-
> [hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
> 2013/7/19 Philipp Janda <[hidden email]>:
> > Am 19.07.2013 10:00 schrC6bte Pierre Chapuis:
> >
> >>> Well, my suggestion of sticking debug.subtype() inside type() was
> >>> meant to sidestep the issue of where to put it, while keeping the
> >>> API function count low. I'm not strongly advocating it, just
> >>> contributing
> >>
> >>
> >> For what it's worth, I agree with that idea.
> >> I really don't like the idea of putting subtype() in debug.
> >
> >
> > I'm fine with `debug.subtype`, although I probably would call it
> > `debug.type`, just like `debug.setmetatable` provides a superset of
> > functionality compared to plain `setmetatable`.
> >
> > But do we need that function at all? Are there any use cases where
> you
> > want to know the actual subtype of functions or userdata in Lua code,
> > or is this just for the sake of completeness?
> >
> > At the moment, my preferred solution would be math.type (like
> io.type,
> > lpeg.type, etc.):
> > *   no new global variables
> > *   no new names
> > *   no unfamiliar calling conventions
> > *   if people remove debug functions, they probably won't make an
> exception
> > for harmless functions like (sub)type
> > *   the only reason to remove `math` is if you don't have floats in
> which
> > case this function becomes obsolete anyway
> >
>
> Yes, math.type looks absolutely the best solution!
>


1234