I mentioned it briefly in IRC and I'll say it again here. This has all kinds of wonderful and fantastic uses. It would be a great addition... for people who know LUA. The uptake on FREDing is already low... to expect a bunch of people to learn a code language to create the kind of missions that the "greats" are would be making is crazy. I've already seen people say they won't learn SEXPs because they don't think they can pull off what is done in BP, JAD or even ST:R. And SEXPs are eeeaaaaaaaasy.
Granted, I know I'm posting this on a coding specific board.. so all you coders are like, 'yeah, but so is LUA!' You are probably right. But probably not as easy as SEXPs to approach. I guess I'm saying that to dump SEXPs entirely in favor of LUA from some point on... is a quick an easy way to cut down on the number of people making missions... Missions, by the way, are what we want more of.
(This is going off the impression from the conversation that if this ever happened, people probably wouldn't make new SEXPs anymore.)
Okay so, it is all theoretical at this point but us tackle these concerns.
All pre-lua sexps should still available in the events editor as before, which sexp to lua parser interprets and handles over to lua subsystem to keep backwards compatibility with old missions.
There could be two ways to add new sexps. In one you can add new sexps within fred, which opens a text editor that has built-in lua syntax to help you. That is then saved into the mission file.
Second is a table (tbl or tbm), let us use sexps.tbl for convenience. Both fred and fs builds would bundle a default sexps.tbl, which can be either overridden or added to with a tbm. The sexps.tbl would most likely contain all pre-lua sexps necessary for backwards compatibility with existing missions, so that they won't break. And any new post-lua sexps would be added to a tbm instead, locking the sexps.tbl for anything but bug fixes. By having old sexps parsed through sexps.tbl into lua has the advantage that even non-coders can try and fix bugs in the parser, should there be any. Or people like Axem can wreak havoc on people by changing how even old sexps behave in JAD, without having to resort to custom builds.
As for new sexps, we could use tbm's for those like mysexp-sxp.tbm which would be easily distributable. We could also build a library of those into FSWiki and possibly even build library access right into fred itself. Just look at popular internet browsers with built-in library access for their addons. So with that, we have two possibilities to add new sexps. Either tables or directly written into the mission file. The first option can be shared and distributed easily, the second gives fredder easy platform to handle sexps unique to one mission. And a lua library would provide easy access to works of the community.
What this means is that writing new sexps is a lot easier than it has been so far. You would no longer need a coder to do it and you wouldn't need to compile new builds for it. Sharing and distribution of new sexps does not need to be difficult either, we can have a library just for that which fred could access within the application.
That said. The work involved in overhauling lua scripting to a point where it can replace sexps is daunting. But this community has tackled big projects before, so it can be done.
Edit: It just occurred to me that if lua is given access to pretty much anywhere, then it is probably necessary to move tbl/tbm parsing over to tbl to lua interpreter and handled entirely in lua. This does have the added benefit that you don't necessarily need to roll out new builds to add support for new tabling features. Not only that but giving control over tables to lua also gives astounding possibilities. For example, the question T-Rog asked in the irc chat log that began this whole discussion could be done in lua version of weapons.tbl or tbm just to give one example.
