All your local are belong to us

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

All your local are belong to us

Egor Skriptunoff-2
  Every Lua beginner makes the same mistake: using local variables in
interactive mode of Lua standalone interpreter.

  Probably, it is worth to display a warning "Local variables are lost
due to end of chunk" (or the like) after every chunk consisting solely
of locals definition entered by user in REPL.

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

Re: All your local are belong to us

Dirk Laurie-2
2015-10-02 1:52 GMT+02:00 Egor Skriptunoff <[hidden email]>:

>   Every Lua beginner makes the same mistake: using local variables in
>   interactive mode of Lua standalone interpreter.

Those of us who post code snippets on Lua-L with officious "local"
statements in it, making it unrunnable in the standalone, must bear
at least part of the blame for that. Especially so if that code purports
to answer a newbie's question.

>  Probably, it is worth to display a warning "Local variables are lost
>  due to end of chunk" (or the like) after every chunk consisting solely
>  of locals definition entered by user in REPL.

This could be a useful feature for one of the customizable REPL's
that people announce here from time to time (can't remember the
names, please put up your hands) but IMO does not belong in
"a sample host program called `lua`".

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Hisham
On 2 October 2015 at 05:28, Dirk Laurie <[hidden email]> wrote:
> 2015-10-02 1:52 GMT+02:00 Egor Skriptunoff <[hidden email]>:
>
>>   Every Lua beginner makes the same mistake: using local variables in
>>   interactive mode of Lua standalone interpreter.
>
> Those of us who post code snippets on Lua-L with officious "local"
> statements in it, making it unrunnable in the standalone, must bear
> at least part of the blame for that. Especially so if that code purports
> to answer a newbie's question.

And those who post code snippets on Lua-L _without_ "local" statements
in it must bear part of the blame for the proliferation of unnecessary
globals in a lot of Lua code out there.

I'm of the opinion that any presented code should be of the highest
possible quality, especially in this age of copy-and-paste
programming.

I would be appalled if somehow "don't use locals in examples because
it confuses REPL users" became a recommendation. To me that's an
anti-pattern.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Javier Guerra Giraldez
On Fri, Oct 2, 2015 at 11:17 AM, Hisham <[hidden email]> wrote:
> I would be appalled if somehow "don't use locals in examples because
> it confuses REPL users" became a recommendation. To me that's an
> anti-pattern.


same here.

much better would be if the REPL had some way to enter a whole bunch
of code in a single operation.  maybe some kind of quoting or
parenthesis...

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Roberto Ierusalimschy
> much better would be if the REPL had some way to enter a whole bunch
> of code in a single operation.  maybe some kind of quoting or
> parenthesis...

Something like do-end?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Javier Guerra Giraldez
On Fri, Oct 2, 2015 at 11:30 AM, Roberto Ierusalimschy
<[hidden email]> wrote:
>> much better would be if the REPL had some way to enter a whole bunch
>> of code in a single operation.  maybe some kind of quoting or
>> parenthesis...
>
> Something like do-end?


bingo!

(i don't know why it didn't occur to me... i use do..end all the time
in scripts to contain local vars.  never thought to use in the REPL)

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Dirk Laurie-2
In reply to this post by Hisham
2015-10-02 18:17 GMT+02:00 Hisham <[hidden email]>:
> I would be appalled if somehow "don't use locals in examples because
> it confuses REPL users" became a recommendation. To me that's an
> anti-pattern.

You do as you like, I do as I like. That's called "freedom" in some
social systems.

I try to make it a habit (OK, you will find counterexamples) to post
only code that I have actually tried. I.e. my "-->" comments would
normally be cut-and-pasted from a `lua` session.

<alert> I won't be not repeating this alert. Any code I post here is
a "serving suggestion" and should not be cut-and-pasted as-is
into someone else's module.
</alert>

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Parke
In reply to this post by Roberto Ierusalimschy
On Fri, Oct 2, 2015 at 9:30 AM, Roberto Ierusalimschy
<[hidden email]> wrote:
>> much better would be if the REPL had some way to enter a whole bunch
>> of code in a single operation.  maybe some kind of quoting or
>> parenthesis...
>
> Something like do-end?

do-end allows experienced Lua users to use locals across multiple
lines in the REPL.

do-end does nothing to help new Lua users discover that local does not
work "as expected" in the REPL.

Additionally, do-end is not interactive.  I can never interactively
use any of the locals created in a do-end block.  All such locals
disappear immediately after the end.

Right now, Lua is two separate languages.  In Lua-A, top level locals
persist.  In Lua-B, locals do not persist.  Lua-A is the language you
get when you put multiple statements into a file and run the file with
the "lua" comamnd.  Lua-B is the language you get when you enter the
REPL via the very same "lua" command.

It is not surprising to me that new users are repeatedly confused by
this schism.

Most of the code new users will see is Lua-A.  But new users are
highly likely to try to test their understanding as they learn by
jumping into the REPL.  Where, without warning, they will be using
Lua-B instead!  I imagine this can be highly frustrating and time
consuming for new users, and may well leave them with an unnecessary
bad impression of the language.

Egor's original suggestion was that a warning be added to the REPL to
alert new users of the schism.  A REPL warning in response to
singleton statements of the form "local namelist [‘=’ explist]" seems
like a good idea to me.

-Parke

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Dirk Laurie-2
2015-10-02 20:54 GMT+02:00 Parke <[hidden email]>:

> Egor's original suggestion was that a warning be added to the REPL to
> alert new users of the schism.  A REPL warning in response to
> singleton statements of the form "local namelist [‘=’ explist]" seems
> like a good idea to me.

The difficulty is that this is not a simple matter of changing
a few lines in lua.c. One needs functionality equivalent to
luac to diagnose the situation.

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Coda Highland
On Fri, Oct 2, 2015 at 12:25 PM, Dirk Laurie <[hidden email]> wrote:

> 2015-10-02 20:54 GMT+02:00 Parke <[hidden email]>:
>
>> Egor's original suggestion was that a warning be added to the REPL to
>> alert new users of the schism.  A REPL warning in response to
>> singleton statements of the form "local namelist [‘=’ explist]" seems
>> like a good idea to me.
>
> The difficulty is that this is not a simple matter of changing
> a few lines in lua.c. One needs functionality equivalent to
> luac to diagnose the situation.
>

This isn't necessarily true. One COULD, for example, just see if the
beginning of the input line consists of 0+ whitespace characters,
followed by the string "local", followed by 1+ whitespace characters,
and emit the warning only in this case. (This would also catch "local
function".)

For a more involved but probably more robust solution, it would also
be possible to install a debug hook in each created chunk that would
determine if new locals were introduced (perhaps, for instance, by
checking lua_getlocal with an index of 1 and seeing if it returns
non-NULL) and then emit the warning. In this case, it may even be
possible to emit the names of the locals that would be lost, which
could be a further useful piece of information.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Jonathan Goble

Rather than get overly complicated, why not just print a one-line warning when the interpreter is first started, under the version number and copyright info and before the first prompt? Quick, simple, and no parsing needed. Something like "Warning: local declarations will not persist beyond the line on which they are entered." would be sufficient.

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Coda Highland
On Fri, Oct 2, 2015 at 1:01 PM, Jonathan Goble <[hidden email]> wrote:
> Rather than get overly complicated, why not just print a one-line warning
> when the interpreter is first started, under the version number and
> copyright info and before the first prompt? Quick, simple, and no parsing
> needed. Something like "Warning: local declarations will not persist beyond
> the line on which they are entered." would be sufficient.

Because that wouldn't actually solve the problem of inexperienced
users overlooking the issue.

Humans are tuned to associate cause and effect. You do something,
something else happens, you pay attention, you learn.

Humans are also tuned to ignore repetitive stimuli. When you see a
message pop up in the same place every time you start the program, the
information in it stops being perceived as salient.

By putting the message on every startup, you're just producing a
warning that's going to get ignored. The message informing the user of
the problem is separated in both time and space from the cause of the
problem (worse, it precedes it, and humans are REALLY bad at seeing
correlations when they're time-reversed).

It also runs the risk of being perceived as patronizing -- experienced
users aren't going to want to be reminded every time they start up the
interpreter; that's just more noise on the terminal.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Patrick Donnelly
In reply to this post by Dirk Laurie-2
On Fri, Oct 2, 2015 at 3:25 PM, Dirk Laurie <[hidden email]> wrote:

> 2015-10-02 20:54 GMT+02:00 Parke <[hidden email]>:
>
>> Egor's original suggestion was that a warning be added to the REPL to
>> alert new users of the schism.  A REPL warning in response to
>> singleton statements of the form "local namelist [‘=’ explist]" seems
>> like a good idea to me.
>
> The difficulty is that this is not a simple matter of changing
> a few lines in lua.c. One needs functionality equivalent to
> luac to diagnose the situation.

It's simpler than that. You can use lua_getlocal to determine if the
chunk defined any locals.

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Patrick Donnelly
On Fri, Oct 2, 2015 at 4:48 PM, Patrick Donnelly <[hidden email]> wrote:

> On Fri, Oct 2, 2015 at 3:25 PM, Dirk Laurie <[hidden email]> wrote:
>> 2015-10-02 20:54 GMT+02:00 Parke <[hidden email]>:
>>
>>> Egor's original suggestion was that a warning be added to the REPL to
>>> alert new users of the schism.  A REPL warning in response to
>>> singleton statements of the form "local namelist [‘=’ explist]" seems
>>> like a good idea to me.
>>
>> The difficulty is that this is not a simple matter of changing
>> a few lines in lua.c. One needs functionality equivalent to
>> luac to diagnose the situation.
>
> It's simpler than that. You can use lua_getlocal to determine if the
> chunk defined any locals.

Nevermind, no you can't. When you run lua_getlocal on a closure, you
only get information about its parameters. I thought there was an API
to get the local count but I guess not...

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Gregg Reynolds-2
In reply to this post by Egor Skriptunoff-2


On Oct 1, 2015 6:52 PM, "Egor Skriptunoff" <[hidden email]> wrote:
>
>   Every Lua beginner makes the same mistake: using local variables in
> interactive mode of Lua standalone interpreter.

That's called learning,  and working through it is a valuable  experience.

>
>   Probably, it is worth to display a warning "Local variables are lost
> due to end of chunk" (or the like) after every chunk consisting solely
> of locals definition entered by user in REPL.
>
> -- Egor

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Coda Highland
In reply to this post by Patrick Donnelly
On Fri, Oct 2, 2015 at 1:51 PM, Patrick Donnelly <[hidden email]> wrote:

> On Fri, Oct 2, 2015 at 4:48 PM, Patrick Donnelly <[hidden email]> wrote:
>> On Fri, Oct 2, 2015 at 3:25 PM, Dirk Laurie <[hidden email]> wrote:
>>> 2015-10-02 20:54 GMT+02:00 Parke <[hidden email]>:
>>>
>>>> Egor's original suggestion was that a warning be added to the REPL to
>>>> alert new users of the schism.  A REPL warning in response to
>>>> singleton statements of the form "local namelist [‘=’ explist]" seems
>>>> like a good idea to me.
>>>
>>> The difficulty is that this is not a simple matter of changing
>>> a few lines in lua.c. One needs functionality equivalent to
>>> luac to diagnose the situation.
>>
>> It's simpler than that. You can use lua_getlocal to determine if the
>> chunk defined any locals.
>
> Nevermind, no you can't. When you run lua_getlocal on a closure, you
> only get information about its parameters. I thought there was an API
> to get the local count but I guess not...

lua_gettop() is basically that.

But as I was suggesting, use a debug hook -- it'll fire after the
contents of the input are executed, but before the chunk returns.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Paul E. Merrell, J.D.
In reply to this post by Gregg Reynolds-2
On Fri, Oct 2, 2015 at 1:57 PM, Gregg Reynolds <[hidden email]> wrote:
>
>>   Every Lua beginner makes the same mistake: using local variables in
>> interactive mode of Lua standalone interpreter.
>
> That's called learning,  and working through it is a valuable  experience.

Point noted. But it's also important to keep in mind that Lua has
users with different proficiency levels. The existing documentation is
great for the proficient but very poor for a newbie with no
programming experience.  For example, the manual says that an ellipsis
("...") is a reserved character but never explains its functionality.
Likewise, the Manual is rife with words and phrases that are commonly
understood by experienced programmers but come across as Klingon to
newbies.

In my mind, the biggest thing that has held Lua back from much wider
adoption is the dearth of documentation for newbies.

I return to my suggestion that we get the documentation into a wiki
that can be annotated with example code, notes, and links.

'Nuff said.

Best regards,

Paul


--
[Notice not included in the above original message:  The U.S. National
Security Agency neither confirms nor denies that it intercepted this
message.]

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Andrew Starks
On Fri, Oct 2, 2015 at 7:41 PM, Paul Merrell <[hidden email]> wrote:

> On Fri, Oct 2, 2015 at 1:57 PM, Gregg Reynolds <[hidden email]> wrote:
>>
>>>   Every Lua beginner makes the same mistake: using local variables in
>>> interactive mode of Lua standalone interpreter.
>>
>> That's called learning,  and working through it is a valuable  experience.
>
> Point noted. But it's also important to keep in mind that Lua has
> users with different proficiency levels. The existing documentation is
> great for the proficient but very poor for a newbie with no
> programming experience.  For example, the manual says that an ellipsis
> ("...") is a reserved character but never explains its functionality.
> Likewise, the Manual is rife with words and phrases that are commonly
> understood by experienced programmers but come across as Klingon to
> newbies.
>
> In my mind, the biggest thing that has held Lua back from much wider
> adoption is the dearth of documentation for newbies.
>
> I return to my suggestion that we get the documentation into a wiki
> that can be annotated with example code, notes, and links.
>
> 'Nuff said.
>
> Best regards,
>
> Paul
>
>
> --
> [Notice not included in the above original message:  The U.S. National
> Security Agency neither confirms nor denies that it intercepted this
> message.]
>

Another approach would be to distribute a version of Lua that was
specifically designed for command line consumption. Which is only a
lot bit close to the whole "Batteries" thread.

There is a line between "Embedded Scripting Language" and what PERL
is. Adding thoughtful hints like this makes even more sense, when
there is a reasonable library, package manager, etc.

Since Lua's REPL is mostly useful when developing Lua applications, it
seems like its terse and "documented only just enough" approach is
consistent with the rest of Lua.

An enhanced and possibly more verbose repl seems like a great fit for LuaDIST.

-Andrew

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Dirk Laurie-2
In reply to this post by Paul E. Merrell, J.D.
2015-10-03 2:41 GMT+02:00 Paul Merrell <[hidden email]>:

> In my mind, the biggest thing that has held Lua back from
> much wider adoption is the dearth of documentation for newbies.

You mean, there should be easily available, preferably online
documentation something like this?

-----
To keep with the tradition, our first program in Lua just prints "Hello World":

    print("Hello World")

If you are using the stand-alone Lua interpreter, all you have to do
to run your first program is to call the interpreter (usually named
lua) with the name of the text file that contains your program. For
instance, if you write the above program in a file hello.lua, the
following command should run it:

    prompt> lua hello.lua
-----

Reply | Threaded
Open this post in threaded view
|

Re: All your local are belong to us

Paul E. Merrell, J.D.
On Fri, Oct 2, 2015 at 9:33 PM, Dirk Laurie <[hidden email]> wrote:

> You mean, there should be easily available, preferably online
> documentation something like this?
>
> -----
> To keep with the tradition, our first program in Lua just prints "Hello World":
>
>     print("Hello World")
>
> If you are using the stand-alone Lua interpreter, all you have to do
> to run your first program is to call the interpreter (usually named
> lua) with the name of the text file that contains your program. For
> instance, if you write the above program in a file hello.lua, the
> following command should run it:
>
>     prompt> lua hello.lua

Not necessarily, although a link to a "Getting Started" set of pages
would be nice.

I had more in mind a copy of the Reference Manual, 1 section per page,
with the ability to link terms we take for granted to definitions, to
illustrative portions of the existing wiki, to related articles, to
archived emails that answer questions ...

More an annotated Reference Manual, using the manual's organization as
the structure. The basic goal being to make the (annotated) Manual
more useful to newbies.

Of course, that's just my fantasy. Others may have better fantasies.

Best regards,

Paul
--
[Notice not included in the above original message:  The U.S. National
Security Agency neither confirms nor denies that it intercepted this
message.]

12