Re: Inconsistent Multiline String Handling in Lua REPL (Direct Input vs. History Recall)
mathieu stumpf-guntz <[email protected]> Thu, 30 Jul 2026 21:46:51 -0700 (PDT)
| Newsgroups | gmane.comp.lang.lua.general |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_109364_1132011384.1785473211590 Content-Type: multipart/alternative; boundary="----=_Part_109365_516347788.1785473211590" ------=_Part_109365_516347788.1785473211590 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Martin and Roberto, Thank you very much for all of your insights, that=E2=80=99s very enlighten= ing,=20 though I=E2=80=99ll have to meditate and play a bit more around with it bef= ore=20 integrating the full lesson here I guess. To respond your question Martin, maybe in a broader fashion than the way=20 you where initially conducting it, what I would expect is a bit less=20 surprise in behaviour while interacting with the interpreter. Though I can= =20 get the point that, this or that surprising behavior can be the expected=20 result according to the grammar and the documentation. Even sitting firmly= =20 in that scope, having a consistent behavior for the same input whatever the= =20 input method seems to dwell on an other level of expectation. Consider the= =20 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= =20 of an ill formed construction, fair enough. - Through history facility I select again this ill formed construction and= =20 launch interpretation which eventually returns true and prints accordingly. - Then I copy/pasted the whole code snippet in the interpreter, and was=20 informed this time that this is false, the matching value representation=20 being printed. - Then picking this very last entry in history and running it, I still get= =20 false printed. - Finally, picking instead in history the earliest item available, we are= =20 back to true being printed. Just reading the session transcript, one could certainly spot what=E2=80=99= s=20 happening in the directly typed entry thanks the extra `>` hint. But=20 without the previous explanations, one would certainly have a hard time=20 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= =20 behavior in the REPL.=20 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=20 > > I used any magic sequence, the "\n" was actually literal new lines. So= =20 > > to make it clear, the test conducted was more like `echo -e=20 > > '[[\ntest\n]]' | lua`, which ends up (in all configurations I was=20 > > 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 > > > --=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/72c88= ccc-765c-4d7f-9b19-cf6d5b4a509fn%40googlegroups.com. ------=_Part_109365_516347788.1785473211590 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div>Hello Martin and Roberto,</div><div><br /></div><div>Thank you very mu= ch for all 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 integra= ting the full lesson here I guess.</div><div><br /></div><div>To respond yo= ur question Martin, maybe in a broader fashion than the way you where initi= ally conducting it, what I would expect is a bit less surprise in behaviour= while interacting with the interpreter. Though I can get the point that, t= his or that surprising behavior can be the expected result according to the= grammar and 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"font-family: "JetBrains Mono", monospace;">Lua= 5.3.6 Copyright (C) 1994-2020 Lua.org, PUC-Rio<br />> [[<br />>>= test<br />>> ]] =3D=3D "test\n"<br />stdin:3: unexpected symbol near= '[[test<br />]]'<br />> [[</span></div><div style=3D"background-color: = rgb(30, 31, 34); color: rgb(188, 190, 196);"><span style=3D"font-family: &q= uot;JetBrains Mono", monospace;">test</span></div><div style=3D"backgr= ound-color: rgb(30, 31, 34); color: rgb(188, 190, 196);"><span style=3D"fon= t-family: "JetBrains Mono", monospace;">]] =3D=3D "test\n"<br />t= rue<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;">test</span></div><div style=3D"background-color: rg= b(30, 31, 34); color: rgb(188, 190, 196);"><span style=3D"font-family: &quo= t;JetBrains 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", m= onospace;">test</span></div><div style=3D"background-color: rgb(30, 31, 34)= ; color: rgb(188, 190, 196);"><span style=3D"font-family: "JetBrains M= ono", monospace;">]] =3D=3D "test\n"<br />false<br />> [[</span></d= iv><div style=3D"background-color: rgb(30, 31, 34); color: rgb(188, 190, 19= 6);"><span style=3D"font-family: "JetBrains Mono", monospace;">te= st</span></div><div style=3D"background-color: rgb(30, 31, 34); color: rgb(= 188, 190, 196);"><span style=3D"font-family: "JetBrains Mono", mo= nospace;">]] =3D=3D "test\n"<br />true</span></div><br />So what happen her= e:</div><div>- I typed manually the boolean test and got printed an error i= nforming=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/pa= sted the whole code snippet in the interpreter, and was informed this time = that this is false, the matching value representation being printed.</div><= div>- Then picking this very last entry in history and running it, I still = get false printed.</div><div>- Finally, picking instead in history the earl= iest item available, we are back to true being printed.</div><div><br /></d= iv><div></div><div>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 ha= ve a hard time inferring what has actually been done in the subsequent inte= ractions.</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" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 2= 04); padding-left: 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]">lua-l+unsubsc= [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">https://groups.google.com/d/msgid/lua-l/72c88= ccc-765c-4d7f-9b19-cf6d5b4a509fn%40googlegroups.com</a>.<br /> ------=_Part_109365_516347788.1785473211590-- ------=_Part_109364_1132011384.1785473211590--