Anonymous user
Talk:Brace expansion: Difference between revisions
→Task is ready for accepting solutions!
m (→Task is ready for accepting solutions!: botched the sig) |
|||
Line 8:
:: Regarding the python code: the commas not in bracers can be parsed as literal chars, but the unmatched bracers as specified by task is not workable. How do you parse "{a,{b,c}" ? As "{a", "b", "c", or as "a", "{b", "c"? Same for closing bracers. This is not just a problem with descending parsers, it's simply ambiguous and counterintuitive, so best treated as a syntax error IMO. The part of spec about "{a}" parsed literally is also not done in python, which can take some workaround but is again not intuitive. --[[User:Ledrug|Ledrug]] ([[User talk:Ledrug|talk]]) 02:37, 26 January 2014 (UTC)
:::I understand that Python culture tends more toward throwing an exception if in doubt, but I think the intent of the task was to emulate the shell's notion of how to do this, hence the failsoft aspects, which are pretty easy to do with a decent backtracking engine. It's certainly straighforward in the Perl 6 solution, once I figured out the top level parses with slightly different rules than sublevels do. And it was certainly specced how it was supposed to treat weird characters. --[[User:TimToady|TimToady]] ([[User talk:TimToady|talk]]) 02:49, 26 January 2014 (UTC)
:::: Well, I'm not really with the python culture, but that's not important. I can see why the spec is setup this way, but the fact remains that the rule about unmatched bracers is underdefined. The spec should say which bracers would be considered extra for consistency across implementations. I'll withdraw the python code for now since it does fail to follow other rules, while the task hopefully can get some clarification. --[[User:Ledrug|Ledrug]] ([[User talk:Ledrug|talk]]) 03:19, 26 January 2014 (UTC)
| |||