2017-10-09 22:18 GMT-03:00 Vinnie Falco via Boost <boost@lists.boost.org>:
I'll try to provide more clarity. `beast::basic_parser` is designed with standardization in mind, as I intent to eventually propose Beast for the standard library.
A standard library is a library where we cannot have the luxury to make mistakes. If you make a mistake, the API will carry the technical debt forever. I have made the interface as [...]
[...] tradeoffs are made. [...] [...] One can only measure the relative success of designs based on the feedback from users. They opened issues [...]
So... it solves the problem for N users... therefore it'll solve the problem for N + Z users too? Do you see how this looks like to me? If I take the guess that the problem is the inductive reasoning that I criticized all along in the previous tutorial I've linked, would you think that this would be a wild guess or a reasonable guess? Can you understand why I see the situation as such? However, I'll pretend that I've chosen the optimistic vision this time. I'll pretend that you've started to grasp the critics and you're here explaining how you've developed Boost.Beast parser (i.e. the approach used to tackle development) to justify your design. For a moment, let's ignore the “justify the design” and focus on the approach to the development (because the way you presented is not a discussion of design). What you're doing is applying a heuristic. I do know and use this heuristic (directly and indirectly). But there are two points that I want to add here. The first point is: do not be a slave to a single one heuristic. I also mentioned one heuristic in the tutorial I've linked previously, the Occam’s razor https://vinipsmaker.github.io/asiohttpserver/#_footnote_8 When you say “we need to be careful interpreting results”... how does someone who lacks the tools in the cognitive repertory will interpret these results? Can you describe/use me your other tools? I'm not the one who will praise you if you answer quickly. Take your time (people rarely listen to this advice). The second point is: here, you need to go *beyond* the heuristics. This is a point that depends entirely on you. I cannot explain you how you go beyond the heuristics. You've just got to do it. I'll try a new approach here. Given some of the ideas weren't well received by you, I took the liberty to convert the Tufão project that you've mentioned to use the Boost.Beast parser: https://github.com/vinipsmaker/tufao/commit/56e27d3b77d617ad1b4aea377f993592... Would you say you like the new result better? Would you say that I've misused your parser to favour my approach? How would you have done it in this case? Would you go beyond and accept the idea that the spaghetti effect is inherent to the callback-based approach of push parsers? Or maybe would you say that the spaghetti effect is small and acceptable here? What do you think about the following links? - https://github.com/google/pulldown-cmark - https://www.ncameron.org/blog/macros-and-syntax-extensions-and-compiler-plug... - https://github.com/Marwes/combine Let's try yet another way to approach the problem (a different perspective again). We talked about heuristics and I begged you to go beyond. But there is one vision/perspective of this problem that may help you. Reason + logic: wouldn't you agree that `basic_parser<T>::eager(false)` is just a hacky way to implement a pull parser? Why? Remember to pay attention to the *why*. I'm not interested in the yes/no. [...] no one has asked for [...] If this becomes something that users
consistently ask for, it can be done by [...]
“if you do not give a try to enter in the general problem and insist on a *myopic vision*” — https://vinipsmaker.github.io/asiohttpserver/#_implementing_ boost_beast_parser_interface Why do you only solve the problem that is immediately in front of you? You're not serious about standardization (consult my comment on technical debt right at the beginning of this email) if you're unwilling/afraid to let go of this modus operandi. There is a bright mind hiding behind this robot. Let us see it. There is a talk that is pure design, “understanding parser combinators - a deep dive”[1]. How do you use *any* of your currently presented lens/perspectives to judge the ideas of this talk? “Look, the idea of composability here is wrong because he hasn't filled a project with 100 issues at Github”. It's just pathetic. I'm not entering in this leads-to-nowhere line of reasoning, so please just stop. What would you use as an example of design discussion? The tutorial I've linked previously[2] or the conversation we're at now? How wrong was I... I just thought you were ignoring the ideas all along. How wrong was I... You just don't understand the subject at hand. “There are these two young fish swimming along, and they happen to meet an older fish swimming the other way, who nods at them and says, "Morning, boys, how's the water?" And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes, "What the hell is water?"” You don't know water, do you? Nor inductive reasoning, nor myopic vision, nor Occam’s razor and the list goes on... It's so frustrating... you can't imagine. You just have no idea. Sorry about the trouble caused so far. I'll meditate on this matter and try to learn something out of this episode. “A cat approaches a dog and says “Meow.” The dog looks confused. The cat repeats, “Meow!” The dog still looks confused. The cat repeats, more emphatically, “MEEOW!!!” Finally, the dog ventures, “Bow-wow?” The cat stalks away indignantly, thinking “Dumb dog!”” Thank you for the useful research that you've done. I'll surely use it (and learn from it). [1] https://vimeo.com/171704565 [2] a tutorial that I've done in a rush and I'm not very proud of, but it still touches design -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/