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 ok, so no prior art, then. 01:45
but it *is* what naturally falls out of (a) we process macros ASAP when we know all the parts and (b) unquotes are parts that we don't know yet.
ah; I've seen bracha.org/pluggableTypesPosition.pdf before -- think jnthn++ linked to it
masak reads it now, as it's a short read
01:48 ilbot3 joined
masak ugh. the paper is not proof-read enough. :/ 01:51
"The austere discipline of optional typing forces [a] more minimalist and simple language design, to the benefit of the system as a whole." -- I can feel this effect in action in 007 01:57
"every feature tends to effect every other feature" -- ffs, Bracha! :( 01:58
ok, finished reading the paper 02:11
it contains a review of mandatory/optional type systems
and then two ideas
"what if type systems were pluggable?"
and "what if type inference strategies were pluggable?" 02:12
it doesn't develop either idea particularly, although it does suggest that the program AST could be annotated from the outside with type information 02:14
I believe that's a good idea, and one we should probably make use of for 007
for that to work, 007 needs two things, as far as I can see: 02:15
(a) a way to navigate from every use to the corresponding definition -- something that's on the roadmap for Qtree introspection anyway
(b) a way to map from Qtree nodes to type annotation information. hashing algorithm aside, that means Qtree nodes need unique IDs. but that was probably inevitable anyway. 02:17
Ven, vendethiel: this was flagged up in my twitter stream this morning: arxiv.org/pdf/1510.03726v1.pdf -- you might find it interesting, too. 02:19
05:12 ilbot3 joined
masak er. crucially, the type thing in `{{{fn: Q::Statement::Sub}}}` is *not* a type annotation. 08:10
and I don't see that it can be outside of core the way the rest of the typing syntax/framework can be.
I think the easiest way to manage it is to just make it a core part of the unquote syntax. 08:11
08:49 Ven joined 08:50 vendethiel joined
vendethiel cargo-culting form perl 6 :P 09:31
masak from hypothetical Perl 6 :P 09:32
oh, or you meant the accidental typing of "say expr" all the time?
yes, grr! 09:33
it's in my fingers somehow. and I still don't want to add listop call syntax :)
vendethiel I did, yes :P 09:39
kebabcase \\o/ 09:42
masak I'm having another nice hacking/tinkering day with 007 here :)
will be quite busy next week, though
hoping to still get some tuits with quasis and unquotes and stuff
vendethiel I need to finish implementing my PR. only the runtime value is missing right? 09:45
09:49 FROGGS_ joined
masak checks 09:57
in github.com/vendethiel/007/commit/f...a5b6481efa -- I don't think you need an .eval on Q::Propery, because it's not first-class 09:59
also, I'd still be very much interested in a s:g/pair/property/ rename, for consistency 10:00
(not a merge blocker, though. I'm prepared to merge it and then change it meself)
your branch seems to need a rebase. do you want me to do one?
in github.com/vendethiel/007/commit/d...80475bc544 , I think it should be Q::Sub, not Q::Block. except we don't have a Q::Sub... 10:02
the thing that feels wrong to me about Q::Block is that I feel it should have a name, since the sugar `{ fn() { ... } }` is short for `fn: sub fn() { ... }`
all this indicates that we should get a Q::Sub (Q::Literal::Sub?) and also get subs-as-expressions, which there has been some pressure to get for some time now. 10:03
but if you don't want to do that in this branch (since it's fairly unrelated), then please keep it as Q::Block, and we'll fix it later. 10:04
vendethiel++
vendethiel it shouldn't be a Q::Sub, because those imply lexical presence, from what I've seen 10:09
correct me if I'm wrong 10:10
masak but the methods in objects do close over their surrounding scope
(as do blocks, by the way) 10:11
vendethiel they do
but the name is not present lexically
masak or did you mean "registers in the surrounding lexical scope"?
vendethiel ^ rather t hat
masak yeah, that's what I was thinking would be different with Q::Sub
mirroring JavaScript
vendethiel {fn(){}} mirroring {fn: sub fn(){}) <- doesn't the latter have the name lexically installed?
masak i.e. `var blahoo = function twigzwat() { };` -- `blahoo` gets installed in the surrounding scope; `twigzwat` doesn't 10:12
though `twigzwat` is still a visible name from within that function
11:52 Ven joined 11:53 Ven_ joined 12:50 vendethiel joined 14:34 Ven_ joined 14:35 Ven_ joined 14:54 Ven_ joined 15:10 Ven joined 15:44 Ven joined 15:47 vendethiel joined 16:13 Ven joined 16:26 Ven joined 16:37 Ven joined 17:38 Ven joined 17:54 Ven joined 18:07 Ven joined 18:58 Ven joined 19:17 Ven joined 19:26 Ven joined 19:45 Ven joined 19:54 vendethiel joined
vendethiel > "every feature tends to effect every other feature" -- ffs, Bracha! :( 20:49
masak: I believe "effect" is right here :-).
"effect (verb): To make or bring about; to implement." 20:50
who knows 20:52
anyway, sorry for the backlog delay :)
masak I know "effect" can be used in that way. there's an xkcd strip about it: www.xkcd.com/326/ 23:34
but "affect" would have made more sense in Bracha's text. 23:35
as in "there are interdependencies such that every feature has some influence on all the other features" 23:36

Powered by Cro and the Raku® Programming Language.

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

Thank you!