|
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
|
|||