|
03:12
iwuvmika joined
03:34
iwuvmika left
03:40
iwuvmika joined
|
|||
| lizmat | while working on the Dutch translation of the Raku Guide, I was suddenly struck by the fact that parsing texts with a grammar feels a bit backward syntax wise | 10:20 | |
| grammar.parse($text) | |||
| wouldn't $text.parse(grammar) as alternate syntax also make sense ? | 10:21 | ||
| method parse(Str:D: Grammar $grammar) { $grammar.parse(self) } | |||
| ShimmerFairy | I suppose it depends on if you think of methods as asking the class to do something to the invocant (Str.parse = "Str class, do a parse on this string object"), or if you think of them as asking the object itself to do something ("string, please parse this grammar"???) | 10:51 | |
| lizmat | I was more thinking like: we also have .match on a string | 11:08 | |
| or maybe .match should just accept Grammars | |||
| ShimmerFairy | I kinda like the idea of putting a new overload on .match instead. Feels better than having two classes with the same-named function working in opposite ways (less risk of $str-var.parse("bar") mistakes). The only thing to note is that this hypothetical Str function, whatever the spelling, would have to support the usual :actions etc. arguments you can usually pass to parse. | 11:15 | |
| lizmat | ah, the magic of |%_ :-) | ||
| ShimmerFairy | The one downside to a Str.match overload is that it makes a Str-side version of Grammar.subparse more awkward to include, if you even wanted that. (parsefile is, of course, something that would be on the IO stuff if anything) | 11:16 | |
| lizmat | so maybe not overload .match then :-) | 11:21 | |
| ShimmerFairy | I do like the idea of overloading .match as just another step in "matching complexity"; match a literal string -> ad-hoc Regex -> full Grammar. You could make the case that subparse is an "advanced use" of grammars, since they're almost always used to parse an entire text, so it's fine to be forced to use Grammar.subparse then. | 11:28 | |
| lizmat | hmmm... so you're saying Str.match(grammar) should call .subparse ? | 11:40 | |
| ShimmerFairy | eh, I'm not so sure. The default state of a regex is to not match the whole string, unless you add in two extra characters and type it like /^ ... $/. But for grammars, I'd argue the "default state" is to parse the whole thing, so .parse should be used. | 11:42 | |
| IME at least, grammars are usually used when you have "a file" whose entire contents need to be valid syntax, and parse out to some kind of AST. In contrast, if you just want to extract a part of the string with little care for surrounding context, the Grammar mechanism is likely overkill. | 11:43 | ||
|
12:47
iwuvmika left
12:48
iwuvmika joined
|
|||