Not actually a superset, marketing promise setup major disapointment

[alerque]

The first I heard about Pluto was promotional material suggesting it was a superset and all existing Lua 5.4 code could be run in it. This is reflected in the docs and even the readme:

The only Lua dialect that's proven it can be dropped into massive communities (100K> users), and not break any existing scripts.

This is just not true. I set out to test the speed claims my running my existing projects and am not able to run most of them due to the extra reserved keywords that are allowed in PUC Lua variants.

You can do whatever you decided to do with the language itself, but please stop touting it as being a superset and run existing code when it really is not and cannot.

I'm still interested in playing with it, but not being properly told up front that I would need to refactor existing code depending on simple things like choice of variable names to run under Pluto was a major turn off.

It would be good to clarify this in the README and other docs where the claim is made, perhaps linking to a list of things that (may) need to be changed to run existing Lua code (which I still haven't found a complete list of, I'm just changing them as I hit errors).

[well-in-that-case]

We don't issue promotional material or advertisements whatsoever, anything you see is from other users sharing it. Nevertheless, this is exactly what we talk about in our compatibility documentation: https://pluto-lang.org/docs/Compatibility

I cannot help but feel that you have completely overlooked our documentation before essentially grilling us.

This is just not true.

Stand migrated to Pluto with compatibility mode enabled, where it broke no existing scripts. This is why compatibility mode exists, for integrators who need to ensure existing Lua codebases will run perfectly fine. You can leverage usage of pluto_use for extremely robust configuration of where and when compatibility mode applies, pre-select versions of Pluto, and so on. Please, read the documentation.

[Sainan]

The way we handle standalone scripts (outside of an environment where an integrator can enable compatibility mode for the entire ecosystem) is that all keywords are enabled by default, because we want all the features to be there by default. You can easily disable non-compatible keywords as documented:

pluto_use * = false

We do recognise that this breaks your ability to run the scripts with Lua, so in 0.9.0 we're also adding another way to configure this:

-- @pluto_use * = false

[alerque]

This helps some. An asterisk in the readme suggesting this mode needs to be enabled for the claims to be true would help. And yes, it looks like I'll have to wait for v0.9 to even give it a decent shake.

Can I suggest a CLI flag to enable this as well? Right way just playing with v0.8 I notice this mode needs to be set on every file and module loaded which is a huge imposition on trying to give it a test run. I can't even just set it in the entry point file to give things a try.

[alerque]

The wording I quoted is from your readme.

The docs site also puts both these claims front and center with no hint of a "compatibility mode" one should search for and enabling if those two headline features are desired.

[well-in-that-case]