<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am Di., 9. Okt. 2018 um 15:45 Uhr schrieb Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] What I'm trying to say here is that tracking the backtracking level in types doesn't seem like it will fly (tempting though it may be).<br></blockquote><div><br></div><div>... and even if it did fly, parser combinators with backtracking have a strong tendency to introduce space leaks: To backtrack, you have too keep previous input somehow, at least up to some point. So to keep the memory requirements sane, you have to explicitly commit to one parse or another at some point. Different combinator libraries have different ways to do that, but you have to do that by hand somehow, and that's where the beauty and maintainability of the combinator approach really suffers.</div><div><br></div><div>Note that I'm not against parser combinators, far from it, but I don't think they are necessarily the right tool for the problem at hand. The basic problem is: Haskell's syntax, especially with all those extensions, is quite tricky, and this will be reflected in any parser for it. IMHO a parser generator is the lesser evil here, at least it points you to the ugly places of your language (on a syntactic level). If Haskell had a few more syntactic hints, reading code would be easier, not only for a compiler, but (more importantly) for humans, too. Richard's code snippet is a good example where some hint would be very useful for the casual reader, in some sense humans have to "backtrack", too, when reading such code.</div></div></div>