Hey Matthew, Do you have an example of doing parser combinators without FP? I'd be very interest
On Tue, Jan 24, 2017 at 4:52 PM, Matthew Johnson <[email protected]> wrote: > > On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution < > [email protected]> wrote: > > I agree that being able to implement parsers in a nice way can be a huge > step forward in being really good at string processing. > > There are a couple of possibilities that come to mind directly: > > 1. Build parsers right into the language (like Perl 6 grammars) > 2. Provide a parser combinator language (e.g. https://github.com/ > davedufresne/SwiftParsec). > 3. Rely on external tools like bison/yacc/etc. > 4. Make it easy for people to write hand-written parsers (e.g. by > providing an NSScanner alternative). > > Some obvious drawbacks of each approach: > > 1. Lots of work, probably hard to get right? > 2. Only way to do this, afaik, is using lots of functional programming > which might scare people off. Also probably it's hard to get performance as > fast as 1. > > > FWIW, it is quite possible to do things very similar to parser combinators > without functional programming. What you need is a way to create and > compose small parser fragments, ideally an EDSL approaching something like > EBNF that allows users to build a grammar out of the parser fragments, and > a way to execute / interpret the resulting grammar during parsing. > I'd love to see this. Do you mean "possible today" or "it would be possible"? One really big thing that I took away learning parser combinators is that grammars are composable, whereas parsers themselves are not. Parser combinators express grammars. For example, when you have a Swift parser available, and you want to "embed" it inside a Markdown parser, that's hard to do. Whereas composing the Markdown grammar with the Swift grammar is a lot easier. It'd be nice to have that composability. Chris > > The functional approach would not be the most idiomatic approach in Swift > and as you note, it probably wouldn’t have the performance a more idiomatic > approach could achieve (too much copying). > > My intuition is that a hybrid 1 / 2 approach might be best: do as much as > possible in the library and let the design drive new language enhancements > where necessary. > > 3. No clear integrated way to do this > 4. You still have to know how to write a parser. > > I would think that 4. would be a good step forward, and 1/2 would > definitely benefit from this. > > Also, I'd love to have this functionality on sequence/collection types, > rather than Strings. For example, it can be tremendously helpful to parse a > binary format using proper parsers. Or maybe you would want to use an > event-driven XML parser as "tokenizer" and parse that. Plenty of cool > possibilities. > > On Tue, Jan 24, 2017 at 8:46 AM, Russ Bishop via swift-evolution < > [email protected]> wrote: > >> >> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution < >> [email protected]> wrote: >> >> >> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution < >> [email protected]> wrote: >> >> >> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado <[email protected]> >> wrote: >> >> Taken from NSHipster <http://nshipster.com/nsregularexpression/>: >> >>> Happily, on one thing we can all agree. In NSRegularExpression, Cocoa >>> has the most long-winded and byzantine regular expression interface you’re >>> ever likely to come across. >> >> >> There is no way to achieve the goal of being better at string processing >> than Perl without regular expressions being addressed. It just should not >> be ignored. >> >> >> >> We’re certainly not ignoring the importance of regexes. But if there’s a >> key takeaway from your experiences with NSRegularExpression, it’s that a >> good regex implementation matters, a lot. That’s why we don’t want to rush >> one in alongside the rest of the overhaul of String. Instead, we should >> take our time to make it really great, and building on a solid foundation >> of a good String API that’s already in place should help ensure that. >> >> >> I do think that there's some danger to focusing too narrowly on regular >> expressions as they appear in languages today. I think the industry has >> largely moved on to fully-structured formats that require proper parsing >> beyond what traditional regexes can handle. The decades of experience with >> Perl shows that making regexes too easy to use without an easy ramp up to >> more sophisticated string processing leads to people cutting corners trying >> to make regex-based designs kind-of work. The Perl 6 folks recognized this >> and developed their "regular expression" support into something that >> supported arbitrary grammars; I think we'd do well to start at that level >> by looking at what they've done. >> >> -Joe >> >> >> I fully agree. I think we could learn something from Perl 6 grammars. As >> PCREs are to languages without regex, Perl 6 grammars are to languages with >> PCREs. >> >> A lot of really crappy user interfaces and bad tools come down to >> half-assed parsers; maybe we can do better? (Another argument against >> rushing it). >> >> >> Russ >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > > -- > Chris Eidhof > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- Chris Eidhof
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
