Re: Making Lua unique through supporting natural language texts as valid script code

[Javier Guerra Giraldez <javier@...>]

On Mon, 2 Oct 2023 at 09:30, Claudio Grondi <claudio.grondi@freenet.de> wrote:
> What I was asking was where to look at source code of Lua to patch it in order to make possible what I have asked for. What I have got up to now is a list of reasons why what I want to achieve shouldn't be done or why it would not work.


I don't want to comment on your ideas, project, or methodology.  I do
encourage you to pursue them as long as you find them compelling.

What I want to propose is to experiment with your ideas, not as
"patches to the Lua code", but as a code transformation tool.
sometimes called a "transpiler" (although i don't like that word).
I'm sure you'll find it much more straightforward and fruitful.

As a comment, i think that perhaps the negativity you've found comes
from two misconceptions:

1. when you said (in the original subject line) "Making Lua
unique...." It sounds like a proposal for changes to be made to the
main Lua project.  Which is not bad in itself, but it would require at
least not to create much problems for other users of Lua.

Specifically, backwards compatibility is a **big** issue.  That means
that any existing code must still work after the proposed changes.
For example, in current Lua code, "a-b" definitely means "variable a
minus variable b", and changing that to a variable name would break a
huge amount of existing code.

If one instead takes your initial email as asking for help to create a
new system, heavily based in Lua, then none of these problems apply
anymore, since what you're building is not Lua, but something else,
for different uses.


2.  Much of your explanations deviate heavily from what is "common
usage" in programming language design and implementations.

And that's OK!

But you have to realise that although the Lua implementation code is
small when compared to other languages, it's still far from trivial;
and its design relies heavily on the existing programming language
design theory.

Your changes, which look "small" when described via examples of
acceptable code, would require major design changes in the parsing
code.  One big issue that was mentioned early was about introducing
inconsistencies.  While you dismissed them based on other (semantic, i
think?) considerations, they remain a large problem in language design
theory.



Thus, I think your project would be far better served not by trying to
modify Lua code, but by creating a separate project, which would
transform input in your proposed language into some other, more
"classical" language that could be parsed and executed by existing
systems, be it Lua or any other language you find appropriate.


Wish you the best of luck, and please don't hesitate to announce here
if you choose to create such a system on top of Lua.



--
Javier