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

[Hisham <h@...>]

On 18 July 2013 22:33, Andrew Starks <andrew.starks@trms.com> wrote:
>
>
> On Thursday, July 18, 2013, Hisham wrote:
>>
>> On 18 July 2013 21:39, Andrew Starks <andrew.starks@trms.com> wrote:
>> >
>> >
>> > On Thursday, July 18, 2013, Hisham wrote:
>> >>
>> >> On 18 July 2013 14:16, Roberto Ierusalimschy <roberto@inf.puc-rio.br>
>> >> wrote:
>> >> >> 2013/7/17 Roberto Ierusalimschy <roberto@inf.puc-rio.br>
>> >> >>
>> >> >> >  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/