pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog: irc.pugscode.org/
Set by Tene on 29 July 2008.
00:36 Alias_ joined 00:43 justatheory left 00:49 jferrero left 00:50 silug joined 00:56 benzo left 01:08 eternaleye joined
pugs_svn r22549 | lwall++ | [assign.t] missing semicolons 01:08
01:11 alester left
pugs_svn r22550 | lwall++ | [STD] there is no infix:<is> (was hiding missing semicolons in assign.t) 01:24
r22550 | lwall++ | [viv] much improved typology of EXPR asts (and doesn't lose nested ops)
01:30 alanhaggai joined 01:32 BinGOs left 01:37 PZt left, BinGOs joined 01:41 ab5tract left 01:49 hercynium_ joined 01:52 PZt joined 02:05 alester joined 02:08 felipe left 02:09 zostay_ is now known as zostay 02:15 eternaleye left 02:17 Limbic_Region left 02:23 eternaleye joined 02:49 agentzh left, agentzh joined
pugs_svn r22551 | lwall++ | [basic.t] default expression must come after traits 02:50
r22552 | lwall++ | [viv] autogenerate VAST packages as needed 02:52
03:10 ab5tract joined 03:11 jhorwitz left 03:32 felipe joined, alanhaggai left 03:35 jfredett left 03:44 agentzh left, agentzh joined
pugs_svn r22553 | lwall++ | [viv] can now reconstruct the p6 from the ast for simple expressions 04:17
04:56 masak joined 05:05 Patterner left 05:08 Psyche^ joined, Psyche^ is now known as Patterner 05:14 |Jedai| joined 05:21 Bzek joined 05:28 |Jedai| left 05:29 |Jedai| joined 06:09 BinGOs_ joined 06:11 agentzh left, agentzh joined 06:22 BinGOs left 06:30 ashizawa joined 06:44 alester left 06:47 BinGOs_ is now known as BinGOs 06:49 alester joined, alester left 06:59 iblechbot joined 07:00 alester joined 07:05 penk joined 07:09 agentzh left, agentzh joined 07:12 sri_work joined 07:13 agentzh left 07:16 alester left 07:17 agentzh joined 07:23 viklund joined 07:29 masak left 07:36 ab5tract left 07:46 Alias_ left 07:57 zamolxes left 08:04 cosimo joined 08:07 BinGOs_ joined 08:09 BinGOs_ left 08:15 elmex joined 08:21 BinGOs left 08:27 jferrero joined 08:54 BinGOs joined 09:17 renormalist joined 09:37 tomyan joined
moritz_ std: class A { sub :foo { say bar }; }; 09:45
lambdabot moritz_: You have 1 new message. '/msg lambdabot @messages' to read it.
p6eval std 22553: OUTPUT[Unknown routines:␤ bar called at 1 ␤parsed␤]
moritz_ @massages
lambdabot azawawi said 11h 46m 54s ago: any-list.pir p5chop and p5chomp is running all tests now. Patches are on RT. Thanks.
09:55 meppl joined 10:06 Bzek left 10:18 Bzek joined 10:21 ruoso left 10:30 xinming_ joined 10:31 xinming left 10:33 kanru left 10:38 xinming joined, Ontolog joined 10:39 xinming_ left 10:47 xinming_ joined, xinming_ left 10:48 dmq joined, dmq left 11:00 [particle] joined, ruoso joined 11:03 Ontolog left, xinming left 11:04 xinming joined
moritz_ @tell azawawi thanks for the patch. However (as the others that modify self) I'll wait wih applying until the lexical issues are sorted out 11:06
lambdabot Consider it noted.
11:07 penk left 11:12 [particle-split] left 11:14 xinming left, xinming joined
pugs_svn r22554 | ruoso++ | [smop] small bugfix in native bool was causing unexpected behavior 11:30
ruoso er... actually it wasn't the bugfix that was causing the unexpcted behavior... *sigh* 11:31
11:36 alanhaggai joined 11:48 kanru joined 11:58 meppl left 12:01 xinming left 12:06 bjakb joined
bjakb hello? 12:09
moritz_ hi
12:10 xinming joined
bjakb I have a problem with the Pugs installation, can somebody might help me? 12:12
moritz_ I can try
but only if I know what your problem is
12:14 bjakb2 joined
bjakb sorry I have a problem with my irc client could you please repeat your answer? 12:14
moritz_ the logs are at irc.pugscode.org 12:15
in short "I can try"
12:17 bjakb left
bjakb2 OK, I'm following the installation instructions of pugs 12:19
12:19 kanru left
moritz_ which instructions? 12:19
bjakb2 that is the best to install it with cabal
'cabal update'
'cabal install Pugs'
12:19 kanru joined
moritz_ ok 12:20
bjakb2 to be able to do that you have to install a few haskell packages - which i did install
12:20 Bzek left
bjakb2 I was also able to run the two mentioned cabal commands 12:21
the installation went through without any errors
But, at the end, I cannot run pugs
I can also not find any pugs binary 12:22
moritz_ the binary will be in ~/.cabal/ somewhere 12:23
probably ~/.cabal/Pugs/bin/pugs or something along these lines
which OS are you on?
12:26 Ontolog joined
bjakb2 say 'hello' :-) 12:28
12:29 ashizawa left
bjakb2 moritz: the binary was indeed in the ~/.cabal directory - thanks 12:29
moritz_ bjakb2: you're welcome 12:30
12:32 bjakbh joined
bjakb2 the next thing I want to try is to compile perl6 code into perl5 - that sounds interesting 12:34
moritz_ I don't think that's properly implemented in pugs 12:35
elf does it, though
ruoso pugs: module Foo { sub bar { baz() } }; &Foo::baz := sub { say 1 }; Foo::bar()
p6eval pugs: OUTPUT[1␤]
bjakbh elf? - never heard of that 12:36
moritz_ elf: say "hi";
p6eval elf 22554: OUTPUT[hi␤]
12:36 bjakb2 left
moritz_ see also perl.net.au/wiki/Elf 12:37
lambdabot Title: Elf - PerlNet
ruoso pugs: module Foo { sub bar { our $foo = 1; }; sub baz { say $foo } }; Foo::bar(); Foo::baz(); 12:38
p6eval pugs: OUTPUT[*** ␤ Unexpected " }"␤ expecting "::"␤ Variable "$foo" requires predeclaration or explicit package name␤ at /tmp/Bwbo2aprAs line 1, column 59␤]
ruoso pugs: module Foo { sub bar { our &foo := sub { say 1 } }; sub baz { say foo() } }; Foo::bar(); Foo::baz(); 12:39
p6eval pugs: OUTPUT[*** Cannot use Undef as a Code object␤ at /tmp/vScVoZWa3S line 1, column 67-73␤]
ruoso pugs: module Foo { sub bar { our sub foo { say 1 } }; sub baz { foo() } }; Foo::baz(); 12:43
p6eval pugs: OUTPUT[1␤]
12:43 bjakbh left
ruoso that means one of two things: 12:44
1) The package variables are visible as if they were declared as "our" even if there isn't such a declaration...
2) sub dispatch sees if the current package CANDO that after looking in the lexical scope 12:45
moritz_ ruoso: 'our sub' is the same as 'sub' 12:46
ruoso but the local name is installed inside that scope only...
12:48 bjak joined
moritz_ hurm 12:48
ruoso which probably means that the option 2 is the correct one 12:49
12:49 alester joined
ruoso sub dispatch is 'no strict' 12:49
it falls back to global lookup (by global meaning looking up in the package, and not only on the lexical scope) 12:50
pugs: $Foo::bar = 1; module Foo { sub foo { say $bar } }; Foo::foo(); 12:51
p6eval pugs: OUTPUT[*** ␤ Unexpected " }"␤ expecting "::"␤ Variable "$bar" requires predeclaration or explicit package name␤ at /tmp/uEICR3JQar line 1, column 47␤]
ruoso pugs: &Foo::bar = sub { 1 }; module Foo { sub foo { say bar() } }; Foo::foo();
p6eval pugs: OUTPUT[*** Can't modify constant item: VStr "MkCode {isMulti = True, subName = \"&\", subType = SubPrim, subOuterPads = [], subInnerPad = MkPad (padToList []), subPackage = , subAssoc = AIrrelevantToParsing, subParams = [], subBindings = [], subSlurpLimit = [], subReturns = (mkType \"An...
ruoso pugs: &Foo::bar := sub { 1 }; module Foo { sub foo { say bar() } }; Foo::foo();
p6eval pugs: OUTPUT[1␤]
moritz_ ruoso: re sub lookup is 'no strict', that's my feeling as well 12:52
ruoso pugs: &Foo::bar := sub { 1 }; module Foo { sub foo { say &bar.() } }; Foo::foo(); 12:53
p6eval pugs: OUTPUT[*** ␤ Unexpected ".()"␤ expecting "::" or signature value␤ Variable "&bar" requires predeclaration or explicit package name␤ at /tmp/pstwoiEGm4 line 1, column 56␤] 12:54
ruoso indeed... it looks like so...
12:55 bjak left
ruoso alright... so it looks that sub dispatch does: 12:56
1) looks for all variants from the lexical scope and from package CANDO
12:56 bjakb joined
ruoso (it traverses itself the lexical scope, so a inner declaration doesn't mask the outer declaration) 12:56
greps for the ACCEPTS 12:57
moritz_ (CANDO sounds like a reactor from a nuclear power plant; but I probably confuse that with CANDU)
12:57 alester left
ruoso sorts using a "pluggable disambiguation code" 12:57
and invoke the first
and we leave a cache of all variants in the innermost declaration as the room for optimizations 12:58
moritz_ sounds sane
12:59 Alias_ joined 13:01 Alias__ joined 13:02 z80ASM joined, xinming left 13:06 Alias_ left 13:22 z80ASM left 13:27 pmurias joined 13:28 BinGOs left, iblechbot left 13:30 jferrero left 13:31 pmurias_ joined, pmurias_ left
pmurias is it possible to add multi variants at runtime? 13:31
moritz_ yes
pmurias how? ;) 13:33
moritz_ proto foo; eval 'sub foo($x) { $x*2 }'; say foo(2);
pmurias perl6: multi foo(1) {say 3};foo(1); 13:35
p6eval pugs: OUTPUT[*** ␤ Unexpected "1"␤ expecting formal parameter or ")"␤ at /tmp/yOHlPNDb3K line 1, column 11␤]
..elf 22554: OUTPUT[No viable candidate for call to multimethod foo(#) at (eval 121) line 4␤ at ./elf_f line 3861␤]
..rakudo 31827: OUTPUT[Statement not terminated properly at line 1, near "{say 3};fo"␤␤current instr.: 'parrot;PGE::Util;die' pc 119 (runtime/parrot/library/PGE/Util.pir:82)␤]
pmurias perl6: multi foo(Int $a) {say 3};foo(1); 13:36
p6eval elf 22554, pugs, rakudo 31827: OUTPUT[3␤]
13:36 BinGOs joined
moritz_ perl6: multi foo(Int $x) { say "Int" }; eval 'multi foo(Str $x) { say "Str" }'; foo(1); foo("bar"); 13:37
p6eval elf 22554, rakudo 31827: OUTPUT[Int␤Str␤]
..pugs: OUTPUT[Int␤Int␤]
moritz_ elf++
rakudo++
pmurias is it possible to close multis?
like use multi :closed?
moritz_ dunno
don't think it makes much sense 13:38
pmurias why?
moritz_ because multis are one of teh central mechanism to get extensibility into Perl 6 13:39
ruoso www.perlfoundation.org/perl6/index....b_dispatch
lambdabot Title: SMOP Multi Sub Dispatch / Perl 6, tinyurl.com/43fhyt
13:39 Lorn joined
pmurias ruoso: hi 13:40
ruoso hi pmurias
pmurias ruoso: withought variant disambiguation multis wouldn't be more powerfull then normal methods 13:42
ruoso indeed 13:43
13:43 BinGOs left
ruoso pmurias, refresh the wiki page ;) 13:43
13:43 renormalist left 13:44 BinGOs joined
pmurias we also need to check for ambiguity 13:45
that is there need to be 1 topmost item
ruoso pmurias, I think the disambiguation code would 'fail' in that case 13:46
pmurias ok 13:47
13:49 xinming joined
pmurias ruoso: can i remove the nasty adjective 13:50
?
13:50 abra joined
ruoso yeah... :) 13:50
moritz_ ;)
pmurias got to run to eat something and catch a train 13:54
&
13:54 pmurias left 13:58 alester joined 14:01 kanru left, xinming left 14:02 viklund left 14:09 [particle]1 joined 14:14 iblechbot joined 14:27 [particle] left 14:32 eternaleye left 14:37 sscaffidi joined, coke joined 15:02 z80ASM joined
rakudo_svn r31829 | pmichaud++ | [rakudo]: spectest-progress.csv update: 205 files, 4366 passing, 11 failing 15:07
15:11 sscaffidi left 15:12 hercynium_ left 15:16 justatheory joined 15:20 mj41_ left 15:21 ab5tract joined 15:22 z80ASM left 15:26 mj41 joined 15:27 alanhaggai left 15:29 z80ASM joined 15:32 lisppaste3 left 15:38 xinming_ joined
ruoso TimToady, if you have some time, could you please take a look at www.perlfoundation.org/perl6/index....b_dispatch 15:42
lambdabot Title: SMOP Multi Sub Dispatch / Perl 6, tinyurl.com/43fhyt
15:43 Exodist joined 15:46 lisppaste3 joined
TimToady I never have some time :) 15:47
unless you count negative time...
PerlJam ruoso: I just looked at it and your examples look single-dispatchy 15:48
ruoso PerlJam, what do you mean? 15:49
TimToady thinking about lexical CANDO now :) 15:50
15:51 kanru joined
TimToady as someone mentioned earlier, you need to deal with ambiguities too 15:52
15:52 jhorwitz joined
TimToady and there are probably a few other things from S12:876 that will need to be considered eventually 15:55
though a lot of it can be swept under the carpet of "sorting"
but it basically looks sane 15:56
ruoso lexical CANDO?
TimToady lexical autoloading of some sort or other 15:57
probably only dynamic response, not install new symbols
ruoso ah... I see...
it seems heavyweight to call CANDO for every lexical scope in the tree 15:58
TimToady but it would be nice to intercept the query on the way outward
15:58 xinming_ left, xinming_ joined
ruoso TimToady, probably installing symbols at runtime is better 15:58
instead of doing the AUTOLOAD way
TimToady well, the presence of a CANDO in an outer lexical scope would basically pessimize the ability to know what a name means at compile time 15:59
but that can be known at compile time :) 16:00
ruoso oh... I see... you're actually thinking about CANDO not being in the package at all
TimToady that's what I mean by "lexical"
coke has anyone written a rule to english translator?
lambdabot coke: You have 1 new message. '/msg lambdabot @messages' to read it.
ruoso I initially read that as "additionally in the lexical scope" 16:01
TimToady but also potentially in the package, as it is currently
ruoso ok... 16:02
so it basically means adding another step...
TimToady anyway, just a thought, doesn't even need a bit in the lexical scope unless you actually find a my CANDO at compile time
ruoso hmm... I see... the presence of a CANDO would generate a degenerated lexical scope object 16:03
TimToady which would know to treat the CANDO as *
it's probably not worth worrying about right now 16:04
ruoso yeah... it looks like something that can be just plugged in
TimToady can be retrofitted to the compiler if we decide to do it later
16:04 alanhaggai joined 16:05 z80ASM left 16:07 z80ASM joined
diakopte1 moritz_: you pinged 16:08
16:09 diakopte1 is now known as diakopter_o, diakopter_o is now known as diakopter
diakopter moritz_: you pang 16:10
moritz_ diakopter: yes, about the SVN::Web stuff, but Infinioid helped me to sort it out in the mean time
diakopter that guy is very resourceful 16:11
what was wrong with it
moritz_ it died on every request :/
diakopter what caused that symptom
moritz_ assertion failure in some svn libs... changing a path from '/' to '' helped 16:12
16:16 exodist_ joined, Exodist left, exodist_ is now known as Exodist
pugs_svn r22555 | moritz++ | [t/spec] unfudge passing tests in split-simple.t 16:17
16:31 [particle] joined
pugs_svn r22556 | moritz++ | [t/spec] more tests for unchanged source string in transliteration tests. 16:34
16:36 z80ASM left 16:43 Alias__ left 16:47 [particle]1 left 16:56 cosimo left 17:07 xinming_ left, xinming joined 17:13 mberends joined 17:17 apeiron left 17:18 jferrero joined 17:19 apeiron joined 17:20 abra left 17:28 raiph joined, raiph left 17:30 jan_ left 17:32 jan_ joined, coke left 17:33 meppl joined 17:42 smg left 17:46 sri_work left
rakudo_svn r31835 | moritz++ | [rakudo] workaround for RT #59730 by cjfields++ (Str.trans with closures) 18:06
pugs_svn r22557 | moritz++ | [t/spec] unfduge passing test, cjfields++ 18:07
18:11 pyrimidine joined 18:12 Exodist left 18:15 Exodist joined 18:20 abra joined
pugs_svn r22558 | moritz++ | [t/spec] added a test file for infix:<where> 18:33
18:33 abra left
moritz_ I would appreciate it if somebody could take a look at r22558, not sure I fully understood that operator 18:37
18:39 Southen_ joined 18:56 Southen left 18:58 ruoso left 19:02 alanhaggai left 19:03 zamolxes joined, tomyan left 19:06 pyrimidine left 19:12 smg joined 19:15 [particle1 joined 19:19 [particle1 left
TimToady moritz_: well, I don't know if I'm somebody, but it looks okay to me. 19:36
moritz_ TimToady: you're somebody enough to count in this one ;)
TimToady it's a bit subtle that the closures doing appending are returning true 19:37
moritz_ subtle, but intended ;)
TimToady well, but you could say $x ~= 'b'; True to be explicit
moritz_ right 19:38
TimToady just thinking of the Gentle Reader
btw, thanks for all your spectacular work on the test suite 19:39
moritz_ my pleasure 19:40
TimToady what's your opinion of changing all the is $a,$b to ok $a eqv $b?
or maybe even making the builtin ok an infix?
so you could say $a eqv $b ok "message" 19:41
moritz_ wait a sec...
TimToady well, would look better with ok lined up with tabs
moritz_ I like "ok" up front 19:42
TimToady or maybe the builtin tests could be $a eqv $b OK "message";
well I like what you're testing up front :)
and I don't like commas 19:43
moritz_ why do you want to make them all operators?
TimToady esp when they can be confused with precedence
moritz_ re all is $a, $b to ok $a eqv $b, I think many comparisons should stay string comparisons
TimToady well, that's the trouble, people are using them both ways, so ok would make it explicit 19:44
moritz_ right
TimToady anyway, I'm just trying to think of a construct that reads more like "and", except it has to pay attention to the right side all the time 19:45
fullermd "with"?
moritz_ well, the infix:<where> is rather confusing when read as english
TimToady in fact, ok doesn't work well because it's the wrong valence, and because it disappears too easily in the middle
moritz_ that's why you suggested OK, right? 19:46
as all caps
TimToady yes, but also to hide the builtin a little better, since there are other functions too
not that anyone is going to want to define infix:<DIES_OK>, but you never know... :) 19:47
moritz_ anyway, I think that explicit comparison semantics are good, but I somehow fear all the work that it will make
TimToady another reason I want to get rid of "is" is because it's overloaded in Perl 6
moritz_ right
TimToady but I know how to work around that 19:48
(though it's ugly)
19:48 [particle]1 joined
TimToady still, I'd rather not have the cognitive dissonance 19:48
and the is test is horribly imprecise
well, one argument (a weak one) for keeping a verb out front is that you could more easily make macros that way for evalish arguments 19:49
but of course that's awfully fancy 19:50
moritz_ right now I'd rather rewrite all is() tests to ok() than rewriting everything to infix operators; but I don't see how early implementations can give good summaries of failing tests
TimToady you mean with an infix?
don't see a problem with ok()
moritz_ ok $a eq $b would just say "not ok", whereas is() can tell you what's expected and what you got 19:51
TimToady ah
moritz_ so unless you have a very clever macro you loose the information too early
TimToady I wonder how easy it would be to allow parameter properties that capture the text of the parameter, not because you want to reprocess the text like a macro, but simply for documentation 19:53
could write assert() using that too
as long as the original program is available as a string, and we know where the argument started and stopped, it could be done. 19:54
moritz_ but how does that help with error reporting?
TimToady right, still doesn't give you the two values...drat... 19:55
moritz_ an assert($x eq $y) would know '$x eq $y' and true/false
19:55 jferrero left
moritz_ unless it would peek into the AST of its arguments, which is really non-trivial 19:58
TimToady maybe there wants to be a metaoperator, as long as we're dreaming
because you can change is to iseq, iseqv, but is== is not good
don't really need to deal with AST, I think 19:59
moritz_ so would you write '$x iseq $y OK "message";'? 20:00
that'd be confusing, to say the least 20:01
TimToady something like that, though that's kind of ugly
but something that would automatically capture $x, $y, '$x eq $y', and eval '$x eq $y' 20:02
well, and maybe 'eq'
moritz_ still sounds like too much magic for basic implementations 20:03
TimToady could always hardwire 'ok' into the grammar too 20:04
as long as we're building in test ops, that would not be terribly difficult 20:05
after all, all the built-in constructs are essentially macros 20:06
and the utility of this might well outweigh the futility :)
moritz_ isn't entirely convinced 20:07
TimToady people weren't entirely convinced by fudge either :) 20:08
moritz_ aye ;)
TimToady anyway, if we set up the syntax such that a stupid ok could work without macroizing, but you just get less info, that's probably cool
then if the grammar redirects to a smart ok, we just get more info 20:09
moritz_ maybe you could even convince viv to rewrite the tests automatically 20:10
TimToady well, that'd be at the parse tree or ast level, but sure, that's about the right level to recognize the structure of the first argument 20:11
on the other hand, if it's just a grammar rule, we just pick the right precedence to pick off the two sides of the comparison 20:12
several equivalent aproaches
20:14 BinGOs left
moritz_ brb 20:15
20:15 FurnaceBoy joined
pmichaud it almost cries out for making it clear that 'ok', 'is', etc. are truly test operators 20:17
so maybe infix:<?is> infix:<?ok>
where ?is is a ternary. 20:18
20:18 [particle]1 left
pmichaud or, infix:<?is> keeps its arguments somewhere that ?ok can use in a diagnostic message 20:19
$a ?is $b ?ok "variable equivalence"
moritz_ in a contet var, or something?
pmichaud true ?ok "truth"
I'm just throwing out notions here -- I'm not convinced myself. 20:20
20:20 r0bby left
pmichaud maybe it's another meta prefix 20:20
$a ?eqv $b :diag<equivalence of variables> 20:21
TimToady there are obvious infelicities in the current approach, so we might as well fix 'em all :)
pmichaud although ? wouldn't work well as the meta prefix.
20:21 r0bby joined
TimToady yeah, I was thinking about metaops earlier 20:21
pmichaud oh, I guess it wouldn't be toooooo bad
moritz_ pmichaud: in principle I like the notation, but it looks like more character noise
pmichaud maybe it's just an adverb to the existing ops? 20:22
$a eqv $b :test<items are equivalent>
$a eq $b :test<items are string equivalent>
TimToady I was thinking if we wrote 'ok' as a macro the extra info would come in as named args
so the first two args would still be the boolean and the string
pmichaud but the advantage of tying it to the comparison operator is that it has the operands immediately available for a diagnostic message 20:23
TimToady hmm, interesting syntax
pmichaud unless we have "interesting values of boolean" :-)
TimToady Test Yourself!
pmichaud it could even be 20:24
$a eq $b :ok<items are string equivalent>
if there's no :ok adverb, then it's not part of the test output.
TimToady and the operator knows its own identity too
pmichaud of course, this assumes that we have adverbs, which might be a little difficult in a newish implementation :-|
I'm guessing it's less difficult now that there's a standard grammar, though. 20:25
20:25 zamolxes left
TimToady which is the advantage of a stupidish ok $a eqv $b, "string" 20:25
with extra named args containing the pertinent bits of the first arg
which a stupid "ok" can ignore
20:25 zamolxes joined
pmichaud rakudo's lack of adverb support is mostly because it wasn't entirely clear how to get them into the grammar 20:26
(whereas it's much clearer now.)
TimToady but especially with tabs before :ok it could look very clean
pmichaud yes
20:26 BinGOs joined
pmichaud ....and.... 20:26
TimToady it would also be pretty easy to preprocess into a stupider form 20:27
pmichaud a newbie compiler could just treat :ok as a special syntax
TimToady assuming one per line
pmichaud until it has full adverb support
TimToady that too
moritz_ one per line isn't always realistic
TimToady now we just have the problem of dispatching to the version of comparisons that supports the :ok parameter... :/ 20:28
pmichaud it's also nice because the default :ok could give a reasonable message based on the operator type
i.e., $a eqv $b :ok
could give a nicer error message than ok($a eqv $b)
s/error/diagnostic/
TimToady "FOO isn't eqv to BAR you #$&*@#$&!"
pmichaud exactly. 20:29
that's much nicer.
how many comparisons would need to support :ok?
most other comparisons could be reduced (in tests) to versions that support :ok, same as we do now
TimToady I wonder how often we'd have people making the error of trying to interpoalte into :ok<bad $x pardner> 20:30
pmichaud I also wonder what happens with negative comparisons
$a != $b :ok<not equal>
I guess that actually works. 20:31
TimToady presumably meta-! needs to know about it
pmichaud anyway, I think I've tossed my popcorn for now.
er, peanuts
TimToady peanuts hurt more
pmichaud (I used to go to melodramas where the "peanut gallery" actually threw popcorn at the actors)
TimToady anyway, I think this could be a new state of the art 20:32
moritz_ agreed
TimToady and it doesn't look terribly hard
pmichaud the :ok adverb? really? I did something good? ;-)
TimToady for once :P
moritz_ if it's reasonable to implement (which I can't really judge) I'm all for it 20:33
TimToady well, even if it's unreasonable, wouldn't be the first time I forced it anyway... :)
pmichaud THAT'S for sure! :-P
TimToady after all, Perl Philosphy is simply to torment the implementors on behalf of the user 20:34
pmichaud aha! I have a quote for my keynote.
moritz_ lol
pmichaud and perhaps a theme.
TimToady wow, I said something good (for once)
FurnaceBoy eh, you're frequently quotable. 20:36
<TimToady>ASCII just doesn't have enough brackets... I've noticed this before...
pmichaud that's why we make new ones, like "<< >>" 20:37
and #{ ... }
and =begin FOO ... =end FOO
TimToady there aren't enough quotidian quotes
pmichaud and even things like '(' ~ ')' <EXPR> 20:38
which is a particularly bizarre form of bracketing construct :-)
TimToady in which the contents leak out of the brackets :)
moritz_ so what happens to plan()? 20:39
TimToady why should it change?
moritz_ everything else is an operator now
pmichaud we still want todo(), plan()
20:40 apeiron left
TimToady we just want to throw out the "use Test;" part 20:40
unless you want a different tester
moritz_ so 'use Test::Most' would just overwrite... what?
the :ok part, somehow? 20:41
TimToady all those functions that aren't there anymore :)
pmichaud :ok becomes the "builtin" form for testing, but other modules can still define their own "is", "ok", "dies_ok", "is_deeply", whatever equivalents
as normal functions
TimToady I wonder if people are going to be upset by our taking :ok as an adverb 20:42
pmichaud on the operators?
moritz_ so if somebody wants to change the behaviour of :ok, which hooks do they pull?
pmichaud or in general?
TimToady write a set of comparisons that have :ok as a named parameter and included in the current lexically scope more tightly than the builtins from the prelude 20:43
that's all
and you only have to redefine the ones you want to change 20:44
that's why lexically scoped multis interleave with other longnames from other scopes the way they do
(used to be the other way till we got smarter) 20:45
anyway, the :ok call won't dispatch at all to a version that doesn't support :$ok as a parameter 20:46
pmichaud that might result in "spooky at a distance"
TimToady I presume the proto has :ok in it but the standard operator leaves that out of the sig 20:47
how so?
pmichaud $a foo $b might dispatch differently from $a foo $b :ok
someone simply adding an :ok might not recognize the difference.
TimToady that's true of any multi
pmichaud true.
moritz_ so there's no magical :ok that turns an infix op into a test, as a fallback? 20:48
TimToady fudge --ok
hmm, that is a problem for fudge
20:49 apeiron joined
TimToady how will it recognize the beginning of a statement if there's no "is/ok" there? 20:49
another problem: $x eqv $a + $b :ok will apply the :ok to the + 20:50
pmichaud oh well.
it was a nice thought. :-) 20:51
TimToady they'd have to write $x eqv ($a+$b) :ok
but that's just how adverbs work on operators
moritz_ another test suite faq
pmichaud presumably $a + $b :ok would not dispatch?
i.e., there wouldn't be a matching infix:<+> 20:52
TimToady probably not, so at least it's an error
albeit at runtime
but hey, that's when you run the tests, at runtime :)
so it can still fly, I think 20:53
still have the fudge problem though
unless we have an "is" placeholder at the beginning, or some such
or change the rules for how fudge recognizes a test 20:54
split into statements and assume anything containing :ok is a test, maybe
where "split into statements" pays attention only to final ; or } 20:55
moritz_ and we significantly increase the number of builtin multis 20:57
TimToady but the presence or absence of a named argument is known at compile time, so the candidate list can be optimized even before we know any of the types 21:01
pmichaud ...and one could write the builtins with optional named params
TimToady that seems like a recipe for slow builtins
moritz_ aye 21:02
pmichaud yes
TimToady very likely the :ok versions delegate to the non-:ok versions for the actual work 21:04
and it seems like there's going to be a lot of boilerplate
which argues more for a metaoperator 21:05
maybe :ok is really a metaoperator in disguise
it just happens to bind to the same operator as a real adverb 21:06
21:06 ab5tract left 21:08 pbuetow joined
TimToady but always just generates the appropriate underlying operator you need 21:08
sort of a semantic pass macro
PerlJam Are you guys talking about adding testing operators to perl 6? 21:10
moritz_ yes
PerlJam awesome!
pmichaud PerlJam: making test functions part of the builtins, yes.
moritz_ PerlJam: the current approach looks like this: $x == 2, :ok<$x is really 2>;
TimToady no comma
moritz_ erm, withotu the comma
right
PerlJam er, how does :ok know not to bind to the 2 ? 21:11
pmichaud adverbs bind to operators
TimToady it's where an infix is expected
same way 1..10:by(2) knows
PerlJam aye, I just haven't looked at perl6 syntax in a while. 21:12
so, all of the comparators grok :ok ?
(or will)
TimToady make :ok a crypto-meta-operator that rewrites any operator that returns boolean 21:13
PerlJam so, what happens to $a == 2 && $b == 3 :ok<fooey> ? Do I need parens or something?
moritz_ probably around the second == 21:14
TimToady that one would silently fail currently
I mean, fail to work as expected
you'd get a useless use of, maybe
PerlJam it would silently suceed where it may should have failed :)
TimToady it's possible we should reformulate adverbs a bit 21:15
I wonder if they can be made to apply to the *top* operator visible 21:16
instead of the last one
then this would apply to the && instead of the ==
PerlJam How far up the parsetree should they look? :-)
TimToady but 1..10:by(2) would still work
pmichaud then of course we have the issue of ... and 1..10:by(2) 21:17
TimToady only inside the current scalar item, I think
so make it slighty tighter than comma
pmichaud: that would be fine since :by is tighter than and 21:18
&& would be more of a problem
PerlJam This is starting to feel like the "regular" syntax version of that weird regex ~ thingie 21:19
21:20 mberends left
PerlJam Use the special <MAGIC HERE> operator for all your testing needs. 21:20
pmichaud I have to go help kids with their homework 21:21
bbl
21:21 FurnaceBoy left
PerlJam So ... what was wrong with ok($test,$str) ? Or, why do we need another form? 21:22
21:22 tewk_ joined
TimToady we talked about that eariler, doesn't provide anything beyond a boolean unles ok is a macro 21:25
moritz_ PerlJam: one of the problems is that is() isn't very verbose about its comparison semantics
PerlJam: and changing that to ok($a eqv $b) doesn't give any useful diagnostic output 21:26
TimToady backlog about the last 2 hours...
PerlJam okay. 21:27
so, an adverb that attaches to the highest precedence operator in the previous expression ? And all adverbs or just special ones with nice syntactic markers? 21:28
TimToady highest within , precedence 21:29
so basically loose unary precedence like "not", but a postfix
21:30 kulp joined, azawawi joined
TimToady but unlike current formulation, can see within (), so $a and ($b and $c) :foo applies to the second and, because it's the top operator in the expression governed by the :foo 21:31
assuming you'd never want to apply an adverb to (), which we already assume
21:31 iblechbot left
PerlJam Those seem like really special adverbs. Could we make them look lik ^:foo or something? 21:32
s/lik/like/ 21:33
TimToady but since tigher than comma, works in the middle of a list: 1,2,3..10:by(2), 4,5
the only thing special is that it would write the code for you instead of dispatching to a multi with an :ok parameter
PerlJam or maybe I'm just really uncomfortable with all adverbs behaving this way.
TimToady the syntax is independent of the behavior 21:34
if you mean the meta-op semantics
21:34 tewk left
PerlJam sure, but I'd like the former to give me some clue about the latter 21:34
TimToady do you care that !eq is writing code for you?
or += for that matter 21:35
the only difference is whether you have to implement :ok explicitly or not, and the user doesn't really care 21:36
PerlJam !eq, += and :ok all occupy separate conceptual boxes in my head. Mayhap they shouldn't. 21:37
TimToady maybe the current metaoperators all have :foo forms too, and maybe that's their native form
$a + $b :assignop
doesn't really fly though
21:38 apeiron left
TimToady since you can't write === @x :reduce 21:38
not that [===] is exactly normal either :) 21:39
PerlJam [===] feels more natural to me though
TimToady well, I guess it means "are all of these the same object"
well, you've been programmed to think of lists when you see []
PerlJam true
TimToady which is why I picked it, after all :) 21:40
21:40 jogla joined, BinGOs left
PerlJam What you need is an implementation :) They always seem to bring design flaws out (if there are any) 21:42
TimToady anyway, I don't see much problem with treating some adverbs as semantic macros; this is not important for the user to track, only the implementor of :ok, who would otherwise have to duplicate all the builtins
21:42 alester left
TimToady the policy of which operator to apply an adverb to is a different matter 21:42
21:42 Limbic_Region joined
moritz_ in rx.t we have tests like this: 21:43
ok ('bazaar' ~~ /a*: a/) ~~ Match where matchcheck($_, q/:a/), 'basic';
TimToady gee, who wrote that mess :)
moritz_ would that become ('bazaar' ~~ /a*: a/) ~~ Match where matchcheck($_, q/:a/) :ok<basic>;
PerlJam the principle of least surprise is a strong attractor. you just have to pick the right least surprise :)
TimToady so that would apply :ok to the second ~~ if we went with the precedence solution, which is correct, I guess 21:45
moritz_ aye
TimToady since that's the top operator
moritz_ but for longer expressions I'm a bit worried that the :ok is too far on the right
21:46 apeiron joined
PerlJam yeah, there's a bit of distance between there 21:46
moritz_ and it changes the expression from "useless expression in void context" to "run a test"
which somehow violates the principile of end weight
TimToady well, write a longer message :) 21:47
PerlJam heh
TimToady but it's kinda cool that brainos turn into "useless use" 21:48
it'll even tell you *which* operator leaked 21:49
well, one of 'em, anyway
and it better justifies the existence of "loose unary" precedence :) 21:51
PerlJam I guess part of my conceptual difficulty is that I don't think of tests in an adverbial way. I think of them as nouns that you feed stuff to. Maybe I'm just insane.
TimToady well, they're predicates, really, or assertions
if there weren't a history of ! meaning factorial we'd say $a == $b! when we really mean it 21:52
PerlJam they're the teacher and we're the students handing in our assignments to find out if we pass or fail. :) 21:53
azawawi hi
lambdabot azawawi: You have 1 new message. '/msg lambdabot @messages' to read it.
moritz_ the difference between a test and an assertion is that you (have to) actively run a test, whereas assertions are verified along the way of a normal executioing
TimToady yes, and you don't really want to blow execution out of the water on the first failed test :) 21:54
moritz_ (that's what the Eiffel people generally get wrong; they say "we don't need tests, we have our design by contract" - but as long as the code is not executed, these contracts aren't checked)
TimToady you will soon have us all converted to Haskell :) 21:55
21:55 BinGOs joined
moritz_ TimToady: so should :ok'ed operators catch exceptions? 21:55
not before I convert myself to Haskell ;) 21:56
TimToady well, why not? the one think it can't do it catch parsefails...
*thing
moritz_ nice 21:58
TimToady although a parser could resync a statement if it sees an :ok coming up, I suppose, the way some parsers resync on semicolons 21:59
moritz_ what will '1 :ok<1 is a true value>' work out to?
ie when there's no operator to bind to?
PerlJam "operator expected" :) 22:00
moritz_ well, these things must be tested somehow
PerlJam unless there's a null operator it can bind to for other possibilities
moritz_ simple truthness, dies_ok, eval_dies_ok needs to be addressed
TimToady currently it says 'No previous operator visible to adverbial pair 22:01
moritz_ sub unfix:<>
the null operator
PerlJam "unfix"? :)
moritz_ neither pre nor post nor infix
TimToady given that :ok is testing for boolean, presumably it should supply a true()
moritz_ unfix
PerlJam What's your fixity? I have none. 22:02
Limbic_Region salutations all 22:03
moritz_ hello Limbic_Region ;)
where did you leave your ~ ? ;-) 22:04
Limbic_Region on use.perl it is a space 22:05
TimToady the final frontier...
moritz_ unendliche weiten... 22:06
ELANG
22:09 kulp left 22:12 pbuetow left 22:21 hercynium left 22:23 Exodist left 22:24 YMas joined
azawawi moritz_: any interesting RTs / tasks to work on? 22:25
moritz_ depends on your notion of "interesting" ;) 22:26
azawawi moritz_: something that gets committed in the end ;-) 22:27
moritz_ azawawi: I'm sure most of your patches will get commited in the end... 22:28
on the side of the test suite there's still a lot in t/TASKS
on the rakudo side - dunno, really
azawawi im actually looking at it
moritz_ perhaps infix:<where>
azawawi tests for complex: polar
moritz_ have to go to bed now :( 22:30
happy hacking ;)
azawawi me 2 it is 1:29am here
good night...
22:31 YMas left 22:40 hercynium joined 22:41 azawawi left 22:46 ab5tract joined 22:48 ingyfoo joined, ingy left 22:49 ingyfoo left, ingy joined
pugs_svn r22559 | azawawi++ | [t] removed unused empty directories 22:50
22:54 r0bby left 23:03 kulp joined
pugs_svn r22560 | putter++ | [elfish/on_sbcl] Self-compiles. 23:04
r22560 | putter++ | Undef and bool boxing. Dispatch and misc fixes. Slower.
r22560 | putter++ | Doesn't quite compile the p5 version.
r22560 | putter++ | [STD_red] Improved --format=cl string and nil dumping.
r22560 | putter++ | [elf_h] Yet more missing argument fixes.
23:12 r0bby joined 23:21 Lorn left 23:22 elmex left 23:29 kulp left
speckbot r14591 | larry++ | Make operator adverbs parse sanely based on precedence. They are now treated 23:41
r14591 | larry++ | as "loose unaries" (albeit still in a trailing position), and no longer require
r14591 | larry++ | the parser to track "previous operator". The benefits are construed to
r14591 | larry++ | outweigh the problems.
r14591 | larry++ |
r14591 | larry++ | Note also that existence and deletion are now simply adverbs on subscript
r14591 | larry++ | operators.
23:53 hercynium left 23:56 kulp joined 23:59 drbean left, alester joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!