Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2008-03-18

Perl 6 | Reference Documentation | Rakudo

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 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
00:02 TimToady yes, I tried statementlist the other day and ran into trouble, but it's probably a minor bug compared to the others
00:03 TimToady something was getting confused in unv
00:03 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:03 TimToady probably just a scalar/array deref foulup
00:05 TimToady induced by the fact that everything is done with lists but ratchet code usually just wants .[0]
00:06 TimToady yes, there are different DWIMs fighting there
00:07 TimToady but I'm mostly not considering macros here, but complete derived grammars
00:07 TimToady so mostly talking about DSL's her
00:07 TimToady e
00:07 mncharity lol # "there are different DWIMs fighting there"
00:09 TimToady minor tweaks with macros are specced to be more like "assume it's the same as standard p6"
00:10 TimToady so this might actually be a fundamental difference between the user-oriented name infix:<+> and the grammar-oriented name infix:sym<+>
00:10 TimToady and, in fact, within a grammar both of those are possible, and mean two different things
00:10 mncharity ?!?
00:11 TimToady infix:<+> is the name of my current infix + operator, which has little to do with the language I'm parsing
00:11 TimToady infix:sym<+> is not the name of an operator, it's the name of a rule
00:11 TimToady however, we can infer that the eventual user-visible name of the resulting operator is likely to be infix:<+>
00:12 TimToady but that's what its name will be in the user's code, not in our code.
00:12 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').
00:12 TimToady might just be explicit delegation in that case
00:12 TimToady or just using the same --> Mumble
00:13 PerlJam mncharity: speaking as a "user", I'd *expect* precedence and associativity to be the same as whatever I happen to call "normal"  :)
00:13 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:14 TimToady and, of course, you can expect all you like, but you can also be wrong  :)
00:14 mncharity or at APL ;)
00:15 TimToady which is a recursive acronym for APL's Precedent-Less
00:15 mncharity oy
00:15 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.
00:16 PerlJam (And when APL is the baseline ... etc)
00:16 mncharity might be a place for one of those huffman encoding of "do you really want to do this?".
00:17 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 #perl6
00:17 TimToady huffman coding is *precisely* what APL lacks :)
00:18 TimToady which is, of course, why it looks like noise
00:18 PerlJam you could also say that everything in APL is huffman coded :)
00:18 TimToady and you could be wrong again... :)
00:19 PerlJam I reject your reality and substitute my own!  ;)
00:19 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.
00:20 TimToady PerlJam: you are Officially Allowed
00:21 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
00:22 TimToady I believe foo would default to + precedence
00:22 mncharity g'night meppl
00:23 meppl ;)
00:24 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
00:26 mncharity re default + prec, ok
00:29 TimToady except that token is really defining a method on the current class, not the current language
00:29 TimToady possibly it could dwym from noticing that you left out the "sym", but that's kinda subtle
00:30 TimToady and there doesn't seem to be much reason not to use a macro instead, so that you actually supply some semantics :)
00:30 mncharity my sub infix:<foo>($a,$b) is token {}
00:31 TimToady is parsed(token {...}) {42} might do
00:31 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:31 TimToady macros are always lexically scoped
00:32 TimToady references to names like infix:<foo> imply macro binding of that name to a lexical scope
00:32 TimToady regardless of the actual scope of the declaration
00:32 TimToady imported macros are likewise always lexical
00:33 TimToady all grammatical tweaks are lexical, always
00:35 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 mncharity my macro infix:<+>($a,$b) is parsed(token {'+'}) has :precedence<42>{OUTER::infix<+>($a,$b)};
00:37 TimToady there are no absolute prec levels visible to the user, so you're talking something like "is looser", but basically yes
00:37 TimToady and precedence levels are strings rather than numbers in p6
00:37 TimToady so we can do the surreal precedence ad infinitum
00:38 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
00:40 TimToady an anonymous token is really just equiv to a /.../
00:41 TimToady well, with :sigspace:ratchet
00:41 TimToady er, just :ratchet
00:41 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 mncharity 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 ...
00:44 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:47 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:49 TimToady which is more or less what the + in $a + $b is doing
00:49 TimToady 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:52 mncharity hmm.  re "back too", I guess we always were there.  /me got confused.
00:53 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:53 TimToady unless you want to tweak the prec/assoc
00:54 TimToady but that doesn't change the parsing of the sym itself
00:54 TimToady 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:56 mncharity ah, ok.  don't, but could.
00:58 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 TimToady where "my only sub infix:<+>" cuts that candidate list way down :)
00:58 mncharity lol
00:58 mncharity oky, sooo, where does that leave us...
00:59 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 TimToady 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:01 lyokato_ joined #perl6
01:01 TimToady o_O
01:02 mncharity *presence
01:02 mncharity re eyes, lol
01:03 mncharity re "so this might actually be a fundamental difference between the user-oriented name infix:<+> and the grammar-oriented name infix:sym<+>"
01:05 mncharity 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 mncharity ouch. :/
01:06 mncharity ah well.
01:06 TimToady Doctor, it hurts when I do this!!!
01:06 mncharity yeah
01:07 TimToady doubtless there will be a continued process of negotiation over what actually makes sense and what doesn't among the various implementations
01:08 TimToady and we can always invoke the Langauge Designer's Safety Valve: "if you do this, it is erroneous"
01:08 TimToady which I learned from Ada
01:08 mncharity which brings us back to achieving implementations...
01:09 mncharity re Ada, fun spec.  should add it to my reread sometime list.
01:09 TimToady wonderful category of potentially silent errors that are the user's fault, not the language designer's fault.  :)
01:09 mncharity lol :)
01:09 TimToady basically, we can't think how a compiler would warn you that you're making this mistake, so just don't.
01:10 TimToady just put one into the specs today
01:11 TimToady 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 TimToady Happy Language Designer Syndrome
01:12 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.
01:12 mncharity Syndrome?
01:12 mncharity Happy Language Designer, Clearly Informed User :)
01:14 TimToady doesn't have to be quickly, just fast enough to bootstrap effectively. :)
01:14 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".
01:16 mncharity 'bootstrap effectively' => writing lots of code => edit-compile-test cycle time is, after bugginess, of prime interest.
01:16 dduncan joined #perl6
01:17 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:18 TimToady 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 TimToady and it felt pretty zippy on the parsing too once LTM got going pretty good
01:19 TimToady but I admit my test case was very small.  :)
01:19 TimToady 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.
01:20 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 TimToady 'course, depends on how early or late pge hits the correct rule in the | alternations...
01:27 TimToady 'course, there's also the problem that it's spewing millions of lines of diagnostic output to stderr, which may be unbuffered...
01:29 TimToady 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.
01:29 TimToady unv probably
01:30 TimToady problem I mentioned earlier
01:30 TimToady though as I say, my copy varies
01:30 TimToady because I was scrabbling around with Match objects while missing 40% of my blood...
01:31 TimToady and it shows...
01:31 TimToady well, gotta go to dinner, wife picking me up in a minute or three
01:32 TimToady later &  # will backlog of course
01:32 mncharity with  3+3+...3; as input,
01:32 mncharity sorry for getting distracted :/
01:34 mncharity 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:35 mncharity oh, wait.  increasing, not dropping.  that's up to 3.0 instances per sec.
01:36 ntgrl joined #perl6
01:38 mncharity perhaps the slow approach you mentioned.
01:40 mncharity 100 gave a 2.5/s again.  so seems linear, with the 3.0 being noise.
01:40 dduncan left #perl6
01:42 mncharity re 'probably beat current PGE'... but current PGE is painfully slow... :/
01:47 mncharity 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:51 mncharity s/current PGE is painfully slow/current PGE*based parsing of p6* is painfully slow/
01:52 mncharity that can sometimes be a trival  "oops, missed a commit and spending lots of time backtracking", rather than a "real" problem.
01:53 mncharity yipes.  end of day.  good night all &
01:57 drbean joined #perl6
02:11 TimToady joined #perl6
02:23 BinGOs_ joined #perl6
02:28 aindilis joined #perl6
03:18 diakopter joined #perl6
03:20 stevan__ joined #perl6
04:15 spinclad TimToady: S03:664:  s/a list all/a list of all/
04:16 spinclad and S03:1578:  i don't recognize the C<:)> operator?  :)
04:18 spinclad (oh, wait.  mncharity pointed out it's a new statement terminator :) )
04:49 stevan_ joined #perl6
05:18 bbkr__ joined #perl6
05:31 literal joined #perl6
05:31 masak joined #perl6
05:42 drbean joined #perl6
05:59 kst` joined #perl6
06:05 devogon joined #perl6
07:00 penk joined #perl6
07:08 IllvilJa joined #perl6
07:42 Aankhen`` joined #perl6
07:50 drbean joined #perl6
07:56 Caelum joined #perl6
08:28 pmurias joined #perl6
08:48 cognominal_ joined #perl6
09:17 avar joined #perl6
09:19 literal_ joined #perl6
09:38 rindolf joined #perl6
09:39 drbean joined #perl6
10:16 Maddingue joined #perl6
10:21 devogon joined #perl6
10:33 ruoso joined #perl6
10:37 chris2 joined #perl6
11:04 devogon joined #perl6
11:28 lisppaste3 joined #perl6
11:39 Foke2 joined #perl6
11:50 devogon joined #perl6
12:25 masak joined #perl6
12:28 ting joined #perl6
12:44 clintongormley joined #perl6
12:45 chris2 joined #perl6
12:51 LazyJim joined #perl6
13:06 pmurias joined #perl6
13:12 thierry_M joined #perl6
13:24 devogon left #perl6
13:50 ThierryM joined #perl6
13:50 Chillance joined #perl6
13:51 spinclad joined #perl6
14:02 FurnaceBoy joined #perl6
14:22 clintongormley left #perl6
14:28 Foke2 joined #perl6
14:29 TJCRI joined #perl6
14:45 ikeda joined #perl6
14:56 rdice joined #perl6
15:01 TJCRI joined #perl6
15:03 pugs_svnbot r20130 | putter++ | [misc/STD_red] Progress towards parsing elf_one.p6.  infix:<.> isn't working, and classes need a trailing ; .
15:03 pugs_svnbot 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++
15:03 pugs_svnbot diff: http://dev.pugscode.org/changeset/20130
15:03 lambdabot Title: Changeset 20130 - Pugs - Trac
15:24 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:24 pugs_svnbot diff: http://dev.pugscode.org/changeset/20131
15:24 lambdabot Title: Changeset 20131 - Pugs - Trac
15:29 b_jonas joined #perl6
15:54 kanru joined #perl6
16:17 justatheory joined #perl6
16:33 tobeya joined #perl6
16:38 barney joined #perl6
18:05 rindolf joined #perl6
18:21 Psyche^ joined #perl6
18:43 avar joined #perl6
19:02 soapyj joined #perl6
19:26 qmole joined #perl6
19:38 nothingmuch joined #perl6
20:03 cmarcelo joined #perl6
20:03 cmarcelo left #perl6
20:09 peeps[work] joined #perl6
20:50 pmurias joined #perl6
20:52 buubot joined #perl6
21:29 elmex joined #perl6
21:45 Limbic_Region joined #perl6
21:55 IRSeekBot joined #perl6
22:01 thoughtpolice joined #perl6
22:35 Moss23 joined #perl6
22:42 Helios- joined #perl6
23:11 meppl joined #perl6
23:19 jrockway joined #perl6
23:23 marmic joined #perl6
23:28 justatheory joined #perl6
23:40 marmic joined #perl6
23:50 Sergia joined #perl6
23:53 Schwern joined #perl6
23:58 Sergia left #perl6

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo