Re: Inconsistent Multiline String Handling in Lua REPL (Direct Input vs. History Recall)
jure bagic <[email protected]> Fri, 31 Jul 2026 09:11:43 +0200
| Newsgroups | gmane.comp.lang.lua.general |
|---|---|
| Message-ID | <CAOmpovrwrYuLpHvuPi8Sjv-DWaQF1PaibNGh=czgCKUZx=YEpQ@mail.gmail.com> |
--00000000000072fba20657e2e715 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lua REPL accepts lines of text, when you press enter the REPL first puts "return" before your input and tries to compile it. For example > 69*enter* is actually > return 69*enter* Try doing > 4, 2, 0*enter* If such expression compiles, REPL skips trying to compile your input as statement. Then the compiled function (with prepended 'return' followed by your input) is called in order to obtain those values on the stack and finally those values are used as arguments to global function 'print' (part of basic library). Otherwise, when compilation with implicit 'return' fails, REPL tries to compile your input as statement using a clever hack (in my opinion). As long as the input cannot be compiled (syntax error), it checks end of the error message to see of it ends with '<eof>' string. This indicates an incomplete statement as syntax error will be "near <eof>" (end of file =3D= =3D end of input) because another token was expected before input suddenly ended. And then it prompts second time (with '>>') and so on... So when you do history, you are sending entire expression at once, in other words your input can contain multiple newlines because technically you only pressed enter once. -- Jure On Fri, Jul 31, 2026, 06:46 mathieu stumpf-guntz <[email protected]> wrote: > Hello Martin and Roberto, > > Thank you very much for all of your insights, that=E2=80=99s very enlight= ening, > though I=E2=80=99ll have to meditate and play a bit more around with it b= efore > integrating the full lesson here I guess. > > To respond your question Martin, maybe in a broader fashion than the way > you where initially conducting it, what I would expect is a bit less > surprise in behaviour while interacting with the interpreter. Though I ca= n > get the point that, this or that surprising behavior can be the expected > result according to the grammar and the documentation. Even sitting firml= y > in that scope, having a consistent behavior for the same input whatever t= he > input method seems to dwell on an other level of expectation. Consider th= e > following session: > Lua 5.3.6 Copyright (C) 1994-2020 Lua.org, PUC-Rio > > [[ > >> test > >> ]] =3D=3D "test\n" > stdin:3: unexpected symbol near '[[test > ]]' > > [[ > test > ]] =3D=3D "test\n" > true > > [[ > test > ]] =3D=3D "test\n" > false > > [[ > test > ]] =3D=3D "test\n" > false > > [[ > test > ]] =3D=3D "test\n" > true > > So what happen here: > - I typed manually the boolean test and got printed an error informing me > of an ill formed construction, fair enough. > - Through history facility I select again this ill formed construction an= d > launch interpretation which eventually returns true and prints accordingl= y. > - Then I copy/pasted the whole code snippet in the interpreter, and was > informed this time that this is false, the matching value representation > being printed. > - Then picking this very last entry in history and running it, I still ge= t > false printed. > - Finally, picking instead in history the earliest item available, we are > back to true being printed. > > Just reading the session transcript, one could certainly spot what=E2=80= =99s > happening in the directly typed entry thanks the extra `>` hint. But > without the previous explanations, one would certainly have a hard time > inferring what has actually been done in the subsequent interactions. > > I hope this clarify what I mean when I say I would expect a more > consistent behavior in the REPL. > > Kind regards, > Mathieu > On Thursday, July 30, 2026 at 4:42:55=E2=80=AFPM UTC Martin Eden wrote: > >> >> On 2026-07-30 18:05, mathieu stumpf-guntz wrote: >> > Not sure what you mean here, but in my previous examples I didn=E2=80= =99t mean >> > I used any magic sequence, the "\n" was actually literal new lines. So >> > to make it clear, the test conducted was more like `echo -e >> > '[[\ntest\n]]' | lua`, which ends up (in all configurations I was >> > able to try) with >> > lua: stdin:3: unexpected symbol near '[[test >> > ]]' >> >> Well that's a different thing! It gives same error for me too. >> >> So as >> >> $ echo -e '123' | lua >> lua: stdin:1: unexpected symbol near '123' >> >> What result you expect? >> >> "lua" program in interactive mode silently places expressions >> inside "print()". That's neat feature to use it as calculator. >> >> But neither "[[\ntest\n]]" nor "123" is valid Lua code: >> they are expressions, not statements. >> >> -- Martin >> >> >> -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/lua-l/72c88ccc-765c-4d7f-9b19-cf6d5b4a5= 09fn%40googlegroups.com > <https://groups.google.com/d/msgid/lua-l/72c88ccc-765c-4d7f-9b19-cf6d5b4a= 509fn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter> > . > --=20 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 e= mail to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/lua-l/CAOmp= ovrwrYuLpHvuPi8Sjv-DWaQF1PaibNGh%3DczgCKUZx%3DYEpQ%40mail.gmail.com. --00000000000072fba20657e2e715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto">Lua REPL accepts lines of text, when yo= u press enter the REPL first puts "return" before your input and = tries to compile it.</div><div dir=3D"auto"><br></div><div dir=3D"auto">For= example</div><div dir=3D"auto">> 69*enter*</div><div dir=3D"auto">is ac= tually</div><div dir=3D"auto">> return 69*enter*</div><div dir=3D"auto">= <br></div><div dir=3D"auto">Try doing</div><div dir=3D"auto">> 4, 2, 0*e= nter*</div><div dir=3D"auto"><br></div><div dir=3D"auto">If such expression= compiles, REPL skips trying to compile your input as statement.</div><div = dir=3D"auto">Then the compiled function (with prepended 'return' fo= llowed by your input) is called in order to obtain those values on the stac= k and finally those values are used as arguments to global function 'pr= int' (part of basic library).</div><div dir=3D"auto"><br></div><div dir= =3D"auto">Otherwise, when compilation with implicit 'return' fails,= REPL tries to compile your input as statement using a clever hack (in my o= pinion). As long as the input cannot be compiled (syntax error), it checks = end of the error message to see of it ends with '<eof>' strin= g. This indicates an incomplete statement as syntax error will be "nea= r <eof>" (end of file =3D=3D end of input) because another token= was expected before input suddenly ended. And then it prompts second time = (with '>>') and so on...</div><div dir=3D"auto"><br></div><di= v dir=3D"auto">So when you do history, you are sending entire expression at= once, in other words your input can contain multiple newlines because tech= nically you only pressed enter once.</div><div dir=3D"auto"><br></div><div = dir=3D"auto">-- Jure</div></div><br><div class=3D"gmail_quote gmail_quote_c= ontainer"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 31, 2026, 06:46= mathieu stumpf-guntz <<a href=3D"mailto:[email protected]">psychosl= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>H= ello Martin and Roberto,</div><div><br></div><div>Thank you very much for a= ll of your insights, that=E2=80=99s very enlightening, though I=E2=80=99ll = have to meditate and play a bit more around with it before integrating the = full lesson here I guess.</div><div><br></div><div>To respond your question= Martin, maybe in a broader fashion than the way you where initially conduc= ting it, what I would expect is a bit less surprise in behaviour while inte= racting with the interpreter. Though I can get the point that, this or that= surprising behavior can be the expected result according to the grammar an= d the documentation. Even sitting firmly in that scope, having a consistent= behavior for the same input whatever the input method seems to dwell on an= other level of expectation. Consider the following session:<br><div style= =3D"background-color:rgb(30,31,34);color:rgb(188,190,196)"><span style=3D"f= ont-family:"JetBrains Mono",monospace">Lua 5.3.6 Copyright (C) 1= 994-2020 Lua.org, PUC-Rio<br>> [[<br>>> test<br>>> ]] =3D=3D= "test\n"<br>stdin:3: unexpected symbol near '[[test<br>]]= 9;<br>> [[</span></div><div style=3D"background-color:rgb(30,31,34);colo= r:rgb(188,190,196)"><span style=3D"font-family:"JetBrains Mono",m= onospace">test</span></div><div style=3D"background-color:rgb(30,31,34);col= or:rgb(188,190,196)"><span style=3D"font-family:"JetBrains Mono",= monospace">]] =3D=3D "test\n"<br>true<br>> [[</span></div><div= style=3D"background-color:rgb(30,31,34);color:rgb(188,190,196)"><span styl= e=3D"font-family:"JetBrains Mono",monospace">test</span></div><di= v style=3D"background-color:rgb(30,31,34);color:rgb(188,190,196)"><span sty= le=3D"font-family:"JetBrains Mono",monospace">]] =3D=3D "tes= t\n"<br>false<br>> [[</span></div><div style=3D"background-color:rg= b(30,31,34);color:rgb(188,190,196)"><span style=3D"font-family:"JetBra= ins Mono",monospace">test</span></div><div style=3D"background-color:r= gb(30,31,34);color:rgb(188,190,196)"><span style=3D"font-family:"JetBr= ains Mono",monospace">]] =3D=3D "test\n"<br>false<br>> [[= </span></div><div style=3D"background-color:rgb(30,31,34);color:rgb(188,190= ,196)"><span style=3D"font-family:"JetBrains Mono",monospace">tes= t</span></div><div style=3D"background-color:rgb(30,31,34);color:rgb(188,19= 0,196)"><span style=3D"font-family:"JetBrains Mono",monospace">]]= =3D=3D "test\n"<br>true</span></div><br>So what happen here:</di= v><div>- I typed manually the boolean test and got printed an error informi= ng=20 me of an ill formed construction, fair enough.</div><div>- Through history = facility I=20 select again this ill formed construction and launch interpretation=20 which eventually returns true and prints accordingly.<br>- Then I copy/past= ed the whole code snippet in the interpreter, and was informed this time th= at this is false, the matching value representation being printed.</div><di= v>- Then picking this very last entry in history and running it, I still ge= t false printed.</div><div>- Finally, picking instead in history the earlie= st item available, we are back to true being printed.</div><div><br></div><= div></div><div>Just reading the session transcript, one could certainly spo= t what=E2=80=99s happening in the directly typed entry thanks the extra `&g= t;` hint. But without the previous explanations, one would certainly have a= hard time inferring what has actually been done in the subsequent interact= ions.</div><div><br></div><div>I hope this clarify what I mean when I say I= would expect a more consistent behavior in the REPL.=C2=A0</div><div><br><= /div><div>Kind regards,<br>Mathieu</div><div class=3D"gmail_quote"><div dir= =3D"auto" class=3D"gmail_attr">On Thursday, July 30, 2026 at 4:42:55=E2=80= =AFPM UTC Martin Eden wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex"> <br>On 2026-07-30 18:05, mathieu stumpf-guntz wrote: <br>> Not sure what you mean here, but in my previous examples I didn=E2= =80=99t mean=20 <br>> I used any magic sequence, the "\n" was actually literal= new lines. So=20 <br>> to make it clear, the test conducted was more like `echo -e=20 <br>> '[[\ntest\n]]' | lua`,=C2=A0 which ends up (in all configu= rations I was=20 <br>> able to try) with <br>> lua: stdin:3: unexpected symbol near '[[test <br>> ]]' <br> <br>Well that's a different thing! It gives same error for me too. <br> <br>So as <br> <br> =C2=A0 $ echo -e '123' | lua <br> =C2=A0 lua: stdin:1: unexpected symbol near '123' <br> <br>What result you expect? <br> <br>"lua" program in interactive mode silently places expressions <br>inside "print()". That's neat feature to use it as calcul= ator. <br> <br>But neither "[[\ntest\n]]" nor "123" is valid Lua c= ode: <br>they are expressions, not statements. <br> <br>-- Martin <br> <br> <br></blockquote></div> <p></p> -- <br> You received this message because you are subscribed to the Google Groups &= quot;lua-l" group.<br> To unsubscribe from this group and stop receiving emails from it, send an e= mail to <a href=3D"mailto:[email protected]" target=3D"_bl= ank" rel=3D"noreferrer">[email protected]</a>.<br> To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= lua-l/72c88ccc-765c-4d7f-9b19-cf6d5b4a509fn%40googlegroups.com?utm_medium= =3Demail&utm_source=3Dfooter" target=3D"_blank" rel=3D"noreferrer">http= s://groups.google.com/d/msgid/lua-l/72c88ccc-765c-4d7f-9b19-cf6d5b4a509fn%4= 0googlegroups.com</a>.<br> </blockquote></div> <p></p> -- <br /> You received this message because you are subscribed to the Google Groups &= quot;lua-l" group.<br /> To unsubscribe from this group and stop receiving emails from it, send an e= mail to <a href=3D"mailto:[email protected]">lua-l+unsubsc= [email protected]</a>.<br /> To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= lua-l/CAOmpovrwrYuLpHvuPi8Sjv-DWaQF1PaibNGh%3DczgCKUZx%3DYEpQ%40mail.gmail.= com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg= id/lua-l/CAOmpovrwrYuLpHvuPi8Sjv-DWaQF1PaibNGh%3DczgCKUZx%3DYEpQ%40mail.gma= il.com</a>.<br /> --00000000000072fba20657e2e715--