[swift-evolution] Strings in Swift 4

Tue Jan 24 10:14:56 CST 2017

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 <matthew at anandabits.com>
wrote:

>
> On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> wrote:
>
>>
>> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado <alvaradojoshua0 at gmail.com>
>> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Chris Eidhof
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>

-- 
Chris Eidhof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170124/2a1868fe/attachment.html>