pdluax could have its own binary so we don't need to call the library

[porres]

loading plua as a library at startup or with [declare] is need so Pd knows it has to look for lua files and call them as objects. Although Pd will know to look for lua externals if you use the [pdlua] object, this is important because the order matters and [pdlua] always needs to be created first (best to rely on [declare] which guarantees this).

The [pdluax] version also needs plua loaded as a library but in this case the code is called inside the object as an argument. In this case you don't really need anything to be previously loaded via startup or declare, since the object itself, when created, looks for the lua code.

Nonetheless, we need the library because we do not have a [pdluax] binary that Pd looks for.

I think things would be simpler to manage if we could provide a binary for [pdluax].

[agraef]

Both pdlua and pdluax are classes which are entirely implemented in Lua code (cf. pd.lua:330 ff). There's literally no C code there which could be spun off into its own C/binary object.

Besides, as I see it, pdluax is really of minor importance. It has its uses, so I left it in for backward compatibility. But there are much better ways to do live-coding described in the tutorial (dofile, pdx).

[agraef]

Ok, I'm closing this now because AFAICT there's simply no sensible way to implement your proposal. Feel free to reopen it if I have misunderstood your suggestion, or if you'd like to keep discussing it.