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.
01:56 ilbot3 joined 13:37 ilbot3 joined 19:59 Ven`` joined
Ven`` masak: ping me if you're available for some brain-munching 20:03
I'd like to talk about is parsed. We've had most of the pieces for a solid 6 months now, and the idea of being able to toy with it sounds amazing 20:05
masak Ven``: agreed. ping. 20:08
Ven`` pong!
masak (I'll be intermittent for a few more minutes, because laundry. but you do have my attention!) 20:09
let's hash this out
Ven`` mmh, first, to find the issue
well, github.com/masak/007/pull/258
I'm not sure where we had a very short discussion ~a week ago, but you said something along the lines of: "we'll need to register the is parsed macros" 20:10
masak wonders if we should add more things to the "do not merge before the following" section :)
think the discussion was here on channel
Ven`` oh, right
masak yep, on the 11th 20:11
well, one insight I had working on that PR is that *all* categories will be extensible, not just prefix/infix/postfix
but perhaps the most pressing one is the statement category, because that's where most of the fun is, to be honest 20:12
bfb
brb*
I know I keep saying this, but I can totally see how at some point doing what 007 wants is going to be easier without a Perl 6 grammar than with one 20:19
(it's not a total certainty, of course. maybe I'm just not savvy enough in grammar metaobject hacking to see how to do what we want easily.) 20:20
20:21 Ven`` joined
masak welcome back. irclog.perlgeek.de/6macros/2018-05-12 20:27
Ven`` wow, internet. 20:38
> without a Perl 6 grammar than with one
what does that entail?
masak what we need to register, more exactly, is "in this scope, which things are statements?" -- whether or not we make an internal distinction between built-in ones and custom ones provided as macros shouldn't matter 20:39
Ven`` oh, you mean as an implementation detail. 20:40
masak what leaving the Perl 6 grammar behind entails: it'd mean we do the parsing manually, as some kind of recursive descent, I guess. but it also means we're more in control, which might matter when we do more things like this.
Ven`` yeah right here and now i see two options 20:41
let's say, 3, with one crazy 20:42
masak but, again, there *is* prior art in this case, so we should be fine.
Ven`` - building a list of "prefixes" (first part of the regex) -- doesn't work except for simple cases
- work with !CURSOR -- horrendous
masak ...go ahead
Ven`` - convert the regexes to actual perl 6 regex -- crazy 20:43
I mean I'm not really surprised we're hitting such limits. Some things Perl 6 grammar aren't great at, one of them being the MD parser you demonstrated at SPW 2 years ago
masak mhm 20:44
Ven`` seems like internet is gonna leave me again 20:45
masak in the case of infix ops, for example, what we do is write the `infix` rule as a method
we should be able to do something similar with statements 20:46
20:46 vendethiel- joined
masak this might correspond to your second alternative 20:46
vendethiel- Yes, this was a bit what I was referring to
masak (which isn't so horrendous with ops, at least)
vendethiel- but... it works in this case because it's reducing stuff that's already been parsed 20:47
masak I think the biggest difference is that ops are fixed strings, but `is parsed` statements need to "delegate" to a 007 regex
more than ever before, we're suffering from the implementing language being Perl 6 and not 007 20:48
vendethiel- you're right. with the current runtime speed, i'm barely able to check reddit before the program is done running :P 20:49
sorry, that was too snarky for what I meant, no reason to be that way. still i'm scared of reimplementing it in 007 for this reason
masak heh 20:50
no worries, 007 isn't winning any speed competitions, and that's not what it's built to do either
I'm not actively proposing we reimplement the parser in 007 just to solve this problem 20:51
thinking about what you wrote above about "prefixes". let's say you had two `is parsed` statement macros that both started successfully matching a statement. at which point does that become a problem? 20:52
vendethiel- it becomes a problem even before that. 20:53
anything that's not a string prefix breaks this
a group prefix, quantifier, etc
masak well 20:54
Perl 6 parser lore talks about "longest *declarative* prefix", not "longest constant prefix"... 20:55
vendethiel- the old scriptures do say... :-P 20:56
masak but again, let's strive towards simplicity first
with constant prefixes, at least we can dispatch very easily...
vendethiel- i'm not sure this is actually a good idea at all hahaha 20:57
i mean it gets us "whoa!" working.
everything else is outside the picture
s/outside/out of/ # english I guess
masak what about github.com/masak/007/issues/280 ? 20:58
the prefix in that case is "loop", a constant string...
oh, or you mean that we still don't quite have a story for how to capture things and get them into the macro?
vendethiel- yes
that too, but also we need to pretend some 007::Grammar.pm6 things are 007 regexes 20:59
so that we can "is parsed(/loop <block>/)" or so
masak right
but there's a finite number of those
vendethiel- true. and they will actually be the easy case.
masak gah, where did I put my latest definitive view on how sane it is to say <block> in that case? 21:00
I know I was legitimately concerned about lexical scoping
vendethiel- because in all other cases, we fall back to the initial problem: getting the grammar to yield control back to us
maybe TimToady has an idea on that one, I know the Perl 6 grammar does a wonderful amount of hacks
masak I recall TimToady saying once that `is parsed` macros no longer seem like a good idea to him :) 21:01
vendethiel- grmbls 21:02
masak if we can show how in practice it isn't a good idea, then we'll have accomplished something :P
vendethiel- i'm surprised but alright
stopping at custom operators is surprising 21:03
well, I guess you could say it's the path clojure took
masak 007 is not stopping at custom operators :) 21:04
vendethiel- I know 007 isn't, I'm just saying 21:05
not sure, it's probably just because I'm a champion of such syntax, but this feels like a "maybe this is a good idea in theory, but with users it's not" 21:06
masak: your point about lexicality is well-taken. We don't have packages (yet), but a "pre-installed package" (not a Prelude because not i,ported by default) with access points into 007 grammar seems like a fine choice 21:07
is parsed(/"loop" <007::Block>/)
masak *nod* 21:12
oh, I think I addressed this in one of your PRs...
yeah, seems I was thinking of github.com/masak/007/pull/239 21:14
the *lexical* thing for <block> to refer to would be a named thing in scope called `block` 21:15
and maybe that's fine with *regular* regexes, but with `is parsed` regexes, it's as if they want to "detach" from that regular lexical regime and default to looking things up in the grammar 21:16
urgh 21:17
when I say it like that, I think I do prefer your 007:: prefixing idea :)
vendethiel- šŸ˜†
packages are very global in their nature, but a "neatly organized" kind of global. 21:18
masak I mean, it sorta-kinda makes sense that they want to detach and find themselves "in" the grammar, since that's the "current language" we're extending
but that doesn't change the fact that we're doing a lexical nasty
ooh
how about
<lang::block>
but `lang` *is* a lexical thing, and `::` means something like "unbound method" 21:19
maybe <lang.block> as in "bound method" would be more accurate
anyway, I think I can live with that, because it's consistent with the rest of the OOP design
and we might end up doing *zero* violence to lookup rules, which feels right 21:20
could also call it <parser.block> if that feels better 21:21
vendethiel- 007 is very much the lang here 21:22
masak only until you extend it with some pragma or other 21:23
that's been one constant refrain with the linter, by the way -- the work on the linter is a bit stalled, because I keep realizing that anything that changes the language also changes the rules under which we do linting 21:24
it's not an unsolvable thing, it's just... anything that extends the language also has responsibilities towards other parts of the toolchain
vendethiel- very much so 21:42
undecible parsing galore to start with
masak well, linting takes place on the AST, so that in itself is not a big problem 22:07
unless I misunderstand what you mean, which is possible 22:08
vendethiel- ah, so it does 22:14
i wasn't sure, i'm sorry
masak :)
anyway, coming back to the main topic
I think we're going to have to do this by taking the simplest choice at every point, but building something that works 22:15
#258 could probably be made mergeable without too much more effort 22:16
'night 22:19
vendethiel- 'night! 22:21

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!