01:28
lucasb left
|
|||
masak | Ven``: agreed. let's use it :) | 06:54 | |
Ven``: my biggest constraint right now is that I'm moving house and it's taking a disproportionate amount of my time and attention | |||
Ven``: besides "walk", after the object system refactor, I'm also going to trigger the Cheating era, which will be a big change | 07:00 | ||
(before anyone asks: "Cheating" refers to adding a _lot_ of parser extensions, available through `import`, provided by semi-black Perl 6 magic instead of Genuine(tm) 007-parser extensions) | 07:01 | ||
(see all of #401 for details) | 07:02 | ||
10:46
Xliff joined
12:12
lucasb joined
16:00
Ven`` joined
|
|||
Ven`` | masak: o/ | 16:00 | |
Yes, I understand the bit about moving very well..:) | |||
I'd like to have a brainstorming on "declaring names from inside a macro" | 16:01 | ||
I think to get `defsuccinct`, the list goes as follows: 1) hygiene 2) locations 3) walk() itself (probably need to discuss what we want to expose, but our own Q api doesn't expose all that much) | 16:02 | ||
so, I guess, hygiene first imho. | |||
jnthn idea: COMPILING:: as a dynamic variable that's per-quasi-expansion, so you can get back all your values | 16:57 | ||
(and after expansion / maybe in Actions::expand?, we get this COMPILING, and we $*runtine.declare-var...) | 17:06 | ||
19:27
Ven``_ joined
19:44
Ven``_ left
19:45
Ven``_ joined
|
|||
Ven``_ | masak: there are a few cases where we backtrack a bit too much. | 19:49 | |
sometimes I get a missing block because I've used a single-quoted string (which don't exist) instead of a "neat-er error" | 19:50 | ||
guess I'm gonna try and implement COMPILING in a cheat-y way | 19:53 | ||
masak | the current parser has some famously unhelpful error messages | 20:22 | |
it should be replaced wholesale with a better one | 20:23 | ||
and one where proper attention has been paid to error messages | |||
(I have a neat idea I want to try there, more information upon request) | |||
Ven``_ CTCP masak MOREINFO | 20:36 | ||
mh, second attempt of the day trying to recover variable from the quasi, very unsuccesful so far | 20:37 | ||
I think I'm still getting a bit too confused about phases :-( | 20:42 | ||
.oO( how ironic: he could see through the lisp quasiquoting levels, but not his own ) |
20:43 | ||
masak | haha | ||
the moreinfo that was requested: instead of writing tests that check that when some particular input is provided the correct error message occurs, just _specify_ error messages in that way directly to the grammar | 20:44 | ||
i.e. an _example_ input is provided, along with the place where it's supposed to fail, and the desired error message | |||
the grammar framework does the heavy lifting of figuring out to which parser state this error message should be attached | 20:45 | ||
Ven``_ | ah I see | 20:47 | |
masak | it's not my idea. I read it somewhere | 20:49 | |
but it's obviously a neat one -- "throw error messages at the grammar and make it attach them in the right place" | |||
Ven``_ | how very common lisp-y...:) | 20:59 | |
ok well I'm really not sure how this all works... | |||
Q:::Term::Quasi#eval generates the actual AST node to execute but of course doesn't execute them in place. It does, however, create a lexpad | 21:00 | ||
(so I tried to declare-var COMPILING => Val::Dict.new there) | |||
but the evaluation is only in Q::Expr::BlockAdapter#eval | 21:01 | ||
*sigh | 21:03 | ||
I wish I _actually_ understood something about 007 :\ | |||
oh, I got it | |||
gist.github.com/vendethiel/9792ef3...4efa5bfb23 | 21:09 | ||
this works with my hack | |||
masak looks | 21:11 | ||
cool | |||
I mean, stuff it in a branch, and we can discuss how to clean it up and add it as a PR | 21:12 | ||
Ven``_ | no, it's too awful for now | ||
masak | ok :) | 21:13 | |
it _is_ an interesting idea how to make COMPILING:: work | |||
Ven``_ | well, I had to disable `checking-postdeclared`. | ||
Mostly because I don't see any other option, tbh. | |||
masak | right | 21:14 | |
doesn't surprise me | |||
I've been thinking about that bit, actually | |||
Ven``_ | I tried an alternative at $work: `macro f() is declaring("x") {}` | ||
if we restrict to literal strings *or* from arguments, maybe we can have our cake and eat it? | |||
(let's say literal strings, any arg - will need itself to be a literal string!, and of course interpolations, so we can generate slightly diff names) | 21:15 | ||
this allows us a best-of-both-worlds, it seems. I need to figure out how to get the names from the trait down to the code that extracts COMPILING stuff | 21:16 | ||
wdyt? | 21:17 | ||
masak | I read your words but I don't think I get it yet | ||
something hasn't clicked | |||
"from arguments", you mean something like `macro f(x) is declaring(x)` ? | 21:18 | ||
Ven``_ | yes. | ||
masak | that's very going away, as we turn traits into annotations | ||
Ven``_ | :-( | ||
masak | and I believe that's a good thing | ||
Ven``_ | ok, I'll use integers to refer to parameter positions instead. | ||
masak | can't quite motivate why, but traits are in an odd position | ||
Ven``_ | nah I think I actually agree... traits are applied to the macro itself, not its invocations | 21:19 | |
masak | right | ||
I think there's an issue somewhere where I ruminate about how to achieve this | 21:20 | ||
something about grabbing the parser and telling it outright to declare a name | |||
21:25
Ven`` left
|
|||
Ven``_ | wait, I did what | 21:31 | |
uh oh | |||
well, I should maybe move more of the discussion here, | 21:32 | ||
so, are we tree walking once again? looking for `COMPILING` accesses? | 21:33 | ||
(I feel very much afraid that COMPILING is also able to do non-declaring things, seems to me like it completly breaks hygiene) | |||
masak | its purpose is to break hygiene | 21:35 | |
anytime you use it, you're circumventing hygiene and getting the dangerous unhygienic semantics | 21:37 | ||
note also that (out of necessity), COMPILING:: is a _static_ scope | |||
Ven``_ | there's breaking hygiene and breaking hygiene | ||
masak | I don't know if CL has this concept, but Perl sure does | ||
Ven``_ | wouldn't really make sense, CL is expression-oriented | 21:38 | |
masak | right | ||
"parse, run" | |||
Ven``_ | you don't know if the (top-level) expression after you makes any sense until you're done executing. | ||
masak | I get the sense Python is similar | ||
Perl is very much not | 21:39 | ||
in this sense Perl is "two-pass" :) | |||
Ven``_ | Python seems very distant to me, at least wrt my last message | ||
I don't feel good that the only way to introduce new names is to break hygiene. | |||
masak | that's why I suggested to look at my API musings | 21:40 | |
basically something like `import parser` and then talk to that object about declaring a new name | |||
I think I wanted to do that inside of the `is parsed` regex, though | |||
Ven``_ | finding an issue in the 007 repo is not as easy as you imply it to be :-( | 21:41 | |
masak | ok, lemme find it for you | ||
Ven``_ | github.com/masak/007/issues/159 | ||
actually it is | |||
I'm a huge liar | |||
masak | yeah, that one | ||
Ven``_ | this belongs to `is parsed` (and feels a bit hand-wavy too, though I understand the general idea), and that's both shoulder on giants we'd like to sit on and a huge can of worms. | 21:42 | |
masak | that last comment is what led to the current distinction between Q.Identifier and Q.Term.Identifier | 21:43 | |
masak .oO( if I have seen many worms, it's because I've been standing on a giant can of worms ) | 21:44 | ||
Ven``_ | .oO(.is it better or worse than a can of giant worms? ) |
21:45 | |
ok, anywya | |||
> Here, let me just throw "study Racket" on top of my TODO pile, right after "finish the 'Let Over Lambda' book"... | 21:46 | ||
2016 were less busy times :p | |||
masak | in my defense, I don't think I ever quite finished that book | 21:48 | |
Ven``_ | he he he | 21:49 | |
me neither, but only because the last 2 chapters aren't on the website :P | |||
masak | :) | 21:50 | |
Ven``_ | I don't feel very satisfied with this answer | 21:54 | |
but that's all I'll do about it for tonight | |||
I still kinda like the declarativeness of `is declaring` or the like | |||
masak | I think I agree that the current solutions are unsatisfying | ||
I... I don't immediately think the `is declaring` should go on the macro as such. it feels to me it belongs nearer to the quasi | 21:55 | ||
macros are just routines that return code back to the compiler | |||
Ven``_ | that means you need to evaluate the macro to continue parsing (well, before we check for undeclared identifiers anyway) | ||
masak | the code itself is created with `quasi`, and that's where variables are declared in funny ways | ||
well, yes | 21:56 | ||
macro expansion includes unhygienically declaring variables from the expanded injectile | |||
of that I'm sure already | |||
Ven``_ | mmh | ||
masak | probably, if that leads to a collision, that should be a fatal compile-time error | 21:57 | |
something like `my $x; moo() # also declares $x # boom` | |||
well, $COMPILING::x | 21:58 | ||
Ven``_ | I don't like the amount of flexibility you have there | ||
masak .oO( THIS IS SP^W PERL ) | |||
Ven``_ | well, for sure provide tools to break hygiene if really needs be, but introducing stuff to outer scope seems like very small chunk of that idea, and a much saner one at that | 21:59 | |
.oO( The ruby to my perll, the little sister that doesn't do as many drugs ) |
|||
masak | `my COMPILING::{ident}` does exactly that, no? | ||
masak handwaves over the syntax to somehow heal it | 22:00 | ||
Ven``_ | wait, what's that `my` doing there? | ||
masak | declaring...? | 22:02 | |
you can't just start _using_ a variable without declaring it, you know :P | 22:03 | ||
22:03
Ven``_ left
|
|||
masak | this isn't Python, or Ruby | 22:03 | |
22:36
Ven`` joined
22:40
Ven`` left
|