Re: Are automatic coercions ever going away?

[Steven Degutis <sbdegutis@...>]

In my short 5 years of development experience, I've learned very
thoroughly that simplicity and straightforwardness are always the best
policies. In fact one of the primary reasons I have come to love Lua
is because it takes these policies so completely seriously, as opposed
to my previous favorite dynamic languages (Ruby and Python). Although,
Lua does give a little more power than I'll ever use; I admit that I
never create or use any "class system" in Lua except for the
dead-simple case of using __index to let me type foo:bar() instead of
foo.bar(foo).

>From this perspective, I /always/ know what types I'm dealing with.
Always. And I love that the documentation is 99% of the time
extremely-clear on what types are being given to me from what
operations. (There are a few functions whose documentation is
ambiguous; plus I always assume the error object of a failed
(lua_)pcall is not yet a string.)

That's why I was kind of surprised to read about automatic coercions
when I bought PIL third edition a few weeks ago. (Excellent book btw,
Roberto.) This feature seems like a blot in an otherwise very clean
and simple language. But I was glad that the author agreed in the text
that it's probably not the best idea, and that he discouraged using it
in new code. In all honestly, I never use it anyway; I use tonumber()
and tostring() as needed, and have never noticed the slightest
inconvenience of this over typing i..s or s + i... it's a few
characters more, but what's happening is extremely clear and
straightforward and simple.

That said, I would love for coercions it be disabled by default in Lua
5.3 -- but a compiler option to enable them seems reasonable, just
like how `loadstring` is still available in Lua 5.2 even though it's
been deprecated. But if Lua 5.3 is going to break backwards
compatibility anyway with integer division, it might as well be the
perfect opportunity to finally remove this misfeature too.

But like I said, I only have 5 years experience in this field. I am
still what they call "a newbie" so feel free to take my opinion with a
grain of salt.

-Steven

On Fri, Aug 1, 2014 at 10:36 AM, Coroutines <coroutines@gmail.com> wrote:
> On Fri, Aug 1, 2014 at 8:19 AM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
>
>> Just a few days ago we sent a message stating that we are not sure about
>> this whole thing anymore [1]. You probably missed it.
>
>
> I have trouble taking the whole 'coercion in lua is bad' thing anyway.
> It's not like Javascript where you can concatenate and add two things
> together with the same operator (+).  I am never confused about this
> in Lua as + will derive numbers, and .. will derive strings.  There is
> no overlap for operator use.  I don't find these "coercion sites" very
> ambiguous even if metamethods are called from left-to-right on
> availability.  I'm just tired of people who hate coercion in every
> language speaking like they know what's best for Lua from an
> ideological pedestal.  I do agree that have the option to disable or
> leave enabled coercion might have the potential for a fragmented Lua
> community, but I find the prospect very unlikely.  The only rift I've
> ever seen has been between Lua<->LuaJIT.
>
> I can't think of any such places but I know there must be code hiding
> in the C side of Lua where coercion should be possible (following the
> normal rules) but isn't.  I'd like to see more work done to remove
> these situations -- otherwise I'm already happy.
>
> Go Brazil?
>
> PS: I feel like certain others only want coercion gone so they can do
> compile-time static type analysis.  I have never needed this as
> important as it sounds... my view seems less 'shallow' at runtime.
> Quack quack.
>