|
6macros: discussing the finer points of Perl 6 macros, Qtrees, and how to stay sane | irclog: irclog.perlgeek.de/6macros/today Set by moderator on 28 July 2015. |
|||
|
13:00
cog__ joined
17:54
Ven joined
18:13
Ven joined
18:34
Ven joined
18:53
Ven joined
19:13
Ven joined
19:33
Ven joined
19:53
Ven joined
|
|||
| masak | Ven: oh! cool! | 19:56 | |
| masak thinks about the question | |||
| your own reaction -- "no q types in val, ever!" -- is largely right | |||
| the only time we break that is with Val::Sub, which contains a Q::ParameterList and a Q::StatementList. but I've always considered those to be somewhat suspect and worthy of excision | 19:58 | ||
| Ven: in the absence of a need/use case for the opposite, I think Val::Regex can be pretty opaque, and not need to respond to "unpacking" or destructuring | 20:00 | ||
| the only thing we really require of it is that it match on strings | |||
| that way, I think we can avoid a proliferation of new Val::Regex::* types | 20:01 | ||
| instead, we can aim to be as creative as we need with the Val:: types we already have | |||
| vendethiel | so I should convert the Q::Regex::* to other stuff? | 20:07 | |
| (I have Q::Regex::{Identifier,Call,Group}) | 20:08 | ||
|
20:13
Ven joined
20:33
Ven joined
|
|||
| masak | no, the Q::Regex::* types are fine | 20:39 | |
| in the Q end of things we *do* need the type fine-grainedness | 20:40 | ||
| I guess what I'm saying is that if a Val::Sub can be a mostly-opaque type then Val::Regex can, too | |||
|
20:53
Ven joined
|
|||
| vendethiel | well, not sure how that'll turn how to work then | 21:04 | |
| I'll check on Val::Su | |||
|
21:05
Ven joined
|
|||
| Ven | > Could not locate compile-time value for symbol Val::Array | 21:07 | |
| whatever did I do ._. | 21:08 | ||
| I'm not sure how to fix this Perl 6 error, at all... | 21:19 | ||
| even stashing doesn't fix it, whoops... | 21:20 | ||