Talk:Tokenize a string with escaping: Difference between revisions
No edit summary |
|||
Line 11: | Line 11: | ||
: If you are not replacing the solution, please do not remove it. It's ok to document issues, but if it's really that much of a problem to come up with a better solution, an existing solution which meets the task requirements should almost always be considered adequate. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 02:40, 12 January 2017 (UTC) |
: If you are not replacing the solution, please do not remove it. It's ok to document issues, but if it's really that much of a problem to come up with a better solution, an existing solution which meets the task requirements should almost always be considered adequate. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 02:40, 12 January 2017 (UTC) |
||
: I have itemized solutions and added conduit-based solution. However, I don't see the reason to leave the inefficient and non-idiomatic variant. --[[User:Samsergey|Samsergey]] ([[User talk:Samsergey|talk]]) 03:39, 12 January 2017 (UTC) |
Revision as of 03:41, 12 January 2017
The alternative Haskell solution needs attention
Unfortunately, the alternative Haskell solution, given by @Hout doesn't show the strength of Haskell. The alternative solution is very inefficient in case of big lists, due to a pattern list ++ [element]
. It ruins the effect of foldl
or foldl'
.
It is possible to make this solution better by using difference lists with O(1) snoc
operator, but then it would require toList . map toList
instead of reverse . map reverse
as postprocessing. Another workaround would be to replace ++
by :
and perform reversion, but in this case the alternative solution will become just a paraphrase of a DFT solution with less modular logic.
After all, it is a sort of parsing problem, so the most natural solution would use some parsing technique (DFT, for example). I would be happy to see an alternative solution using any of parsing libraries, or conduits/pipes so that it could handle real-world text-based cases and demonstrate everyday practice.
I recommend to remove the solution.
- If you are not replacing the solution, please do not remove it. It's ok to document issues, but if it's really that much of a problem to come up with a better solution, an existing solution which meets the task requirements should almost always be considered adequate. --Rdm (talk) 02:40, 12 January 2017 (UTC)