Time Nick Message 11:18 MTDiscord kilbith: That's a rather poor hack 11:19 sfan5 having a preprocessor is the only choice, I think it's neat 11:19 MTDiscord 1. It will be applied to comments 11:20 MTDiscord sfan5: Yes, but it's a poor pattern-based preprocessor 11:20 MTDiscord It will be very, very error prone 11:20 MTDiscord What about precedency, for instance 11:21 sfan5 a proper implementation should use an AST 11:22 MTDiscord Yes 11:27 MTDiscord @kilbith: You can't get your Lua tooling to ignore syntax errors 11:28 MTDiscord This preprocessor is it's only language and effectively not Lua anymore 11:28 MTDiscord You could try linting the generated Lua 11:28 MTDiscord it's own* 11:29 sfan5 its own* 11:34 MTDiscord kilbith: you should split the input only once 11:34 MTDiscord currently it has worst case quadratic complexity 11:37 MTDiscord the expression pattern, "[%w%.%[%]"'_]+", looks very broken to me (arguably Lua expressions can't be matched using Lua patterns) 11:37 MTDiscord It won't be able to match bracketed expressions 11:38 MTDiscord It will incorrectly match expressions that use bracketed expressions, such as (a).b++ -> .b = .b + 1 11:39 MTDiscord it also assumes lines as statement delimiters 13:56 kilbith Luatic: I am aware of the limits of the implementation, it wasn't made to handle everything but since it's for my own use and I know what not to do, IMO it's the best thing you can get for a quick hacking around operators 13:58 kilbith Luacheck is my biggest problem though, I can't get it ignoring syntax errors with the inline `-- luacheck: ignore` above code, it only ignores warnings 14:47 erlehmann kilbith why would you even want luacheck to ignore stuff that is obviously not legal lua? 14:48 sfan5 consider reading the backlog 14:48 kilbith because it's /controlled/ errors 14:48 erlehmann sfan5 i did read it, kilbith is writing spaghetti code. i just don't get why it is important to get the linter to not complain. 14:48 erlehmann if you extend the grammar that way, why care about the linter 14:49 kilbith in which way it's spaghetti? 14:49 erlehmann grammars for several languages in one line 14:49 kilbith coming from a MCL author, it's a compliment :] 14:50 erlehmann kilbith i hate the convoluted mcl stuff as much as you hate it, probably more even 14:51 erlehmann kilbith i see that your thing seems useful, but wouldn't it be a good thing to use the linter at a later stage, when the preprocessing is done? 14:52 kilbith how can you tell Luacheck not analysing the static files? 14:53 kilbith btw Luatic: https://github.com/minetest-mods/i3/blob/main/tests/test_operators.lua#L26 (RE: "won't be able to match bracketed expressions") 14:56 erlehmann kilbith, i am sorry, i do not know that. 14:59 erlehmann kilbith, i think i would have set it up differently, so that i actually had static lua files coming out of the preprocessor. you seem to do it at runtime. 15:00 erlehmann i see the advantage of having no intermediate output, i.e. no explicit compile step. but i doubt luacheck will work with it unless you coax it to *also* check the stuff at runtime. 15:00 erlehmann which would be at least a bit weird 15:00 kilbith Luacheck only checks static data 15:02 erlehmann then i see no way around making the intermediate explicit 15:02 erlehmann .lua is the wrong ending for stuff that is lua plus whatever you came up with anyway 15:04 kilbith well yes I guess you raise a good point, it should have a different extension 15:08 erlehmann otherwise i agree with luatic and sfan5 btw, that thing should use a proper parser 15:08 erlehmann i doubt you'll want that, no one ever wants that 15:08 kilbith so that I can implement !foo without breaking the syntax coloring in the text editor 15:08 erlehmann oh good point 15:08 kilbith (about custom extension) 15:09 erlehmann is the ultimate purpose of this thing to a) make it more readable b) make it easier for you to work with c) achieve theoretical purity? 15:10 kilbith a&b 15:21 MTDiscord kilbith: I should have been more specific. The expression itself can be enclosed within brackets, but the operands may not use brackets / other operands / subexpressions. 15:21 MTDiscord "(1 & 1) | 1" for instance is impossible 15:23 erlehmann you come with a regular expression knife to a fight where the other person is wielding something more complex than a deterministic pushdown automaton 15:24 MTDiscord Huh? 15:24 MTDiscord Lua's grammar is context-free 15:24 MTDiscord Patterns aren't regular expressions, they're even less expressive 15:25 MTDiscord RegExes would be enough for Lua tokenization (excluding long strings), which would be enough to substitute operators as long as you don't care about precedency