Error Text Suggestion for coroutine.status in 5.3

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

Error Text Suggestion for coroutine.status in 5.3

Andrew Starks
I have a minor suggestion to make, regarding the error returned from status:

if you pass status something that isn't a thread, it returns:

`bad argument #1 to 'status' (coroutine expected)`

1: It would be more correct to say "thread", since that is the type. This is slightly confusing to a newbie, because type(value) == "thread" is what you would type to check for it and conceptually, a coroutine is a function with a yield inside of it (as PiL explains it).
2: Most other error returns tell you what it received, along with what it expected. That would be helpful here, too.

Thank you for considering these changes!


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

RE: Error Text Suggestion for coroutine.status in 5.3

Thijs Schreijer


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Andrew Starks
> Sent: vrijdag 29 augustus 2014 0:12
> To: Lua mailing list
> Subject: Error Text Suggestion for coroutine.status in 5.3
>
> I have a minor suggestion to make, regarding the error returned from status:
>
> if you pass status something that isn't a thread, it returns:
>
> `bad argument #1 to 'status' (coroutine expected)`
>
> 1: It would be more correct to say "thread", since that is the type. This is
> slightly confusing to a newbie, because type(value) == "thread" is what you
> would type to check for it and conceptually, a coroutine is a function with
> a yield inside of it (as PiL explains it).
> 2: Most other error returns tell you what it received, along with what it
> expected. That would be helpful here, too.
>
> Thank you for considering these changes!
>
>
> -Andrew

Generally speaking I would like to see all "thread" stuff in Lua being replaced by "coroutine", including the c api. The inconsistencies are confusing. Especially for new comers that tend to think in preemptive OS threads whenever they see the word "thread".

Thijs

 - yes, is breaking, I break stuff all the time.


Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Coroutines
On Thu, Aug 28, 2014 at 11:54 PM, Thijs Schreijer
<[hidden email]> wrote:

> Generally speaking I would like to see all "thread" stuff in Lua being replaced by "coroutine", including the c api. The inconsistencies are confusing. Especially for new comers that tend to think in preemptive OS threads whenever they see the word "thread".

Agree :>

Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Dirk Laurie-2
In reply to this post by Thijs Schreijer
2014-08-29 8:54 GMT+02:00 Thijs Schreijer <[hidden email]>:

> Generally speaking I would like to see all "thread" stuff in Lua
> being replaced by "coroutine", including the c api.

And I would like to see "bike shed" replaced by "velocipede depot" :-)

Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Coroutines
On Fri, Aug 29, 2014 at 12:19 AM, Dirk Laurie <[hidden email]> wrote:

> And I would like to see "bike shed" replaced by "velocipede depot" :-)

I wonder if the bike shed argument has ever been used on this list to
a productive end -- instead of being dismissive and a waste of my mail
quota.

Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Dirk Laurie-2
2014-08-29 9:23 GMT+02:00 Coroutines <[hidden email]>:
> On Fri, Aug 29, 2014 at 12:19 AM, Dirk Laurie <[hidden email]> wrote:
>
>> And I would like to see "bike shed" replaced by "velocipede depot" :-)
>
> I wonder if the bike shed argument has ever been used on this list to
> a productive end -- instead of being dismissive and a waste of my mail
> quota.

Maybe I should have reminded readers that a proposal to change
lua_State to lua_Thread or whatever is also on the table.

If we go along this road, then the "table" library should become
the "sequence" library,

There should be one and only one reason ever to change a name:
because the new name is used for something different.

Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Coroutines
On Fri, Aug 29, 2014 at 12:33 AM, Dirk Laurie <[hidden email]> wrote:

> Maybe I should have reminded readers that a proposal to change
> lua_State to lua_Thread or whatever is also on the table.
>
> If we go along this road, then the "table" library should become
> the "sequence" library,
>
> There should be one and only one reason ever to change a name:
> because the new name is used for something different.

Now that's a reply I can invest some time in reading :-)  More of that.

Reply | Threaded
Open this post in threaded view
|

RE: Error Text Suggestion for coroutine.status in 5.3

Thijs Schreijer
In reply to this post by Dirk Laurie-2

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Dirk Laurie
> Sent: vrijdag 29 augustus 2014 9:20
> To: Lua mailing list
> Subject: Re: Error Text Suggestion for coroutine.status in 5.3
>
> 2014-08-29 8:54 GMT+02:00 Thijs Schreijer <[hidden email]>:
>
> > Generally speaking I would like to see all "thread" stuff in Lua
> > being replaced by "coroutine", including the c api.
>
> And I would like to see "bike shed" replaced by "velocipede depot" :-)

LOL, Once 5.3 is released you'll owe me a beer, so be careful there...
Reply | Threaded
Open this post in threaded view
|

RE: Error Text Suggestion for coroutine.status in 5.3

Thijs Schreijer
In reply to this post by Dirk Laurie-2


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Dirk Laurie
> Sent: vrijdag 29 augustus 2014 9:34
> To: Lua mailing list
> Subject: Re: Error Text Suggestion for coroutine.status in 5.3
>
> 2014-08-29 9:23 GMT+02:00 Coroutines <[hidden email]>:
> > On Fri, Aug 29, 2014 at 12:19 AM, Dirk Laurie <[hidden email]>
> wrote:
> >
> >> And I would like to see "bike shed" replaced by "velocipede depot" :-)
> >
> > I wonder if the bike shed argument has ever been used on this list to
> > a productive end -- instead of being dismissive and a waste of my mail
> > quota.
>
> Maybe I should have reminded readers that a proposal to change
> lua_State to lua_Thread or whatever is also on the table.
>
> If we go along this road, then the "table" library should become
> the "sequence" library,
>
> There should be one and only one reason ever to change a name:
> because the new name is used for something different.

Not necessarily. The examples shown (coroutine/thread and lua_State) are pure legacy, if not now, then sometime in the future you'll have to clean that up, simply because over time you'll be accumulating more and more. And even then backward compatibility is only one #define away (for the c api at least)

Thijs
Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Dirk Laurie-2
2014-08-29 10:21 GMT+02:00 Thijs Schreijer <[hidden email]>:

>> There should be one and only one reason ever to change a name:
>> because the new name is used for something different.
>
> Not necessarily. The examples shown (coroutine/thread and lua_State)
> are pure legacy, if not now, then sometime in the future you'll have to
> clean that up, simply because over time you'll be accumulating more
> and more. And even then backward compatibility is only one #define
> away (for the c api at least)

As far as I am concerned, a lua_State* is something I can pass to
an API routine, containing all the information about necessary stuff
that a user of the API does not need to know. If Roberto and friends
think of that information as a "state", that is good enough for me.

Likewise, if they can write a logical sentence in which the words
"thread" (in the Lua sense) and "coroutine" both appear [1], I do
not consider it proper to tell them it's the same thing. Instead, one
should devote some time pondering the implications of the word
"implement" in that sentence.

So neither of those examples is "pure legacy".

Here is an example of a justified name change:

   Lua 5.1: luaL_register
   Lua 5.2: luaL_setfuncs

Inside module code, they are very similar. Where you used to put
luaL_register(L,NULL,lib), you now put luaL_setfuncs(L,lib,0).
But they have different argument lists, and when all three
arguments are non-trivial, the extra tasks they do are different.

[1]  "The type `thread` represents independent threads of execution
   and it is used to implement coroutines." Lua 5.2 manual, §2.1.

Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Andrew Starks


On Friday, August 29, 2014, Dirk Laurie <[hidden email]> wrote:
2014-08-29 10:21 GMT+02:00 Thijs Schreijer <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;thijs@thijsschreijer.nl&#39;)">thijs@...>:

>> There should be one and only one reason ever to change a name:
>> because the new name is used for something different.
>
> Not necessarily. The examples shown (coroutine/thread and lua_State)
> are pure legacy, if not now, then sometime in the future you'll have to
> clean that up, simply because over time you'll be accumulating more
> and more. And even then backward compatibility is only one #define
> away (for the c api at least)

As far as I am concerned, a lua_State* is something I can pass to
an API routine, containing all the information about necessary stuff
that a user of the API does not need to know. If Roberto and friends
think of that information as a "state", that is good enough for me.

Likewise, if they can write a logical sentence in which the words
"thread" (in the Lua sense) and "coroutine" both appear [1], I do
not consider it proper to tell them it's the same thing. Instead, one
should devote some time pondering the implications of the word
"implement" in that sentence.

So neither of those examples is "pure legacy".

Here is an example of a justified name change:

   Lua 5.1: luaL_register
   Lua 5.2: luaL_setfuncs

Inside module code, they are very similar. Where you used to put
luaL_register(L,NULL,lib), you now put luaL_setfuncs(L,lib,0).
But they have different argument lists, and when all three
arguments are non-trivial, the extra tasks they do are different.

[1]  "The type `thread` represents independent threads of execution
   and it is used to implement coroutines." Lua 5.2 manual, §2.1.


I think that the most important principle is internal consistency. 

Lua expects a value with the type "thread" and not "coroutine". In that sense, status's error string is confusing. Also, every other error of that kind tells you whet it got, instead. So that's a little inconsistent and not as helpful. 

I respect the prodigious refinement of software. But a wise, middle age man (me) once said, names are never "exactly" right. Once they've been chosen, that word takes on that definition to all who use it. It becomes "related" to what it does and that has tremendous value. 

In this case, the two words have a specific meaning:

A "coroutine" is the function that is the value you give to "coroutine.create". You can pass that same value to "create" a hundred times, creating a unique "thread" each time.

The only thing that makes a function a coroutine is that it is being used as an argument for create. So, it's usefull as an expression of the value's role, but not otherwise. (Except when a function contains yield, without being protected by is yieldable())


-Andrew


Analogy: In the same way, you may meet a girl that seems like an even better fit for you than your wife, but your existing relationship (your understanding and history), your mortgage and your kids (your code) have a ton of value. :)
Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Andrew Starks


On Friday, August 29, 2014, Andrew Starks <[hidden email]> wrote:


On Friday, August 29, 2014, Dirk Laurie <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;dirk.laurie@gmail.com&#39;);" target="_blank">dirk.laurie@...> wrote:
2014-08-29 10:21 GMT+02:00 Thijs Schreijer <[hidden email]>:

>> There should be one and only one reason ever to change a name:
>> because the new name is used for something different.
>
> Not necessarily. The examples shown (coroutine/thread and lua_State)
> are pure legacy, if not now, then sometime in the future you'll have to
> clean that up, simply because over time you'll be accumulating more
> and more. And even then backward compatibility is only one #define
> away (for the c api at least)

As far as I am concerned, a lua_State* is something I can pass to
an API routine, containing all the information about necessary stuff
that a user of the API does not need to know. If Roberto and friends
think of that information as a "state", that is good enough for me.

Likewise, if they can write a logical sentence in which the words
"thread" (in the Lua sense) and "coroutine" both appear [1], I do
not consider it proper to tell them it's the same thing. Instead, one
should devote some time pondering the implications of the word
"implement" in that sentence.

So neither of those examples is "pure legacy".

Here is an example of a justified name change:

   Lua 5.1: luaL_register
   Lua 5.2: luaL_setfuncs

Inside module code, they are very similar. Where you used to put
luaL_register(L,NULL,lib), you now put luaL_setfuncs(L,lib,0).
But they have different argument lists, and when all three
arguments are non-trivial, the extra tasks they do are different.

[1]  "The type `thread` represents independent threads of execution
   and it is used to implement coroutines." Lua 5.2 manual, §2.1.


I think that the most important principle is internal consistency. 

Lua expects a value with the type "thread" and not "coroutine". In that sense, status's error string is confusing. Also, every other error of that kind tells you whet it got, instead. So that's a little inconsistent and not as helpful. 

I respect the prodigious refinement of software. But a wise, middle age man (me) once said, names are never "exactly" right. Once they've been chosen, that word takes on that definition to all who use it. It becomes "related" to what it does and that has tremendous value. 

In this case, the two words have a specific meaning:

A "coroutine" is the function that is the value you give to "coroutine.create". You can pass that same value to "create" a hundred times, creating a unique "thread" each time.

The only thing that makes a function a coroutine is that it is being used as an argument for create. So, it's usefull as an expression of the value's role, but not otherwise. (Except when a function contains yield, without being protected by is yieldable())


-Andrew


Analogy: In the same way, you may meet a girl that seems like an even better fit for you than your wife, but your existing relationship (your understanding and history), your mortgage and your kids (your code) have a ton of value. :)

I'm dumb. So, I don't know how I flubbed this so badly, but: 

The error returned by create, imHo, should report that it expected a "function", not a "coroutine". If that distinction is useful to make, then add a note like "this function is the coroutine that runs within the thread" or something. 

But to me, the effort to be more... contextually correct?... makes this error more confusing. "coroutine.create" needs a "function" and there is no such value type "coroutine."

Sorry for the flub.
Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Tim Hill
In reply to this post by Thijs Schreijer

On Aug 29, 2014, at 1:21 AM, Thijs Schreijer <[hidden email]> wrote:

>>
>> 2014-08-29 9:23 GMT+02:00 Coroutines <[hidden email]>:
>>> On Fri, Aug 29, 2014 at 12:19 AM, Dirk Laurie <[hidden email]>
>> wrote:
>>>
>>>> And I would like to see "bike shed" replaced by "velocipede depot" :-)
>>>
>>> I wonder if the bike shed argument has ever been used on this list to
>>> a productive end -- instead of being dismissive and a waste of my mail
>>> quota.
>>
>> Maybe I should have reminded readers that a proposal to change
>> lua_State to lua_Thread or whatever is also on the table.
>>
>> If we go along this road, then the "table" library should become
>> the "sequence" library,
>>
>> There should be one and only one reason ever to change a name:
>> because the new name is used for something different.
>
> Not necessarily. The examples shown (coroutine/thread and lua_State) are pure legacy, if not now, then sometime in the future you'll have to clean that up, simply because over time you'll be accumulating more and more. And even then backward compatibility is only one #define away (for the c api at least)
>
> Thijs

“For historical reasons, a Lua_State represents the current state of a Lua thread (not an operating system thread), including its stack. A state created using lua_newstate() is always the main thread of a new, independent global environment (with it’s own registry etc), while any states created with lua_newthread() are coroutines and share the global environment with the main thread.” (Not quoting, just suggesting how this could be explained.)

Seems clear enough to me. Why break all existing C code just to rename something? And in fact the existing convention works well for the vast majority of cases where the C code never directly has to create anything other than the main thread.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Dirk Laurie-2
In reply to this post by Andrew Starks
2014-08-29 15:41 GMT+02:00 Andrew Starks <[hidden email]>:

> A "coroutine" is the function that is the value you give to "coroutine.create".
...
> The only thing that makes a function a coroutine is that it is being used as
> an argument for create.

Can't agree here.

Quote from the Lua 5.2 manual, in the documentation of create:

   Returns this new coroutine, an object with type "thread".

Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Dirk Laurie-2
In reply to this post by Andrew Starks
2014-08-29 16:05 GMT+02:00 Andrew Starks <[hidden email]>:

>
> I'm dumb. So, I don't know how I flubbed this so badly, but:
>
> The error returned by create, imHo, should report that it expected a
> "function", not a "coroutine". If that distinction is useful to make, then
> add a note like "this function is the coroutine that runs within the thread"
> or something.
>
> But to me, the effort to be more... contextually correct?... makes this
> error more confusing. "coroutine.create" needs a "function" and there is no
> such value type "coroutine."
>
> Sorry for the flub.

You've just flubbed a little more. Your initial post dealt with the error
message from "status". "create" expects a function, true, but says so:

> th=coroutine.create(42)
stdin:1: bad argument #1 to 'create' (function expected, got number)

Returning to the fact that "status" says it expects a coroutine. I agree that
the error message should say that it expects a thread, because it only tests
whether it gets a thread, and that's enough. It also works if you pass the
main thread, not only a thread created by coroutine.create.

Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Andrew Starks


On Friday, August 29, 2014, Dirk Laurie <[hidden email]> wrote:
2014-08-29 16:05 GMT+02:00 Andrew Starks <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;andrew.starks@trms.com&#39;)">andrew.starks@...>:
>
> I'm dumb. So, I don't know how I flubbed this so badly, but:
>
> The error returned by create, imHo, should report that it expected a
> "function", not a "coroutine". If that distinction is useful to make, then
> add a note like "this function is the coroutine that runs within the thread"
> or something.
>
> But to me, the effort to be more... contextually correct?... makes this
> error more confusing. "coroutine.create" needs a "function" and there is no
> such value type "coroutine."
>
> Sorry for the flub.

You've just flubbed a little more. Your initial post dealt with the error
message from "status". "create" expects a function, true, but says so:

> th=coroutine.create(42)
stdin:1: bad argument #1 to 'create' (function expected, got number)

Returning to the fact that "status" says it expects a coroutine. I agree that
the error message should say that it expects a thread, because it only tests
whether it gets a thread, and that's enough. It also works if you pass the
main thread, not only a thread created by coroutine.create.


Sometimes, I really frustrate me...

Thanks for your grace. I had wondered why nobody jumped on my original "error". :) 
Reply | Threaded
Open this post in threaded view
|

Re: Error Text Suggestion for coroutine.status in 5.3

Andrew Starks
In reply to this post by Dirk Laurie-2


On Friday, August 29, 2014, Dirk Laurie <[hidden email]> wrote:
2014-08-29 15:41 GMT+02:00 Andrew Starks <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;andrew.starks@trms.com&#39;)">andrew.starks@...>:

> A "coroutine" is the function that is the value you give to "coroutine.create".
...
> The only thing that makes a function a coroutine is that it is being used as
> an argument for create.

Can't agree here.

Quote from the Lua 5.2 manual, in the documentation of create:

   Returns this new coroutine, an object with type "thread".


I stand corrected (although object seems like the wrong word, given that there are no methods on it. You can't do "my_thread:status()", although that's not a horrible idea, so long as threads could also have their metatable individually re-assigned)

I think that my confussion lies in the expression of the feature as "coroutines" and the fact that there aren't any of those in Lua. There are functions, threads, etc.

I do not suggest any changes here (except for the change to the error reported by status). 

But, it does remind me of tables and the __index metamethod pointing to a table with string keys pointing at function values. We may call them objects, but Lua only knows about tables. (Accepting table:method()).