(I'm pretty sure that this won't get a reply, but I'll leave the final post for others.)
> So a deficiency in your code, you chose to blame the language.
The language is to blame if it encourages a deficiency. I've linked to the type checker code to show that this kind of bug is virtually invisible, not like the aforementioned `if (a = b)` case, even to who knew enough to write a type checker.
> So Lua offers two superior ways to process strings over one? and you're still mad?
Lua doesn't offer two superior ways, it's lpeg that offers. And what lpeg offers (first-class PEG) is irrelevant to my problem (Lua the language lets you to accidentally put unintended arguments) anyway.
> Ierusalimchy wrote lpeg specifically to address known deficiencies in the pattern library.
And yet he left the faulty version in the standard library.
> Sure, you can't always use it. Just like you might be stuck on an obsolete version of JS in an embedded system.
You don't need the embedded system to show that you can't always use the JS package system. Web browsers some years ago didn't support that. As a result webpack (among others) happened and we are now comfortable to compile JS down to the bundle. Does Lua have any equivalent?
When I raise the issue with Lua the language you point to Lua the ecosystem and sideskip the fact that Lua the ecosystem itself is fragmented thanks to Lua the implementation. My issue with Lua (either the language, the implementation and the ecosystem) is multitude and pretty much every issue is connected to each other.
> It is, in fact, not.
Your code is different to the following (which is what I consider more readable):
-- [end_str_P and _disp omitted]
-- returns 0 for [[, 1 for [=[, 2 for [==[, and so on
local end_str_len_P = (L.Cp() * end_str_P * L.Cp()) / _disp
local find_str = L.Ct(((-end_str_P * 1)^0 * end_str_len_P)^1)
Your code unintentionally groupped `(-end_str_P * 1)^0 * (L.Cp() * end_str_P * L.Cp())`, as `a * b / c` would be `(a * b) / c` instead of `a * (b / c)`. It is not "incorrect" as the former doesn't contain any capture, but has enough potential to become incorrect. That's what I want to avoid by not using a "quirky EDSL".
> So a deficiency in your code, you chose to blame the language.
The language is to blame if it encourages a deficiency. I've linked to the type checker code to show that this kind of bug is virtually invisible, not like the aforementioned `if (a = b)` case, even to who knew enough to write a type checker.
> So Lua offers two superior ways to process strings over one? and you're still mad?
Lua doesn't offer two superior ways, it's lpeg that offers. And what lpeg offers (first-class PEG) is irrelevant to my problem (Lua the language lets you to accidentally put unintended arguments) anyway.
> Ierusalimchy wrote lpeg specifically to address known deficiencies in the pattern library.
And yet he left the faulty version in the standard library.
> Sure, you can't always use it. Just like you might be stuck on an obsolete version of JS in an embedded system.
You don't need the embedded system to show that you can't always use the JS package system. Web browsers some years ago didn't support that. As a result webpack (among others) happened and we are now comfortable to compile JS down to the bundle. Does Lua have any equivalent?
When I raise the issue with Lua the language you point to Lua the ecosystem and sideskip the fact that Lua the ecosystem itself is fragmented thanks to Lua the implementation. My issue with Lua (either the language, the implementation and the ecosystem) is multitude and pretty much every issue is connected to each other.
> It is, in fact, not.
Your code is different to the following (which is what I consider more readable):
Your code unintentionally groupped `(-end_str_P * 1)^0 * (L.Cp() * end_str_P * L.Cp())`, as `a * b / c` would be `(a * b) / c` instead of `a * (b / c)`. It is not "incorrect" as the former doesn't contain any capture, but has enough potential to become incorrect. That's what I want to avoid by not using a "quirky EDSL".