|
17:38
Ven`` joined
18:16
Ven`` left
18:19
Ven`` joined
18:33
Ven`` left
18:48
Ven`` joined
|
|||
| masak | lucasb: I would tend to agree, except in all other aspects so far, 007 has managed to keep whitespace insignificant | 19:36 | |
| arguably, it's a little bit different *while parsing an identifier*, though | 19:37 | ||
| the latest thing to really surprise me wrt whitespace insignificance: github.com/masak/007/issues/409 | 19:38 | ||
| (simply because I never write my function calls with a space) | |||
| lucasb | with regard the emit-stmt multis in js backend, I was mistaken, they are nested subs inside the method, so I guess it was your intention | 19:51 | |
| masak | yes, although having them after the return statement is admittedly a bit idiosyncratic | 19:53 | |
| I regret a little bit that I/we haven't gotten further on the JS backend. it shouldn't be all that hard, actually. 007 is still a small language. | 19:54 | ||
| 'sides, minor semantic differences (for example in Ints/numbers) should be tolerable | 19:55 | ||
| lucasb | I would like to ask some questions, if you don't mind. It's ok if you leave them unanswered, don't mind if you're busy! :) | 19:58 | |
| does "Val::" stands for... "value" ? | 19:59 | ||
| it's like all language values are... "Val::" type? | |||
| it's what you call "runtime values"? | 20:01 | ||
| they are only needed because you've build an interpreter, right? If you just wanted a a compiler (for ex. to JS), then you wouldn't need those types? Is this correct? | |||
| if you only wanted a compiler, only the Q:: types would be needed. Is it? | 20:02 | ||
| the Q:: types are the nodes in the AST? | 20:04 | ||
| it's like NQP's QAST then? | |||
| masak | the Val:: type hierarchy is a bit artificial -- but (to a first approximation) any value found inside of a running 007 program should be either from Val:: or from Q:: | 20:05 | |
| #242 eliminated that artificial distinction, but it never merged | 20:06 | ||
| "runtime values" is a good lie-to-children -- of course Val:: values can be compile-time and Q:: values can be runtime, too | 20:07 | ||
| yes, the Q:: types are all participants in the AST, like NQP's QAST. the "Q" in Q:: is partly named that way due to the name "QAST" | 20:08 | ||
| (and "QAST", as we all know, is named after the infamous Quantum Michaud) | |||
| again, note that we often find Val:: values inside of Qtrees also; for example, the .name inside of a Q::Identifier is a Val::Str | 20:09 | ||
| lucasb | ah yes, I noticed, the Q:: types was wrappers around Val:: ones | 20:10 | |
| masak | an example of what I didn't expect from the get-go :P | 20:12 | |
| lucasb | thank you for explaing, masak! | 20:13 | |
| masak | here's my very latest idea of a way to implement Val:: and Q:: -- any 007 value can do a subset of these four things: (a) get type(o), (b) get a property like o.foo, (c) index, like o[ix], (d) call, like o(...) | 20:15 | |
| from that, everything else should follow. specifically, there'd be no more need for Val:: | |||
| Q:: would still exist, but be defined completely inside that object-land, not inside Perl 6 | |||
|
22:22
Ven`` left
|
|||