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.
masak hm, I wonder if we should stop calling arrays/objects "literal" in the Q hierarchy, and start calling them "term" instead 02:37
then that'd go for sub terms, too
then only None, Int and Str would be literals. 02:38
04:01 vendethiel joined
masak not sure why I linked to a fork of the riddley project. I don't think I realized; just searched and that's what I found. 04:35
hm, maybe if `quasi { ... }` actually means `quasi @ Q::Expr { ... }` as a default, we actually shouldn't allow semicolons in it?
because right now that feels like the weird inconsistency, that the default quasi is a Q::Expr by value, but a Q::StatementList by parsing rules. 04:37
heh. actually trying to implement examples/ scripts with 007 turns up all kinds of stuff :P 07:18
09:04 vendethiel joined
vendethiel isn't quasi by default quasi @ Q::Block? 09:04
or StatementList ;)
masak maybe -- I guess it depends what the `@` type actually signifies: 09:06
(a) put the parser in that mode inside the quasi block
(b) this is the kind of Q node that the quasi will evaluate to
(c) both
if it's (b) or (c), then I'd say a quasi by default is `@ Q::Expr`, because that's what macros evaluate to 09:07
vendethiel well, that's where you regret not having blocks anymore :P 09:09
masak heh
vendethiel in lisp,it's all just blocks. just add a (begin), (do), or (progn) (scheme/racket, clojure, common lisp)
masak I'm about to re-introduce blocks through expression-level subs, fwiw 09:10
people can choose to make them anonymous or named
blocks were problematic because people wanted them to give values back, and that's what subs/return did, not blocks
anonymous subs will fix that
vendethiel blocks == SEQ :P 09:11
masak SEQ? "someone else's Qtree"? :P 09:12
vendethiel *g*
masak I want to make some headway with github.com/masak/007/issues/47 , but I find it irritatingly difficult to think about... :/
vendethiel (I wrote my SEQ example on #perl6) 09:13
masak huh -- SEQ() 09:15
vendethiel TimToady introduced it when expr-level ; was repurposed for multidim 09:16
masak apparently un unspec'd circumfix to emulate some legacy sequencing inside parens
an*
vendethiel :)
was it never specced? I didn't check
masak don't see it mentioned when I grep for it 09:17
vendethiel well, guess you had to see the commit. huh 09:18
maybe TimToady forgot about it
masak wow, August 2014. 09:21
vendethiel hah, really? 09:23
masak vendethiel: what did you think about s/Q::Literal::Array/Q::Term::Array/ ? 09:27
vendethiel: (and, in your PR, s/Q::Literal::Object/Q::Term::Object/)
vendethiel much better. "literal" is a very misleading namespace
masak good. then I will make that change.
oh, and it should probably also be s/Q::Quasi/Q::Term::Quasi/, come to think of it 09:28
I'm keeping Q::Literal::Int and Q::Literal::Str, though
vendethiel so the result of a concatenation, or of a +, is a Literal? 09:30
masak no, Q types are about what's in the program text 09:31
results of computations are Val types 09:32
and those are just Val::Str and Val::Int, etc
vendethiel right 09:33
:)
masak or, more rudely, "literals are not a runtime thing" ;)
I think I've narrowed down the problem of github.com/masak/007/issues/47 to github.com/masak/007/blob/master/l.../Q.pm#L663 09:36
er, permanent link: github.com/masak/007/blob/81e0aace.../Q.pm#L663
the new Q::Block gets created at that point without any awareness of its surrounding context.
which means that later, when it's inserted somewhere else, it ends up using that new place's context. 09:37
there's currently no *facility* for attaching that kind of surrounding context to a Q::Block. only to a Val::Block, which has an .outer-frame 09:38
a preliminary conclusion is that a Q::Block similarly needs to have an .outer-block
and that (somehow) .outer-frame chains need to follow .outer-block chains 09:39
vendethiel probably.. 09:40
seems very lexical, yes 09:41
masak quasi blocks aren't really lexical, it's more like they take inspiration from the very consistent lexical behavior of closures, and apply that at the higher level of ASTs. 09:42
...something like that. 09:43
I need a term for that. something that would already appear to make sense.
"hyper-lexical"?
"meta-lexical"?
vendethiel let over lambda has its own term
masak it brings to mind how the robots in Asimov's novels realize that the three laws don't serve them well enough long-term, so they slip in a 0th law 09:44
masak goes over to leaf through the book
vendethiel around the macrolet part
to talk about a "macro's scope"
it's a tad different, though
wouldn't fit here
masak seems that is where I have my bookmark right now 09:46
3.5 Unwanted capture
vendethiel I'd have thought it was between the macrolet stuff 09:58
masak not sure where that'd be 09:59
'macrolet' is not in the index
vendethiel yes it is :) 10:01
letoverlambda.com/index.cl/guest/ch...html#sec_4
not a full title, but definitely in the index 10:02
masak I see it now; checking that section 10:03
10:03 Ven_ joined
masak code walking, huh 10:06
sounds a bit like our visitor macros
Ven_ yes-and-no 10:07
insofar as it's not "applied to everything lexically". it's only in the block you pass it, say
so, I should rename my Object? 10:10
yay, rebased cleanly 10:13
masak :) 10:14
yes, should be Q::Term::Object now 10:15
Ven_ the fact that nothing breaks when I remove Q::Property.eval tells me I don't have any test for that
but I knew it already :P
masak heh :)
Ven_ not sure how tests should look like, however 10:16
masak testing on some stringifications sounds good enough to me
vendethiel call say? :) 10:20
masak sure 10:21
there's plenty of prior art on testing on the output of a 007 program in the test suite
vendethiel looking at other tests did it
10:22 Ven_ joined
Ven_ mh, I ned to implement access though 10:24
masak like obj.foo ? 10:26
Ven_ yea
I can't test stringification for a sub, can I?
oh, I totally can
# expected: '{"a": 1}'
# got: '{Q::Literal::Str "a": Q::Literal::Int 1}
masak it comes out as <block ()> right now
Ven_ aw. well. 10:27
masak heh, you're not supposed to store the Q nodes in there :P
you need to .eval($runtime) them when you put them in
Ven_ yeah, whoops 10:28
# expected: '{"a": 1, "b"}' 10:29
# got: '{a: 1, b: 3}
well.
masak two things about that
(a) it's actually rather nice to have those keys unquoted when that's possible
(b) however, when someone has non-identifier symbols in their keys, we do need to quote/escape them 10:30
I'd recommend going simple right now, and quoting/escaping everything
that's the .quote-Str method I exposed for you yesterday in the Val:: types -- it does that
Ven_ should Q::Property.eval just return `.key.eval => .value.eval`?
masak Q::Property should not have an .eval, because it's not a first-class value 10:31
Ven_ well, it's eval'd to Perl6's =>
masak you'll want to do the corresponding thing from inside of your map in Q::Term::Object
Ven_ Q::Object's eval currently has @.elements.map({.key.eval($runtime) => .value.eval($runtime)})
masak yes, it makes sense that it evals to a Pair, I guess
Ven_ right?
masak yes, looks right 10:32
Ven_ so, do I keep Q::Object's eval calling .eval() itself on Q::Property's keys
or do I add an eval to Q::Property?
masak oh, and I'd go with calling it "properties" for objects (like you did in the grammar), not "elements" (which are for arrays)
Ven_: the former
Ven_ ok
masak expression-y things have an .eval 10:33
statement-y things have a .run
Ven_ # expected: '{"a": 1}'
# got: '{}
masak rigid things (like traits, or object properties, which are always couched inside other structures) have neither 10:34
Ven_ I hate silent extra named args :)
# expected: '{"a": 1}'
# got: '{hey you: 3, a: 1}
now that's an issue. 10:35
I'm just using bare .Str
masak that's what I said in (b) above
vendethiel I despise my internet connection.
yes, I know
masak I think the distinction needs to be "is this one a valid 007 identifier?" 10:36
10:37 Ven_ joined
Ven_ right 10:37
and I have no idea how to do that "there" :) 10:38
masak cheat :) 10:43
Ven_ I'm not about to recall a parser thingie here
masak right 10:44
$str ~~ /<!before \\d> [\\w+]+ % '::'/
is good enough
Ven_ ...
well that's pretty awful :). also I need to specialcase Val::Str
masak Val::Str is the only possible thing an object key can be 10:45
vendethiel also, Val::Str might want a "quoted" or "quote" method?
is there such a thing already?
masak yes
as of last night
.quoted-Str 10:46
it's on all Val:: types
but it's really there for the benefit of strings-in-arrays
vendethiel perfect ;-)
masak and (from your patch onwards) strings-in-objects
yes, playing around with your PR made me realize I needed to refactor that bit :) 10:47
10:51 Ven_ joined
vendethiel erm, seems like I have no quoted-Str 10:52
Ven_ ...and it seems my vim crashed. amazing 10:55
masak github.com/masak/007/blob/2cb44eb0...Val.pm#L40 10:56
Ven_ ya, I get it now 10:57
seems like my first rebase didn't catch all of the commits...????
and it seems my key is a plain Str... -.- 10:58
masak how you store that key in the Q::Term::Object shouldn't matter 11:00
I can see either Str or Val::Str working 11:01
vendethiel there's no .quoted-Str on Str
masak no, but you can create a Val::Str at the last minute
vendethiel oh; but obviously.
masak so it doesn't matter, I mean
vendethiel I need my %properties{Val::Str};
Ven_ adds a .sort to the %{}.map 11:03
masak do you need it to be a hash in Q::Term::Object? or are we in Val::Object now?
Ven_ # expected: "\\{\\"hey you\\": 3, a: 1}"
# got: "\\{\\"hey you\\": 3, a: 1}\\n"
grrr.
masak the got one is correct 11:04
because say()
Ven_ adds a n
ok 8 - can print an object 11:05
masak \\o/
Ven_ "\\{\\"hey you\\": <block ()>, a: 1}\\n" is what the test.. tests for 11:06
access is the only thing left to do 11:08
masak awesome
Ven_ 's not sure how to do that
mostly from a parser PoV 11:09
term:dot-access? 11:10
masak it's implemented already
Ven_ ah? 11:11
for the objects?
masak see 'method postfix' in Parser/Syntax.pm
all you need to do is make sure Q::Postfix::Property does the right thing with your Val::Object objects 11:12
Ven_ 1) <identifier> isn't going to be enough for "hey you"-style keys 11:13
2) should I typecheck on $.ident, or on $.ident eval'd?
masak re (1), you're meant to `obj["hey you"]`, like in JavaScript 11:14
re (2), in `obj.foo`, the "foo" shouldn't be eval'd, it's already what it needs to be. you just fish out the .name
i.e. there's nothing dynamic about it. the identifier is used there for its name, not for any underlying value. 11:15
Ven_ it's not about the foo
it's about the expr, rather
not the ident
masak the expr should obviously be eval'd :) 11:16
Ven_ should I `$obj ~~ Q::Object` or `$obj .= eval; $obj ~~ Val::Object`
masak the latter
otherwise you could only do lookup on object terms!
and note that the .eval logic that's already in Q::Postfix::Property is there to support doing lookup on Q types -- it'd be good if you didn't break that feature 11:18
(it's terribly undertested right now, so it bears pointing out) 11:19
11:23 Ven_ joined 11:34 FROGGS__ joined 16:25 vendethiel joined 18:58 Ven_ joined 19:09 Ven_ joined
Ven_ yeah, from a grep, seems undertested indeed 19:16
... I don't know how to generate an AST with . :( 19:21
19:23 Ven_ joined 20:37 Ven_ joined 20:53 Ven_ joined 21:16 Ven_ joined 21:28 Ven_ joined 21:54 Ven_ joined 22:08 Ven_ joined
masak just parse some text, and you'll have an AST? 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!