|
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
|
|||
| Geth | rakudo/main: afee7d8d31 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 7 files Relax return constraint on .sort (#6851) Since .sort internally always needs to create a list of some sort, it has always felt a bit silly to me to have to return the result as a Seq (according to documentation), while this is e.g. definitely not true for native array sort (which returns a native array of the same type). ... (8 more lines) |
13:06 | |
| rakudo/main: dfebad8a60 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod Re-imagine ::ApplyPrefix.IMPL-RECORD-NATIVE-RETURN-TYPE (#6856) - no return statements - re-arranged conditions so short-circuiting can happen earler - assuming it will usually work, use ifnull for condition in binding |
13:08 | ||
| rakudo/main: 882110443e | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/literals.rakumod RakuAST: re-image ::QuotedString.IMPL-EXPR-QAST (#6868) Instigated by github.com/rakudo/rakudo/issues/6860 the problem was that it was assumed that concatenation of interpolated strings could be done with nqp::ops such as concat and join. However, that means that any additional candidates to infix:<~> ... (6 more lines) |
13:11 | ||
|
13:12
iwuvmika left,
iwuvmika joined
|
|||
| Geth | roast: eebbefbc0a | (Elizabeth Mattijsen)++ | S06-operator-overloading/infix.t Add test for fix for visibility of additional ~ ops github.com/rakudo/rakudo/issues/6860 |
13:16 | |
| lizmat | that's one release blocker less | ||
| [Coke] | releasable6: next | 13:32 | |
| releasable6 | [Coke], Next release in ≈4 days and ≈5 hours. 1 blocker. 46 out of 202 commits logged | 13:33 | |
| [Coke], Details: gist.github.com/eee7dcc25a947a4502...b35e34c819 | |||
|
15:52
iwuvmika left,
iwuvmika joined
16:02
iwuvmika left,
iwuvmika joined
|
|||
| Geth | rakudo/main: dc339a5d0d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 20 files RakuAST; make .get-implicit-lookups return an nqp::list (#6864) Rather than a HLL list. Since all calls to .get-implicit-lookups were wrapped in a self.IMPL-UNWRAP-LIST, and .get-implicit-lookups always wrapped any NQP list in a self.IMPL-WRAP-LIST, it doesn't make any sense to do this. So remove the IMPL-WRAP-LIST from .get-implicit-lookups, and remove all IMPL-UNWRAP-LIST from calls to .get-implicit-lookups. This method is getting called more than 100K times during setting compilation. |
17:54 | |
|
18:11
zostay left
18:38
zostay joined
|
|||
| Geth | rakudo/lizmat-82: 6 commits pushed by (Elizabeth Mattijsen)++
|
18:44 | |
| rakudo/main: aa1262d242 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files RakuAST: access val() processing in an easier way (#6867) By adding a val() candidate taking a native string, and then not bothering HLLization in ::QuoteString.IMPL-PROCESS-PART |
18:46 | ||
| [Coke] | c: aa1262 e | 20:25 | |
| committable6 | [Coke], ¦aa1262: «» | ||
| [Coke] | kicking off a blin run. | 20:26 | |