|
pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/ Set by TimToady on 25 January 2008. |
|||
| TimToady | a derived grammar that overrides infix:sym<+> probably wants to infer the prec/assoc from the base grammar's infix:sym<+> | 00:01 | |
| mncharity | ./STD5_run statementlist -e 3 doesn't yet work, so I don't know how to check whether the gimme5 output is fast enough to be then easily used as a usable p6 implementation's parser. | 00:02 | |
| TimToady | and that's a little strange unless rule methods act more like prototypes with parent pointers | ||
| yes, I tried statementlist the other day and ran into trouble, but it's probably a minor bug compared to the others | 00:03 | ||
| something was getting confused in unv | |||
| mncharity | re 'probably wants to infer', really? well, I suppose there are two use cases. doing small tweaks, and minimum user surprise lies in "it's still just like p6". and doing DSL's, where the user expectation may be different. perhaps not so much for infix:<+>, but in general. | 00:04 | |
| TimToady | probably just a scalar/array deref foulup | ||
| induced by the fact that everything is done with lists but ratchet code usually just wants .[0] | 00:05 | ||
| yes, there are different DWIMs fighting there | 00:07 | ||
| but I'm mostly not considering macros here, but complete derived grammars | |||
| so mostly talking about DSL's her | 00:08 | ||
| e | |||
| mncharity | lol # "there are different DWIMs fighting there" | ||
| TimToady | minor tweaks with macros are specced to be more like "assume it's the same as standard p6" | 00:09 | |
| so this might actually be a fundamental difference between the user-oriented name infix:<+> and the grammar-oriented name infix:sym<+> | 00:10 | ||
| and, in fact, within a grammar both of those are possible, and mean two different things | 00:11 | ||
| mncharity | ?!? | ||
| TimToady | infix:<+> is the name of my current infix + operator, which has little to do with the language I'm parsing | ||
| infix:sym<+> is not the name of an operator, it's the name of a rule | |||
| however, we can infer that the eventual user-visible name of the resulting operator is likely to be infix:<+> | 00:12 | ||
| but that's what its name will be in the user's code, not in our code. | |||
| mncharity | (apropos "a derived grammar that overrides infix:sym<+> probably wants to infer the prec/assoc from the base grammar's infix:sym<+>", while I don't really buy 'probably wants to infer', I'd totally agree with 'wants to _be able to_ infer'). | ||
| TimToady | might just be explicit delegation in that case | 00:13 | |
| or just using the same --> Mumble | |||
| PerlJam | mncharity: speaking as a "user", I'd *expect* precedence and associativity to be the same as whatever I happen to call "normal" :) | ||
| TimToady | there are even more DWYM's fighting here than DWIM's | 00:14 | |
| mncharity | PerlJam: yes, but your expectation of "normal" looking at p6-like code, and looking at say PSQL, might be rather different. | 00:15 | |
| TimToady | and, of course, you can expect all you like, but you can also be wrong :) | ||
| mncharity | or at APL ;) | ||
| TimToady | which is a recursive acronym for APL's Precedent-Less | 00:16 | |
| mncharity | oy | ||
| PerlJam | mncharity: sure ... what I'm saying is that, when the perl6 grammar is my baseline, I want the same assoc/prec for its symbology by default unless I've explicitly changed it. | ||
| (And when APL is the baseline ... etc) | 00:17 | ||
| mncharity | might be a place for one of those huffman encoding of "do you really want to do this?". | ||
| TimToady | and macros basically give you that. and I think a DSL designer would be mad not to go along with that if they want p6 programmers to use it | ||
|
00:17
GeJ joined
|
|||
| TimToady | huffman coding is *precisely* what APL lacks :) | 00:18 | |
| which is, of course, why it looks like noise | |||
| PerlJam | you could also say that everything in APL is huffman coded :) | 00:19 | |
| TimToady | and you could be wrong again... :) | ||
| PerlJam | I reject your reality and substitute my own! ;) | 00:20 | |
| mncharity | so if I say my sub infix:<+>($a,$b){42}; I can call it as infix:<+>(3,4); And I expect $x=3+4; to give 42. | ||
| TimToady | PerlJam: you are Officially Allowed | ||
| mncharity | if I say my sub infix:<foo>($a,$b){42}; infix:<foo>(3,4) should work. What about $x=3 foo 4;? | 00:21 | |
| TimToady | mncharity: yes, you could do that, and yes, you could do that | 00:22 | |
| meppl | good night | ||
| TimToady | I believe foo would default to + precedence | ||
| mncharity | g'night meppl | 00:23 | |
| meppl | ;) | ||
| mncharity | so my sub infix:<foo>($a,$b){} is, in part, another way of saying token infix:<foo>{'foo'} ? | 00:24 | |
| TimToady | see S06:1704 for why infix:<foo> would default to infix:<+> prec | ||
| mncharity | re default + prec, ok | 00:26 | |
| TimToady | except that token is really defining a method on the current class, not the current language | 00:29 | |
| possibly it could dwym from noticing that you left out the "sym", but that's kinda subtle | 00:30 | ||
| and there doesn't seem to be much reason not to use a macro instead, so that you actually supply some semantics :) | |||
| mncharity | my sub infix:<foo>($a,$b) is token {} | 00:31 | |
| TimToady | is parsed(token {...}) {42} might do | ||
| mncharity | re ' not the current language', so how does one say I want a new token in the current language, but only in this here lexical scope. | 00:32 | |
| TimToady | macros are always lexically scoped | ||
| references to names like infix:<foo> imply macro binding of that name to a lexical scope | 00:33 | ||
| regardless of the actual scope of the declaration | |||
| imported macros are likewise always lexical | |||
| all grammatical tweaks are lexical, always | 00:34 | ||
| mncharity | so my macro infix:<+>($a,$b) is parsed(token {'+'}) has :precedence<42>{OUTER::infix<+>}; # change +'s precedence to 42 for this block. ? | 00:35 | |
| my macro infix:<+>($a,$b) is parsed(token {'+'}) has :precedence<42>{OUTER::infix<+>($a,$b)}; | 00:36 | ||
| TimToady | there are no absolute prec levels visible to the user, so you're talking something like "is looser", but basically yes | 00:37 | |
| and precedence levels are strings rather than numbers in p6 | 00:38 | ||
| so we can do the surreal precedence ad infinitum | |||
| mncharity | so token foo{'foo'} creates foo in a grammar, macro foo is parsed(token {'foo'}){...} creates foo in a grammar, but limited to a lexical scope. | 00:39 | |
| TimToady | and if you use a new grammar, that is lexically scoped | ||
| an anonymous token is really just equiv to a /.../ | 00:41 | ||
| well, with :sigspace:ratchet | |||
| er, just :ratchet | |||
| mncharity | so long term, do most of the token decls in STD.pm go away, and become artifacts of... no, the Prelude has multi sub infix:<+>, not macro infix:<+>. soo | 00:42 | |
| use macro if you want to create a new token, and use multi if you wish to join in playing with an existing one, and ... | |||
| TimToady | basically | 00:44 | |
| mncharity | can one do a my sub foo is parsed? or only macros? or "is parsed" implicitly creates a macro which calls the sub foo. <evil grin> | 00:45 | |
| TimToady | if you say sub rather than macro, the compiler is unlikely to expect an AST back from it, and will probably just plug it in there like a sub that merely has a strange syntax but returns an ordinary result | 00:48 | |
| which is more or less what the + in $a + $b is doing | 00:49 | ||
| it's just a strange syntax for infix:<+>($a,$b) | 00:50 | ||
| mncharity | true (so the earlier macro examples probably needed a lot more {{{}}} or ""'s), so we're back to sub foo() is parsed(token...) can indeed create a new lexical scoped token in the current language, and not just macro foo's? | 00:51 | |
| hmm. re "back too", I guess we always were there. /me got confused. | 00:52 | ||
| TimToady | and infix:<foo> doesn't (by and large) have to say how it's parsed because of how it defaults to just adding it as part of the LTM matching under <infix> matching | 00:54 | |
| unless you want to tweak the prec/assoc | |||
| but that doesn't change the parsing of the sym itself | |||
| only its relationships | 00:55 | ||
| mncharity | so long term, do most of the token decls in STD.pm go away, and become artifacts of Prelude declarations like multi sub infix:<+>(Number $a,Number $b) is parsed(token infix:<+>{'+'}){Internals::plus($a,$b)} ? | 00:56 | |
| TimToady | I don't think they go away. is parsed is kinda klunky | 00:57 | |
| mncharity | ah, ok. don't, but could. | ||
| TimToady | syntactically, these operators are in the grammar, not the prelude, and the compiler may do different things to them in different scopes depending on the candidate list | 00:58 | |
| where "my only sub infix:<+>" cuts that candidate list way down :) | |||
| mncharity | lol | 00:59 | |
| oky, sooo, where does that leave us... | |||
| TimToady | the compiler *knows* locally that infix + means infix:<+>, but it doesn't know what that means semantically without a lexical context, of which prelude is just the outermost | 01:00 | |
| or firstmost, depending on how you look at it | 01:01 | ||
| mncharity | oh, right. re using :sym's precence to toggle behavior. /me imitates 'bill the cat' blechhh. | ||
|
01:02
lyokato_ joined
|
|||
| TimToady | o_O | 01:02 | |
| mncharity | *presence | ||
| re eyes, lol | |||
| re "so this might actually be a fundamental difference between the user-oriented name infix:<+> and the grammar-oriented name infix:sym<+>" | 01:03 | ||
| hmm. though defining a lexical mumble:foo{'foo'} may not actually be the same as saying mumble:sym<foo>{<sym>}, because category:mumble may have a sym-tweaking proto. | 01:06 | ||
| ouch. :/ | |||
| ah well. | 01:07 | ||
| TimToady | Doctor, it hurts when I do this!!! | ||
| mncharity | yeah | ||
| TimToady | doubtless there will be a continued process of negotiation over what actually makes sense and what doesn't among the various implementations | ||
| and we can always invoke the Langauge Designer's Safety Valve: "if you do this, it is erroneous" | 01:08 | ||
| which I learned from Ada | |||
| mncharity | which brings us back to achieving implementations... | 01:09 | |
| re Ada, fun spec. should add it to my reread sometime list. | |||
| TimToady | wonderful category of potentially silent errors that are the user's fault, not the language designer's fault. :) | ||
| mncharity | lol :) | 01:10 | |
| TimToady | basically, we can't think how a compiler would warn you that you're making this mistake, so just don't. | ||
| just put one into the specs today | |||
| It is erroneous to make use of any side effects of reification, such as movement of a file pointer, since different implementations may have different batch semantics, and in any case the unreified part of the list already "belongs" to the array. | 01:12 | ||
| Happy Language Designer Syndrome | |||
| mncharity | ok. let's see... my course of development seems to fork on how soon kp6 code can be pushed through gimme5p, and on whether the parse happens quickly. | ||
| Syndrome? | |||
| Happy Language Designer, Clearly Informed User :) | 01:13 | ||
| TimToady | doesn't have to be quickly, just fast enough to bootstrap effectively. :) | 01:15 | |
| mncharity | except for those "type inference error X means your code, somehow, emergently achieved property Y, which the type checker can't support. we can only suggest you make random function-preserving mutations of your code, in the desperate hope that property Y goes away at some point". | ||
| 'bootstrap effectively' => writing lots of code => edit-compile-test cycle time is, after bugginess, of prime interest. | 01:16 | ||
|
01:17
dduncan joined
|
|||
| TimToady | it should fill out one of those little logic diagrams for the user like you use to solve those "Murphy was knifed by someone whose tie wasn't red in a room adjacent to the library." puzzle | 01:17 | |
| I don't mind speedy either. after waiting for pugs to compile metholated STD (2 minutes!), p5 does pretty good at about half a second on gimme5's output | 01:19 | ||
| and it felt pretty zippy on the parsing too once LTM got going pretty good | |||
| but I admit my test case was very small. :) | |||
| nice thing about LTM is that it avoids so many false starts | 01:20 | ||
| mncharity | hmm... /me goes to check 3*3*3*3... repeated 1000 times. | ||
| TimToady | so my guess is that it will probably beat current PGE in performance, if all the method calls don't eat us alive | 01:21 | |
| 'course, depends on how early or late pge hits the correct rule in the | alternations... | 01:22 | ||
| 'course, there's also the problem that it's spewing millions of lines of diagnostic output to stderr, which may be unbuffered... | 01:28 | ||
| also, if the LTM is failing, it fails over to the slow approach, which certainly won't beat pge | 01:29 | ||
| mncharity | hmm. STD5 dislikes "3+\n4;" as input. | ||
| TimToady | unv probably | 01:30 | |
| problem I mentioned earlier | |||
| though as I say, my copy varies | 01:31 | ||
| because I was scrabbling around with Match objects while missing 40% of my blood... | |||
| and it shows... | |||
| well, gotta go to dinner, wife picking me up in a minute or three | 01:32 | ||
| later & # will backlog of course | 01:33 | ||
| mncharity | with 3+3+...3; as input, | ||
| sorry for getting distracted :/ | |||
| I'm seeing about 2.5 instances of "3+" per second. it seems to be dropping with size. eg, 80 instances took 26 sec. | 01:34 | ||
| oh, wait. increasing, not dropping. that's up to 3.0 instances per sec. | 01:35 | ||
|
01:36
ntgrl joined
|
|||
| mncharity | perhaps the slow approach you mentioned. | 01:39 | |
| 100 gave a 2.5/s again. so seems linear, with the 3.0 being noise. | 01:40 | ||
|
01:41
dduncan left
|
|||
| mncharity | re 'probably beat current PGE'... but current PGE is painfully slow... :/ | 01:42 | |
| which brings us back to extracting the content of STD.pm in a form in which it can be more easily massaged into assorted representations, directly executable (like gimme5's) or for parser generaters (dparse?, p5 lexed bison?). trying to create something usable for a not-small volume of p6 hacking. | 01:47 | ||
| s/current PGE is painfully slow/current PGE*based parsing of p6* is painfully slow/ | 01:51 | ||
| that can sometimes be a trival "oops, missed a commit and spending lots of time backtracking", rather than a "real" problem. | 01:53 | ||
| yipes. end of day. good night all & | |||
|
01:58
drbean joined
02:11
TimToady joined
02:24
BinGOs_ joined
02:29
aindilis joined
03:19
diakopter joined
03:21
stevan__ joined
03:38
ChanServ sets mode: +o diakopter,
diakopter sets mode: +o TimToady
03:39
diakopter sets mode: -o diakopter
|
|||
| spinclad | TimToady: S03:664: s/a list all/a list of all/ | 04:16 | |
| and S03:1578: i don't recognize the C<:)> operator? :) | 04:17 | ||
| (oh, wait. mncharity pointed out it's a new statement terminator :) ) | 04:18 | ||
|
04:50
stevan_ joined
05:19
bbkr__ joined
05:31
literal joined,
masak joined
05:43
drbean joined
05:59
kst` joined
06:06
devogon joined
07:01
penk joined
07:08
IllvilJa joined
07:43
Aankhen`` joined
07:50
drbean joined
07:57
Caelum joined
08:29
pmurias joined
08:48
cognominal_ joined
09:18
avar joined
09:20
literal_ joined
09:39
rindolf joined
09:40
drbean joined
10:16
Maddingue joined
10:22
devogon joined
10:34
ruoso joined
10:37
chris2 joined
11:05
devogon joined
11:29
lisppaste3 joined
11:40
Foke2 joined
11:51
devogon joined
12:26
masak joined
12:29
ting joined
12:44
clintongormley joined
12:46
chris2 joined
12:52
LazyJim joined
13:07
pmurias joined
13:13
thierry_M joined
13:24
devogon left
13:51
ThierryM joined,
Chillance joined
13:52
spinclad joined
14:03
FurnaceBoy joined
14:23
clintongormley left
14:29
Foke2 joined,
TJCRI joined
14:46
ikeda joined
14:57
rdice joined
15:01
TJCRI joined
|
|||
| pugs_svnbot | r20130 | putter++ | [misc/STD_red] Progress towards parsing elf_one.p6. infix:<.> isn't working, and classes need a trailing ; . | 15:04 | |
| r20130 | putter++ | STD_red_run now defaults to ruby 1.9 (but 1.8 still works), so <ws> can use look-behind. Parse time on the modified elf_one.p6 goes from 17 sec to 1.7 sec. ruby-prof++ kcachegrind++ | |||
| diff: dev.pugscode.org/changeset/20130 | |||
| lambdabot | Title: Changeset 20130 - Pugs - Trac | ||
| pugs_svnbot | r20131 | putter++ | [misc/STD_red] Fixed ruby 1.8 support. And tweaked it (+25% speedup - but still 13 sec, vs 2 sec on ruby 1.9). | 15:25 | |
| diff: dev.pugscode.org/changeset/20131 | |||
| lambdabot | Title: Changeset 20131 - Pugs - Trac | ||
|
15:29
b_jonas joined
15:55
kanru joined
16:17
justatheory joined
16:33
tobeya joined
16:38
barney joined
18:06
rindolf joined
18:22
Psyche^ joined
18:44
avar joined
19:02
soapyj joined
19:26
qmole joined
19:39
nothingmuch joined
20:03
cmarcelo joined
20:04
cmarcelo left
20:10
peeps[work] joined
20:51
pmurias joined
20:53
buubot joined
21:30
elmex joined
21:46
Limbic_Region joined
21:56
IRSeekBot joined
22:01
thoughtpolice joined
22:36
Moss23 joined
22:43
Helios- joined
23:12
meppl joined
23:19
jrockway joined
23:24
marmic joined
23:28
justatheory joined
23:41
marmic joined
23:50
Sergia joined
|
|||
| Sergia | Those of you familiar with me know that my investment advice through the course of our detachment has appreciated a stellar 45-50%. | 23:52 | |
|
23:54
Schwern joined
|
|||
| Sergia | NOTE that I expect the American dollar to depceciate down to 30 cents Canadian within the next 20 years. | 23:55 | |
| It is not enough to hold Canadian stocks trading on American indices. | 23:56 | ||
| You are not getting any currency exposure that way. | |||
| You need to buy them with Canadian dollars on the TSX to benefit from the long-term slide of the USD. | 23:57 | ||
| 20-40% of your portfolio ought to be the NASDAQ-100 from this point on. BUT the rest of your equity portfolio ought to be in Canadian stocks ON THE TSX. | |||
|
23:58
Sergia left
|
|||