Compound assignments as an exercise - hints welcome

[Родион Горковенко]

Hi Friends!

Sorry if it sounds silly, but I tried to make a minimal "patch" to Lua source-code to implement compound assignments on a parser level. It was caused by some thread I've seen in this maillist earlier - I guess it stated the issue is with how parsing is implemented in strict "single-pass" and moreover I found parser generates opcodes as soon as it can.

Here is the repo with the result of this "exercise" and I would be glad if you can spare 10-15 minutes to test or review it and tell whether some stupid flaw remained unnoticed.

https://github.com/RodionGork/lua-plus/ - the change itself is in the latest commit which you can view separately.

(I don't expect such "amends" to be welcome by the language development team, so rather regard it as a proof-of-concept and exercise)

Main motivation was to get a bit acquainted with the source code. Another one - as I offered Lua to users of my website, to solve coding puzzles in it - and I get some feedback, noticing that people with some experience in other languages are mostly unhappy with 3 minor features of the language - lack of compound assignments, non-equals operator differing from C/Python style and 1-based arrays. In other words these really small things have significant impact in, so to say, language marketing.

Thus I grew curious whether it is possible to amend the first two with some very small change, retaining compatibility (i.e. to add but not replace anything). With "not-equals" it seems easy, just like adding 2-3 lines (I guess there could be minor drawbacks as it is not a separate operator but just another "spelling" of the same).

With compound assignment it was more difficult. There is a branch with the "failed first attempt" which tried to avoid "small rewind" of token stream (it works only for simple variables).

Thus I ended up with adding small storage for tokens from the start of the statement till the assignment operator (e.g. those consumed with "suffixedexp(...)" call). Obvious drawback is that parser becomes not "exactly single-pass" as it makes short "lookbacks" when compound assignment is met.

Another is that I decided not to introduce the heap of separate operators - thus actually they are two still, and could be separate with space (e.g. "a + = b" will work). And then it is just "expanded" to normal assignment (e.g. "a = a + b") on the parser level - so it may behave differently when L-value is suffixed with some expression having side-effect.

But I guess it is a reasonable tradeoff to keep the "amend" small - it shows now 110 lines, of them 45 in "readme".

So to conclude, if you can enlighten me on whether there are more serious problems with such approach - that would be great. I'm thinking of making similar patch for LuaJIT and perhaps propose its optional using some projects which, like mine, are exposing Lua to wider audience and may receive similar "votes of discontent" from programmers with experience in other languages (I myself am far from thinking that the said language features are really prohibitive).

sincerely yours,

Rodion

[Xmilia Hermit]

> Another is that I decided not to introduce the heap of separate
> operators - thus actually they are two still, and could be separate with
> space (e.g. "a + = b" will work). And then it is just "expanded" to
> normal assignment (e.g. "a = a + b") on the parser level - so it may
> behave differently when L-value is suffixed with some expression having
> side-effect.

A problem with this approach shows in.

local a=3
local b=2
a*=b+1
print(a)

This will print 7. However, I would expect to see a 9 since 3*(2+1) ==
9, but a*=b+1 is parsed as a=a*b+1 which will group like a=(a*b)+1
instead of the expected a=a*(b+1).

Regards,
Xmilia

[Родион Горковенко]

Wow, thanks for such a speedy reaction and clever insight!

Should be fixed now, thanks for your hint and example :)

--
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 visit https://groups.google.com/d/msgid/lua-l/41d3416a-3c5d-47ea-accd-5dc0fccb7726%40gmail.com.

[Sainan]

Lua-plus reminds me a lot of Pluto when it first started. Since we had maintained a separate fork of Lua just for compound operators, we just switched to Pluto. Looking at it now like a few years later, it's a lot more than just Lua with compound operators, haha. I wonder what direction Lua-plus will go.

-- Sainan

[bil til]

Am Fr., 29. Aug. 2025 um 19:01 Uhr schrieb Родион Горковенко
<rodio...@gmail.com>:

>

>Main motivation was to get a bit acquainted with the source code.

... but this sonds like a quite challeging "acquanting startup" :).

... better try to do some really useful meta-"classes" for your users,
or then in advanced level some more challenging multi-tasking
(yielding) apporaches... .

... if you say, that your users do not like "code compatibility" with
Python/C, you should better also describe a bit the "nature of your
users" - what sort of programming are the mostly interested in? You
have to see that a VERY main advantage of Lua is, that it does
CIRCUMVENT the tricky coding of C, and that it can be used also by
more "simple thinking" people quite easily. e. g "more simple
electricdians" or programming starters.

Main things are, that it e. g. avoids the CRAZY C operators like &&,
|| or and and or, which are extremely difficult fo coding beginners,
also their difference to & and | in the "bit wolrd". Also of course
that you easily implement script programming features in any larger
software with minimum code print, and that you can easily implement
sandboxing applications - this all does NOT work with C (I do not know
python in detail, but i think also not wiht Python).

Such "abbreviation things" like += are somehow nice for "lazy tipping
code experts", but the are not really important, and if you really
want them, you could just implement some function "addto(...)" or
similar. You have to see further mainly, that the "=" operator in Lua
is MUCH more powerful than in C (also Python I assume), as it allows
assignment of mutliple arguments in one operation... .

[bil til]

Am Sa., 30. Aug. 2025 um 02:33 Uhr schrieb 'Sainan' via lua-l
<lu...@googlegroups.com>:

>Main motivation was to get a bit acquainted with the source code.

[bil til]

Am Fr., 29. Aug. 2025 um 19:01 Uhr schrieb Родион Горковенко
<rodio...@gmail.com>:
>

> Hi Friends!
>
> Sorry if it sounds silly, but I tried to make a minimal "patch" to Lua source-code to implement compound assignments on a parser level.

>... Main motivation was to get a bit acquainted with the source code. ...

... are your starting with Lua and really try "Lua coding
modifications" as "training field"?... this sounds a bit VERY
challenging start :).

[Родион Горковенко]

Sainan, Hi!

Thanks for reminding of Pluto :)

> I wonder what direction Lua-plus will go.

I didn't mean it to "go" anywhere too far :) Probably I'll try using it in my education project (if no critical issues with the approach are found).

Also looked into LuaJIT source code - it seems to resemble the original in that part of parsing - so I wonder if the same trick could be done

there, could it be utilized in Tarantool for example. 

On Sat, Aug 30, 2025 at 3:33 AM 'Sainan' via lua-l <lu...@googlegroups.com> wrote:

Lua-plus reminds me a lot of Pluto when it first started. Since we had maintained a separate fork of Lua just for compound operators, we just switched to Pluto. Looking at it now like a few years later, it's a lot more than just Lua with compound operators, haha. I wonder what direction Lua-plus will go.

-- Sainan

--
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 visit https://groups.google.com/d/msgid/lua-l/EXABhVYNeZc_TXgkHrLey-jKto4rxgB0lVsoV984w_QhwIFGmIoNjuGcrHAnOQsK7vlV7BFFhB_2NwebyBIdyuTr7c3NqdPblMFYrc8Mg9A%3D%40calamity.inc.

[Родион Горковенко]

Hi and thanks for the feedback!

Though it is not about the code, definitely, your questions are good to consider!

> you should better also describe a bit the "nature of your users" - what sort of programming are the mostly interested in?

I run the small website with programming puzzles. Most of them could be solved in any language, however I made also a class of

exercises where user is to write the code which implements some game algorithm and optionally may run some in-page animation.

To check the result of user's submissions I need to plug in their code into some game-running code on the server and test the result -

thus it is necessary they write in single chosen language. Here is an example:

https://www.codeabbey.com/index/task_view/space-invaders-automation

Another idea (more for future) was to create a kind of programming course based on Lua running with canvas in the web-page,

that is for real beginners (you can find it by clicking "School" in the main menu on the same site). Here I use Lua compiled with

EMCC to work with canvas and mouse in the simple manner (similar to how we did it in times of Qbasic and Pascal).

The first kind of users are people with some experience (often in Python) and while Lua resembles simpler and lighter version

of that language, they are predictably driven crazy fixing their common typos.

For the second kind of users (who are supposed to be very beginners), it is not that important as they should learn the Lua

as their first language. However as I "promote" Lua telling that they may easily found similarities in other languages later,

it is good to have more of such "similarities".

 

> but this sonds like a quite challeging "acquanting startup"

You see, I have a small curiosity about programming languages, how they work etc - but no good skills in this field - thus I suddenly thought of this as

a good opportunity to learn better of how Lua works. Truly at the first glance I was pretty confused :)

> Main things are, that it e. g. avoids the CRAZY C operators like &&,

Honestly this sounds much like personal experience. When I was learning C operators never were a problem

(while other things were).

For me Lua is great for concentrating extreme power and expressiveness in a very laconic implementation. Another

important thing is that it was created as "human-oriented".

> Such "abbreviation things" like += are somehow nice for "lazy tipping code experts", but the are not really important, 

That's quite true! But they are "not really important" for me - while their absence significantly hampers "marketing" the

language, you see. Not that I'm selling it of course, but it is obvious that user's acceptance of the language may

significantly depend on their liking of basic syntax familiarity, for which they are ready to learn then about advanced features.

It is no good to persuade people "yes, syntax is different for no specific reason, but go on, push forward and you'll like it" -

while it may be true, people normally won't like such kind of "vocal motivation" :)

As I said, compound assignment is absent, I guess, not due to some specific ideology, but rather due to the way the parser is

implemented. It allows to avoid allocating some more hundreds of bytes. However as Lua nowadays is used in pretty large

systems, this doesn't look important.

sincerely yours,

Rodion

--
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 visit https://groups.google.com/d/msgid/lua-l/CAOnDXmFEJixNsf8mOUhrR4XtmEDyUYprtExZZWU4_L7sGS5YfQ%40mail.gmail.com.

[bil til]

Am Sa., 30. Aug. 2025 um 08:11 Uhr schrieb Родион Горковенко
<rodio...@gmail.com>:
>

> Hi and thanks for the feedback!
>
> Though it is not about the code, definitely, your questions are good to consider!
>
> > you should better also describe a bit the "nature of your users" - what sort of programming are the mostly interested in?
>
> I run the small website with programming puzzles. Most of them could be solved in any language, however I made also a class of
> exercises where user is to write the code which implements some game algorithm and optionally may run some in-page animation.

... this reminds me a bit of "codewars" internet page. Codewars also
presents programming puzzles in various languages (including Lua, C,
Python) - this maybe is a bit similar. In fact this really is VERY
useful to train Lua to my experience... .

[Frank Dana (FeRD)]

On Saturday, August 30, 2025 at 12:53:14 AM UTC-4 bil til wrote:

Main things are, that it e. g. avoids the CRAZY C operators like &&,
|| or and and or, which are extremely difficult fo coding beginners,
also their difference to & and | in the "bit wolrd".

Is that really the case, that beginners generally find boolean operators "extremely difficult"? If so, I'm shocked. Boolean logic is a FUNDAMENTAL concept of programming, and if you can't wrap your head around some version of 'and' and 'or' as operations, it feels like you're not going to be very effective as a coder.

What exactly is "CRAZY" about boolean 'and' or 'or'?

I don't want to make this into a battle of personal anecdotes, but I never got the impression that boolean logic was a stumbling block for beginning programmers. Not just in my personal experience, but among my peers when I was in school. 

Typically, the challenging things for novice C programmers are dealing with character arrays aka "strings" (they're not real strings) — in fact, dealing with memory allocations in generaly — and then working with pointers. Recursion sometimes trips people up, too. 

But, boolean logic? Really?

I agree that having boolean operators (&&, ||) and bitwise operators (&. |) that look so similar is highly unfortunate, which is why C++ added the keyword-form synonyms (and, or) for the boolean operators. I've never understood why C didn't follow suit on that. But, insufficiently-distinct operators in C is hardly unusual. (See also: = vs ==.)

[Sainan]

While I'm not sure what they meant with 'crazy', I can imagine that the 'side effect' of such operators can be confusing, e.g.:

_ = true and print("I will be printed")
_ = false and print("I will not")

-- Sainan

[Frank Dana (FeRD)]

On Sunday, August 31, 2025 at 9:30:01 AM UTC-4 Frank Dana (FeRD) wrote:

I agree that having boolean operators (&&, ||) and bitwise operators (&. |) that look so similar is highly unfortunate, which is why C++ added the keyword-form synonyms (and, or) for the boolean operators. I've never understood why C didn't follow suit on that. 

Oh, in fact, since C95 the iso646.h header includes macros to do exactly that. 

[bil til]

Am So., 31. Aug. 2025 um 15:30 Uhr schrieb Frank Dana (FeRD)
<fer...@gmail.com>:

>
> Is that really the case, that beginners generally find boolean operators "extremely difficult"?

not boolean.

But &&, || and their mixup possibility to & and | in C... .

C was a programming language made by experts with extreme view to
"coding efficiency". It therefore IS nice for experts, but it has many
pitfalls for beginners... . Beginning in Programming, or programming
"sometimes from time to time" is much nicer in basic or Lua... .