lua "local" attribute seems to cause problems

[Lawrence Emke]

I just trashed my chrome pixel (OS) penguin container, and removed

and reinstalled the Debian environment.

Ran apt "update / dist-upgrade"

then ran "sudo apt install lua5.4"

with the simple install I ran 'lua" from the command line.

Entered the follow interactive input:

------------------------------------------------------------------

penguin-$lua
Lua 5.4.4  Copyright (C) 1994-2022 Lua.org, PUC-Rio
> local aaa = 9
> print(aaa)
nil
> b = 4
> print(b)
4
>

-------------------------------------------------------------------------

as you can see the variable create with the "local" attribute

does not function correctly (i.e. the "nil" print result

When I defined a variable without the "local" attribute

the variable works correctly and the print function has no problem

------

I there any problem reported on this problem? If the "local"

attribute is eliminated, the variable ends up in the global scope!

I don't know if this occurs for variables defined within a function definition.

If it does, there is going to be a BIG problem.

Looking for a "fix"  - any help is appreciated

 

[wfrsk]

It is not an issue, the REPL executes each "line" in different function, so local variables across multiple "lines" do not persist.

Of course, global variables do, since the aforementioned functions are still executed under the same environment.

Sent with Proton Mail secure email.

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lua-l/3d66f9b2-7b03-4fa1-8f70-06355355a595n%40googlegroups.com.

[Lawrence Emke]

Thanks for the information. I did not realize that was the way that the interactive environment works.

Problem solved!

Thanks

[blog...@gmail.com]

Yes local no save on new line in command line mode, but you can use  this

```

dron@gnu:~/$ lua5.4
Lua 5.4.6  Copyright (C) 1994-2023 Lua.org, PUC-Rio
> load[[

>> local aaa = 9
>> print(aaa)

>> ]]()
9

```

:D

вторник, 30 апреля 2024 г. в 00:42:22 UTC+3, Lawrence Emke:

[Luiz Henrique de Figueiredo]

If you want locals to survive, enclose the code in a do-end block:

do

local aaa = 9
print(aaa)

end

[Charles Heywood]

You can use `do` to start a lexical block and `end` to end it. This creates a scope for variables to live in.

Each line of the interpreter, if it can be run by itself (i.e. not a block), is run as its own lexical scope.

Ryan Heywood <vando...@gmail.com>

--

[Rett Berg]

I hit this problem as well and found it frustrating. Would you accept a PR which threw an error if the first word in the command was `local`? I think this would solve 99% of actual mis-uses.

[blog...@gmail.com]

>Would you accept a PR which threw an error if the first word in the command was `local`?

I thing it not resolve problems, but create problems and broke use `do ... end` case

> do
>> local a = 5; -- make error for this?
>> print(a)
>> end
5

>

And broke all copypasted code in do ... end body

And maybe more something

Maximum we can do it sey for user in new line "you local varname is local and deleted" but we again need check this varname in do ... end scoupe or not?

Maybe just sey for in start  this

dron@gnu:~$ lua5.4

Lua 5.4.6  Copyright (C) 1994-2023 Lua.org, PUC-Rio

Notice: local variables no visible on after new line

> 

Becouse local in REPL mode it not error it  just peculiarity.

And in general, it seems to me that this is not a problem, but just one of hundreds of things that you just need to know and that’s it.

среда, 1 мая 2024 г. в 01:14:29 UTC+3, Rett Berg:

[Denn...@protonmail.com]

On Tuesday, April 30th, 2024 at 10:14 PM, Rett Berg <goog...@gmail.com> wrote:

> I hit this problem as well and found it frustrating. Would you accept a PR which threw an error if the first word in the command was `local`? I think this would solve 99% of actual mis-uses.

I would advise against this. I usually use this behavior to its
advantage for small tests by writing one-liners in the interpreter,
such as

local x = 5 print(x)

Although having the user input a useless statement (such as
"local x = 5" by itself) would be bad, making a distinction about it
seems excessive. Even if you have a system to detect for genuine
operation, I think it would be better to assume users know what they
are doing over assuming they don't.

[bil til]

Am Mi., 1. Mai 2024 um 01:44 Uhr schrieb blog...@gmail.com <blog...@gmail.com>:
>
> Lua 5.4.6 Copyright (C) 1994-2023 Lua.org, PUC-Rio
> Notice: local variables no visible on after new line

Giving this "do ...local ... print ... end" example (and the contrast
to "local...print" without "do...end" encapsulation) I think would be
really helpful in the ref manual, best I think in 3.2 "Variables"
where local also "generally is introduced'". Maybe with the remark,
that the "sense of local" is mainly to define variables in NON-global
code parts.

(I was surprised myself by this difference, I must admit - although I
am not TOTAL Lua newbee... but I seldom work with global code in Lua,
practically all my Lua code is anyway "encapsulated in functions", and
there you do not meet this "single line pecularity of local", as far
as I see it).

[Rett Berg]

How about if it was just a warning? You could easily disable it by using a ';' as the first character.

The problem is normally local works across lines, so it's surprising behavior for many folks 

--
You received this message because you are subscribed to a topic in the Google Groups "lua-l" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lua-l/f3qgqzOXiro/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lua-l+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lua-l/wWwDtAGtzxoaKMp6NbRnJoUSTVdipsdnTbZBIo-UGmdgZ5Y8yAyCCCWJ9e8K3Gs1yVGYAF4Q-_uOQB3cPjVhWESFbSyepFEeNmUzlZICxXk%3D%40protonmail.com.

[Gerhard Sittig]

On Wed, 2024-05-01 at 12:30 +0200, bil til wrote:
>
> Giving this "do ...local ... print ... end" example (and the contrast
> to "local...print" without "do...end" encapsulation) I think would be
> really helpful in the ref manual, best I think in 3.2 "Variables"
> where local also "generally is introduced'".

I'd disagree. The issue of the 'local' keyword "hiding" the
variable after execution of the chunk is not a language feature
(i.e. the library), but instead is an implementation detail of
the REPL (an example application, one of several possible).

Yes the lua(1) manpage may need adjustment. It discusses that
lines are read, and tried to compile, before execution. My local
copy talks about "statements" while I think this should read
"chunk" instead. And I guess it's appropriate to assume that
lua(1) interpreter users are a kind of programmer, while those
who create scripts or config files may not be to the same degree.
If that makes sense to you. Execution of scripts exactly follows
the language's description in the reference, and does not
"suffer" from the example application's implementation detail of
collecting chunks and executing them, including all consequences.


virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.

[Roberto Ierusalimschy]

> If you don't understand or are scared by any of the above
> ask your parents or an adult to help you.

I believe this phrase is not addressed to anyone in particular, but
anyway it would be polite to avoid it in this list. Many thanks,

-- Roberto

[bil til]

>Am Mi., 1. Mai 2024 um 17:46 Uhr schrieb 'Gerhard Sittig' via lua-l <lu...@googlegroups.com>:
> Yes the lua(1) manpage may need adjustment. It discusses that
> lines are read, and tried to compile, before execution.

... btw. this "local own chunk" pecularity is explained in detail and
very well in Roberto's Book "Programming in Lua", Cahpter 8, "Local
Variables and Blocks".

(sorry, I looked up "PiL" book a bit late here... there really you
typically find the "more application programming related tricks+hints"
in comparison on the more "language strict" Ref manual of Lua... ).

[Gerhard Sittig]

On Fri, 2024-05-03 at 09:23 +0200, bil til wrote:
>
> >Am Mi., 1. Mai 2024 um 17:46 Uhr schrieb 'Gerhard Sittig' via lua-l <lu...@googlegroups.com>:
> > Yes the lua(1) manpage may need adjustment. It discusses that
> > lines are read, and tried to compile, before execution.
>
> ... btw. this "local own chunk" pecularity is explained in detail and
> very well in Roberto's Book "Programming in Lua", Cahpter 8, "Local
> Variables and Blocks".

You deleted the more important part of what I wrote, the
"statement vs chunk" reference. The full context was:

Yes the lua(1) manpage may need adjustment. It discusses that

lines are read, and tried to compile, before execution. My local
copy talks about "statements" while I think this should read

"chunk" instead. [ ... ]

It's well understood that a REPL interpreter does take input, and
processes it, and may generate output. The very issue discussed
in this thread was that users expected that individual REPL
activities would be "coupled" instead of separate from each
other. They share global state. But local activities in one chunk
would not transpire to other chunks. Which becomes apparent when
looking at the example application's implementation details, but
isn't obvious before becoming aware of these details.

Had a look at more recent sources than the installation which I
was referring to earlier. File lua-5.4.6/doc/lua.1 still reads:

In interactive mode, lua prompts the user, reads lines from
the standard input, and executes them as they are read. If
the line contains an expression, then the line is evaluated
and the result is printed. If a line does not contain a
complete statement, then a secondary prompt is displayed and
lines are read until a complete statement is formed or a
syntax error is found.

Can't tell "how much Zen" is in the question of whether a "do ...
end" block is "a statement". Granted it's a compound statement.
Which happens to include several other statements in its body.
The missing information is the execution in separate chunks, as
soon as the input text "gets committed" (full line) and compiles
successfully. Such a chunk can be more than one statement (see
earlier examples in the thread).


The point remains: Passing one script to the runtime which is
taken as one chunk, and passing several pieces of input to the
REPL interpreter, which processes them in separate chunks that
don't share local context, makes the difference here.

The question is how the documentation that ships with the lua(1)
application can communicate that detail to its users. Referencing
"external literature" like the Blue PiL can be perfectly
acceptable, as long as users have the chance to know, or learn.

It's important to remain aware that the PiL is not an integral
part of the distribution of the Lua reference implementation. Two
editions exist, targetting 5.0 and 5.3 respectively. The PiL
doesn't ship with the interpreter, and its content may disagree
with the interpreter's and runtime's versions that users have.
That's fine, since the PiL is considered an independent external
thing. That's why I wouldn't consider it to be _the_
documentation that users own or have access to, and must know.

Another option is to not assume PiL awareness at the user's, and
reference a FAQ. It's a known pitfall and the solution is also
known (drop the 'local' decoration, or create wider scopes).


Some users still use the (free) online version which discusses
5.0 when they run local installations that are 5.3 or 5.4. That's
fine as long as they do the translation and adaption on their
side. And me mentioning that PiL is separate and external doesn't
mean that it should come for free or needs to be part of the
distribution. It's a great read and a valuable resource in
learning the language and mastering embedding et al, and worth
getting anyway when you are serious. This is not a critique.

My point is: How can formerly unexpecting users become aware,
understand the detail, and accept the fact. To then successfully
use the tool and enjoy, knowing it works correctly. How can they
learn that there is no problem without reading the source code.

Is such a phrase considered useful?

Interactively entered source code executes in separate chunks
sharing the same Lua state. Local details are not available to
other chunks.

[Gerhard Sittig]

This has always been there. Just was handled properly back when
dashlines used to work. Seems the most recent switch of the ML
hosting broke that email feature as well. :(

Am assuming that grown ups can tell it's said with tongue in
cheek. Others may need to grow up, or seek help indeed.

But I get your point, and will try to remember. Or respond less.

[Gerhard Sittig]

On Sat, 2024-05-04 at 10:43 +0200, Gerhard Sittig wrote:
>
> It's important to remain aware that the PiL is not an integral
> part of the distribution of the Lua reference implementation. Two
> editions exist, targetting 5.0 and 5.3 respectively.

Have obviously missed the other editions. They exist for 5.0 and
up to 5.3, including 5.1 and 5.2 as well. Sorry.