Perl 6 - the future is here, just unevenly distributed

IRC log for #6macros, 2015-11-01

| Channels | #6macros index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #6macros index | Today | | Search | Google Search | Plain-Text | summary