|
01:59
Ven`` left
14:19
Ven`` joined
17:17
Ven`` left,
Ven`` joined
20:50
Ven`` left
21:29
Ven`` joined
21:32
lucasb joined
|
|||
| masak | lucasb: I imagine github.com/masak/007/pull/451 will please you :) | 22:30 | |
| Ven`` | masak: have you had any time to take a stab at your advent article? | 22:34 | |
| masak | no, but I can look at it now | 22:39 | |
| I believe I fixed the 17 Dec post now. no idea what happened to it to bust it up so | 22:50 | ||
| I see nothing wrong with the 5 Dec post. | 22:51 | ||
| Ven`` | perfect, thanks | 22:56 | |
| masak | Ven``: by the way, did you catch my feverish ramblings about regexes back in colabti.org/irclogger/irclogger_lo...-12-05#l12 ? | 23:22 | |
| Ven`` | I did | 23:23 | |
| masak | as I re-read that, one thing I didn't manage to catch in writing (but that I've been thinking of) is that it's important for regexes not to become just a "black box", but they should be manipulable/optimizable Qtrees | 23:25 | |
| regexes are quite close to functions in how they behave (and how they capture lexical context) | 23:26 | ||
| but there are two extreme endpoints: one "program structure" use case, where the regex is just used to achieve some effect, kind of like an `if` statement or similar -- and one "first-class" use case, where a regex might be passed around | 23:27 | ||
| it feels to me like the former case should be very optimizable; something like `str ~~ /foo/` should compile down to the same thing as `str.contains("foo")` | 23:28 | ||
| I guess the interesting question is how much of the code-generation machinery should be shared between functions and regexes | 23:35 | ||
|
23:42
lucasb left
|
|||