Anonymous user
Talk:Brace expansion: Difference between revisions
→Task is ready for accepting solutions!: edited task
(→Task is ready for accepting solutions!: shells tend to be failsoft on this) |
(→Task is ready for accepting solutions!: edited task) |
||
Line 4:
--[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 17:49, 25 January 2014 (UTC)
:There appears to be a bug in the task. Your third test case should have backslashes on the comma by the "always leave in the backslash" rule. See the Perl 6 output. --[[User:TimToady|TimToady]] ([[User talk:TimToady|talk]]) 02:02, 26 January 2014 (UTC)
::I edited the task to add the backslashes, after verifying that the Perl code actually does include the backslashes before comma. --02:52, 26 January 2014 (UTC)
:Also, with the toy output, it's not at all clear that the current Perl or Python implementations are doing this according to spec. The Perl code claims to follow the spec, but the spec is missing backslashes on the commas. The Python code talks about barfing on code that the specification says it should accept. Maybe we should require a bit more rigor in proving solutions actually pass the spec for backslashed and not-really-meta characters. --[[User:TimToady|TimToady]] ([[User talk:TimToady|talk]]) 02:22, 26 January 2014 (UTC)
:: 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)
| |||