[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Arithmetic on strings
- From: Andrew Starks <andrew.starks@...>
- Date: Wed, 13 Jun 2012 18:53:51 -0500
On Jun 13, 2012, at 17:04, Rena <hyperhacker@gmail.com> wrote:
> On Wed, Jun 13, 2012 at 3:50 PM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
>>> interesting, so what is the trick for
>>>
>>> local t = { 1, 2, "test", true }
>>>
>>> print(table.concat(t))
>>
>> There is no trick in this case. As I said, those cases should be
>> solved in an individual basis. Whether or not table.concat accepts
>> other types is somewhat independent of whether format'%s' accepts
>> other types, etc. Therefore, each function decides what coercions
>> to apply to its arguments. My point is that what each function does
>> can be independent of the coercions done by the language.
>>
>> (It would be interesting if table.concat followed the semantics of '..',
>> but that already is not the case.)
>>
>> -- Roberto
>>
>
> One place that automatic coercion has bit me is in writing C functions
> that accept different types of arguments. For example an "open file"
> function that accepts a path, a numeric file descriptor, or a table
> containing those and some other information.
>
> So the logic looks like:
> if(lua_isstring(L, 1)) /* we have a path */
> else if(lua_isnumber(L, 1)) /* we have an FD */
>
> Who sees the problem there? lua_isstring() will return *true* for
> numbers, because lua_tostring() will silently convert them. So the FD
> path is never reached. OK, simple enough, reverse the check:
>
> if(lua_isnumber(L, 1)) /* we have an FD */
> else if(lua_isstring(L, 1)) /* we have a path */
>
> Should be fine now, right? Still, not quite, because lua_isnumber()
> and lua_tonumber()/lua_tointeger() do the same conversion. That means
> it's no longer possible to open a file with a purely numeric name.
>
> Then the table iteration issue people have mentioned; I've been
> careful to avoid it (at the expense of some extra stack operations
> inside every loop), but who knows how many have been bitten there...
>
> The one place it is nice is in concatenation, when I can write code like:
> assert(things > 3, "only have " .. things .. " things, need at least 3")
> not having to put a tostring() call in there helps make the code
> shorter and more readable.
>
> So, my ideal change would be to remove all implicit conversion between
> strings and numbers, but provide a default __concat that allows
> concatenating numbers and strings.
>
> --
> Sent from my Game Boy.
Perhaps a lua way to set __tostring and __tonumber and a library
function. Like:
string.lazycat(s)
where .. calls tostring on everything. Right now, numbers being
special makes everything else easier I forget. I hate having to
remember to wrap potential nils and boolean, etc. Obviously
string.format helps, but sometimes I know that everything that needs
to go into a literal string needs to be a string...
Not sure if that all make sense.
- References:
- Re: Arithmetic on strings, liam mail
- Re: Arithmetic on strings, Andrew Starks
- Re: Arithmetic on strings, Javier Guerra Giraldez
- Re: Arithmetic on strings, Roberto Ierusalimschy
- Re: Arithmetic on strings, liam mail
- Re: Arithmetic on strings, Hans Hagen
- Re: Arithmetic on strings, Roberto Ierusalimschy
- Re: Arithmetic on strings, Hans Hagen
- Re: Arithmetic on strings, Roberto Ierusalimschy
- Re: Arithmetic on strings, Hans Hagen
- Re: Arithmetic on strings, Roberto Ierusalimschy
- Re: Arithmetic on strings, Rena