pugscode.org/ | nopaste: sial.org/pbot/perl6 | ?eval [~] <m oo se> | We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by diakopter on 11 July 2007.
00:02 jferrero joined 00:05 p6quester left, p6quester_ joined 00:07 theorb joined 00:15 p6quester_ left, __Ace__ joined 00:16 p6quester joined 00:19 theorbtwo left 00:21 thoughtpolice left 00:22 p6quester left, explorer__ joined 00:23 p6quester__ joined 00:26 explorer__ left, explorer__ joined
pugs_svn r19300 | lwall++ | Clarification of substr requested by Gothmog++ and pmurias++ 00:27
Limbic_Region TimToady ping 00:28
TimToady pong
Limbic_Region I have been working my way through the synopses very slowly 00:29
I have come to a conclusion - perhaps one you already recognized
they are too dense for anyone to learn perl 6 from
TimToady they're not tutorials, fershure
Tene Limbic_Region: I learned Perl 6 from them. 00:30
Limbic_Region Tene - I assure you, I am talking objectively for the majority and not subjectively for a few
Tene Well, I already knew Perl 5.
Limbic_Region: Okay.
Limbic_Region TimToady - so, is there a specific project to make the documentation more accessible or is the idea to wait for Learning Perl 6? 00:31
TimToady It's certainly something that needs doing one way or another. 00:32
The synopses aren't even in any kind of rational order internally; the only one that has actually ever been reorganized is S03
Limbic_Region well, I have some ideas but it really requires a collaborative effort 00:33
00:34 p6quester__ left
Limbic_Region TimToady - in a nutshell, I think almost every new non-perl 5 concept requires a mini-tutorial 00:35
00:36 p6quester joined
Limbic_Region traits, roles, mixins, the advanced type system, etc 00:36
TimToady (sorry, watching Rose Bowl...) 00:39
Limbic_Region no worries - I am not into college football, but being from Maine - I was very much interested in the Patriots this past Saturday
00:39 jferrero left
Limbic_Region TimToady - in any event, as I work through these synopses I want to write code to assimilate it. I am having a hard time doing this because the code snippets are far too concise. 00:42
TimToady - once the code is written, I think it would be a nice contribution to a tutorialish type doc project 00:43
TimToady - but I am going to need a really in the know resource to help me as I stumble through
Limbic_Region AFK but will be back in a bit 00:44
00:44 r0bby joined
wolverian Limbic_Region, Learning Perl 6? 00:47
00:59 p6quester left 01:01 p6quester joined 01:04 seablue100 joined, _sprocket_ joined 01:08 seagreen100 joined 01:09 p6quester left
meppuru good night 01:09
01:10 kanru left 01:14 meppuru left 01:15 chris2 left
[particle1 pugs: :8<0.0> 01:17
exp_evalbot RESULT[0/1]
01:17 [particle1 is now known as [particle] 01:18 cnhackTNT joined
[particle] pugs: say :8<0.1**2> 01:18
exp_evalbot OUTPUT[0.15625ā¤]
[particle] pugs: say :8<0.1*2**2> 01:23
exp_evalbot OUTPUT[0.16015625ā¤]
01:24 seablue100 left
TimToady doesn't look right to me 01:26
[particle] me neither
not terribly surprising, given the lack of tests
TimToady and the first form is illegal syntax
[particle] however, i think STD is wrong, too
yes, that's what i see in STD, the first form is illegal
01:26 thoughtpolice joined
[particle] $<radfrac> = [ '.' <[ 0..9 a..z A..Z ]>+ ]? ] # one too many ']' ?? 01:26
(in token rad_number) 01:27
01:27 _sprocket_ left
pugs_svn r19301 | lwall++ | Extra right bracket noticed by [particle]]++ 01:28
[particle] ha! also, having an alias called 'radint' as well as a rule called 'radint' is potentially confusing 01:29
TimToady prolly
01:34 han_ joined
pugs_svn r19302 | lwall++ | [STD] "radint" ambiguity pointed out by [particle]++ 01:36
01:38 JarJarBinks left
[particle] is $<fracpart> an array, and is '.' captured? 01:39
01:40 justatheory joined 01:50 alester joined
TimToady no, [...] just captures a string 01:52
01:52 seablue100 joined
pugs_svn r19303 | lwall++ | Another spurious bracket 01:53
[particle] hrmm, i'll need to come up with a perl6 replacement for radint, since we don't have <?{...}> yet
i'll hardcode the bits of rad_number that matter
TimToady: how's this look? rafb.net/p/eOSFla31.html 02:01
02:02 devogon left
TimToady seems pretty okay 02:08
02:09 seagreen100 left
pugs_svn r19304 | lwall++ | Previous radint change was incomplete. 02:09
TimToady in fact, I might end up refactoring STD that way 02:13
02:15 jjore-m joined
[particle] it's likely a *very* minor optimization 02:32
Limbic_Region TimToady - was the outcome of the Rose Bowl what you wanted? 02:34
[particle] damned you, georgia! 02:35
02:35 explorer__ left, jisom joined
[particle] l_r: my team came awful close to kicking your team's butt 02:36
...saturday.
Limbic_Region [particle] - um, came close to winning perhaps - butt kicking, I think not 02:38
[particle] TimToady: my refactor of radint allows my grammar action for radint to be *very* simple: method radint($/, $key) { make $( $/{$key} ); }
TimToady: :8<0b1110> doesn't seem to be a valid rad_number... you need [...] or (...) in order to parse it. is that intended? 02:50
TimToady yes
[particle] ok, then t/syntax/numbers/octal.t is wrong 02:51
...and likely some other t/syntax/numbers tests 02:52
*/ tests
ack. window transparency fooled me into thinking i had mistated myself 02:53
TimToady actually, :8<0b1110> should parse but fail in radcalc with an invalid digit, I think
I can see the argument for allowing it though 02:54
[particle] in perl6 it fails to parse, with Statement not terminated properly at line 43, near "(:8<0b1110"
that's the expected error for a failed statement
TimToady nevertheless, :16<0b1110> is certainly a hex number
[particle] in any case, the tests are wrong, because the smart link points to # L<S02/Literals/"Think of these as setting the default radix"> 02:55
TimToady well, you can't have separate rules for every radix
[particle] but it's talking about :8($x) not :8<$x>
TimToady yes, the question is whether the same calculation is done by radcalc, and how does it know that the 8 in that case is just a default radix? 02:56
if radcalc is used for both purposes, all it can do is guess based on the suggested radix, since 0b is illegal octal and decimal, but valid hex 02:57
alternately, radcalc needs a flag to tell it whether to guess based on the string prefix 02:58
[particle] radcalc has enough args to justify named args imo
TimToady in which case the default should be to not guess, I guess
[particle] agreed
TimToady but I'd really like to allow people to say 0xdeadbeef where a decimal is expected on input 02:59
it's just the literal forms that don't make sense with :10<0xdeadbeef>
that's just perverse 03:00
[particle] please! you've got to keep *some* of perl's perversity!
TimToady I think that'll happen by accident in any case. :) 03:01
[particle] ha! no doubt.
perl6 doesn't seem to parse :8(0b1), which i find odd
since integer is a number is a value is a noun is a term 03:04
i suppose :8(<0xdeadbeef>) is workable 03:05
token integer in STD doesn't mesh with S02. i don't see where \0 is defined 03:08
from S02:2046 03:10
03:13 han_ left 03:19 _sprocket_ joined 03:20 jjore-m left
pugs_svn r19305 | lwall++ | [STD] qq_backslash for \0 missing, [particle]++ 03:22
03:24 lampus_ joined 03:31 _sprocket__ joined 03:37 _sprocket_ left 03:42 _sprocket_ joined, lampus left 03:44 _sprocket___ joined 03:50 awwaiid left, awwaiid joined, _sprocket__ left 03:53 kanru joined 03:59 _sprocket_ left 04:00 _sprocket___ left 04:03 lampus joined 04:20 lampus_ left 04:26 lampus_ joined, lampus_ left 04:37 markstos left 04:38 lampus left
wolverian is adriano ferreira here? 04:39
we were talking about www.oreillynet.com/onlamp/blog/2007...ors_1.html on an unnamed #perl, and were wondering if <!after '/'> makes sense in the context, and if the = in =[\~] is really needed 04:40
TimToady the = is unnecessary there 04:45
[\X] always produces a list 04:46
wolverian that's what I thought 04:49
how about the <!after '/'>? seems it should be just <after />?
Tene pugs: split /<!after '/'>/, 'foo/bar/baz' 04:50
exp_evalbot OUTPUT[*** ā¤ Unexpected "'>/,"ā¤ expecting term postfix, operator, ":" or ","ā¤ at /tmp/i30GNfTlBQ line 1, column 18ā¤]
Tene pugs: split /<!after '\/'>/, 'foo/bar/baz'
exp_evalbot OUTPUT[*** Cannot parse regex: <!after '\/'>ā¤*** Error: Error: Undefined subroutine &Pugs::Emitter::Rule::Perl5::after called at /home/evalenv/pugs/perl5/Pugs-Compiler-Rule/lib/Pugs/Emitter/Rule/Perl5.pm line 124.ā¤ā¤]
TimToady well, these days <?after /> would be more like it 04:53
wolverian ah, okay.
there's one <after in S05 04:54
TimToady <after is okay, but captures to $<after> by default 04:58
05:03 lorn joined
wolverian righto, should have read. thanks again :) 05:11
now, sleep
05:13 Daveman joined
Limbic_Region TimToady - does your local church make audio of weekly sermons available online? 05:15
nevermind - I followed the link from your website and apparently the answer is yes 05:18
05:20 nothingmuch left, jisom left
TimToady reminds me, I have a .wav I need to turn into a .mp3 at some point for 12/16 05:21
05:29 nothingmuch joined 05:39 p6quester joined 05:41 thoughtp1lice joined 05:53 theorb left, thoughtpolice left 06:00 Limbic_Region left
seablue100 in STD.pm, what is unsp and unv? 06:01
06:14 seablue100 left 06:23 thoughtp1lice is now known as thoughtpolice 06:31 alc joined 06:53 dduncan joined 06:55 cnhackTNT left, cnhackTNT joined 07:04 xinming left 07:07 Auzon left 07:08 dduncan left 07:12 mattz left 07:18 alester left, alester joined 07:24 iblechbot joined
pugs_svn r19306 | pmichaud++ | Some initial test refactors and cleanups for basic operators. 07:31
r19307 | pmichaud++ | add some comments to existing tests about refactoring targets. 07:34
07:43 drrho joined 07:48 Aankhen`` joined 07:56 lyokato_ joined 07:59 BinGOs left 08:05 han_ joined, BinGOs joined 08:08 alester left 08:11 BinGOs left 08:17 BinGOs joined 08:24 chacha_chaudhry joined, idiotmax joined 08:38 iblechbot left, meppuru joined 08:46 IllvilJa joined 09:10 H0LE joined 09:20 devogon joined 09:23 ruoso joined 09:38 penk joined 09:39 drrho left 09:55 elmex joined 10:07 cnhackTNT left, H0LE left 10:13 jferrero joined 10:29 theorbtwo joined 10:35 p6quester left 11:04 meppuru left 11:24 chris2 joined 11:40 polettix left 11:41 polettix joined 11:56 IllvilJa left 11:57 jiing left 12:14 fglock_ joined, fglock_ is now known as fglock 12:32 alc left 12:33 han_ left 12:46 Daveman left 12:49 iblechbot joined 12:59 __Ace__ left 13:02 pmurias joined
pmurias fglock: hi 13:02
fglock pmurias: hi 13:03
pmurias fglock: have you seen the Perl5V6 backend?
fglock not yet - I saw the commits
13:04 elmex left
pmurias the thing i'm not sure how should be done is the calling convention 13:06
should i remove Perl5Cached and TokenC? 13:08
13:09 cmarcelo joined
fglock you mean, you need to know how the v6.pm calling convention works? 13:16
13:16 jferrero left
pmurias fglock: i'm not sure if using the v6.pm calling convention is the right thing 13:17
i haven't looked into Data::Bind internals but read the (scant) docs and looked at he test suit,so it's no a problem 13:18
13:19 lyokato_ left
pmurias i wrote a primitive benchmark misc/calling_convention_benchmark.pl, and i'm not sure if it won't be a big performance hit 13:20
fglock yes, you could keep most of the current kp6-perl5, and replace the object system and binding only 13:21
I'm not sure what problems you will find ahead
but it's worth trying
pmurias fglock: does anything problematic come to your mind? 13:23
(besides concurency)
what parts do you think we could keep?
fglock hmm - there is the BEGIN problem, which we fixed by using the "modified" flag 13:24
pugs_svn r19308 | pmurias++ | [kp6] removed KindaPerl6::Visitor::Emit::Perl5Cached
fglock re keep, kp6-perl5 parameter passing is better than v6.pm 13:25
pmurias fglock: the way i plan to keep it for now is to use the orginal Perl5 backend for begin blocks
fglock yes, but it will break when it bootstraps
the Parrot backend has the same problem 13:26
weird, the Parrot backend has more problems than the Perl5 backend
pmurias fglock: we can keep it for a bit after the bootstrap, and switch to saving the env later
the Perl5V6 was going pretty smooth 13:28
s/was/is 13:29
fglock :)
you could emit the "modified" flags - the first versions of kp6 used to work like that 13:30
or you could just ignore it for now, just leave some comments in the code 13:31
13:31 thoughtpolice left, pmccann_ joined
pmurias fglock: i would strongly prefare the later 13:31
fglock ok
that's how "perl6" works 13:32
hmm - I wonder if the Coro module could give us enough introspection to make a dump of the compile-time environment 13:34
doesn't seem so 13:40
pmurias fglock: it think the contrary
Coro::State::call 13:41
13:43 lichtkind joined
pmurias Pad::eval_ast seems to use Emit::Perl5V6 is it possible? 13:43
fglock $state->eval looks useful - I liked the comments too
lichtkind is it true that array munging operators were especially inspired my haskell or similiar languages? 13:44
fglock pmurias: $visitor_emit_perl5 is hardcoded in Pad.pm 13:45
pmurias yes
try script/kp6 -Bperl5v6 t/kp6/06-begin.t
fglock one sec 13:47
pmurias: do you get this error? Can't use string ("2") as a HASH ref while "strict refs" ... Perl5/Pad.pm line 422 13:49
pmurias yes
13:54 chruck left
pmurias fglock: why do we need to use Coro, isn't PadWalker enough? 13:56
fglock PadWalker needs to be executed from inside the closure, I thought Coro could give some other options 13:57
pmurias ah 14:00
$stuff but other& 14:01
fglock pmurias: re emit_perl5 x emit_perl5v6, "class Lit::Code" is redefining several methods 14:07
14:10 alester joined 14:13 pmccann_ left
pmurias fglock: thanks, fixing 14:14
fglock pmurias: I'm fixing here
didn't work - please go on :P
ok, got it 14:15
pugs_svn r19309 | fglock++ | [kp6-v6] fixed method name collision
14:16 chacha_chaudhry left 14:18 jhorwitz joined
pmurias 3 tests more pass :) 14:19
14:24 alester left 14:35 overlast1 joined 14:37 chris2_ joined 14:43 chris2 left
avar why make it run on v6 isn't that pre-mp6? 14:45
14:46 pjcj left
pmurias avar: the name is misleading 14:47
Perl5V6 emits perl5
14:47 han_ joined
pmurias but does it in a style similiar to v6, maping directly to perl5 instead of creating a layer between 14:48
avar: if you can think up a better name, suggest it ;) 14:49
avar I thought it was using v6.pm
fglock avar: it is using v6.pm "runtime"
pmurias Data::Bind that is 14:50
fglock that is, Moose and Data::Bind
pmurias by the way help on it is welcome ;) 14:51
avar can you paste some generated code for this and the normal perl5 backend? It would be interesting to see what p5-directly looks like 14:52
pmurias s/on/with/
avar: use can use script/kp6 -Cperl5v6
avar: or do you want be to nopaste some code? 14:53
pasteling Someone at 81.168.228.98 pasted "../../t/01-sanity/01-tap.t #kp6 -Cperl5v6" (32 lines, 890B) at sial.org/pbot/29541 14:55
Someone at 81.168.228.98 pasted "../../t/01-sanity/01-tap.t #kp6 -Cperl5" (50 lines, 3.1K) at sial.org/pbot/29542 14:56
pmurias pasted 01-sanity/01-tap.t 14:57
avar interesting 14:58
15:14 _sprocket_ joined
ruoso fglock, did you get to any conclusion on my capture's question? 15:21
fglock ruoso: no 15:27
15:28 ebassi joined
fglock brb 15:30
15:31 mncharity joined 15:36 han_ left 15:38 kanru left 15:39 |Jedai| joined
fglock mncharity: hi 15:44
ruoso TimToady, could you please ellaborate more on captures in the specs? I'm having a hard time getting how they should behave... 15:45
15:47 pjcj joined 15:49 acmoore left 15:52 thoughtpolice joined 15:57 TJCRI joined 15:58 jedai left 16:03 _sprocket_ left 16:18 alester joined 16:24 rindolf joined 16:29 rindolf left
PerlJam ruoso: captures are an unruly bunch. They don't behave. 16:30
16:31 Psyche^ joined
TimToady I seem to have missed the question 16:31
and do you mean captures or Captures? 16:32
mncharity hi fglock! :)
16:38 barney joined 16:46 Patterner left, Psyche^ is now known as Patterner
ruoso TimToady, Captures 16:48
TimToady, as in $a = \(1,2,3); or in $a := %a<b><c> 16:49
TimToady what would you like elaborated? 16:51
ruoso how does \%a<b><c> affects %a<b><c> 16:53
is one of the things
should capture creation be understood as a "context", as would be scalar?
PerlJam ruoso: taking the Capture doesn't do anything to the underlying data structure AFAIK if that's what you're asking.
ruoso PerlJam, you see, that's the point where I get confused... 16:54
how then \%a<b><c> autovivifies the hash, while just %a<b><c> doesn't
TimToady it should not autovivify unless bound to something rw 16:55
ruoso hmmm...
ruoso looking again
TimToady just as foo(%a<b><c>) doesn't autovivify unless its first parameter is rw
ruoso my $a = \%a<b><c> autovivifies 16:56
TimToady a Capture is just a snapshot of an unbound argument list
"my $a" defines a rw variable
so yes
ruoso ok... how should a Capture object look like/ 16:57
?
thinking about data structures
TimToady that's an implementation detail :P
ruoso ok... I need some help with that...
:)
PerlJam ruoso: I think TimToady is only good for suppositional implementations these days :) 16:58
ruoso I still can't figure out how the capture binding can trigger the autovivification
be it to a variable or to a signature
PerlJam, a supositional would be enough for me now... 16:59
:)
PerlJam ruoso: okay, suppose you have a spherical cow of uniform density ...
17:00 penk left
TimToady and suppose that cow can contain a Failure that knows how to autovivify something in order to "unfail" 17:00
17:00 rindolf joined
ruoso ok 17:00
TimToady and suppose an rw binding looks at the cow, and calls the autovivify method on it 17:01
only without the cow
ruoso ok, so the binding process should explicitly call the autovivification?
hmmm
I was counting on that being part of the logic of the array and hash types
TimToady if it needs an rw binding 17:02
rindolf Hi all.
Hi TimToady , ruoso
ruoso hi rindolf
rindolf Happy new year.
TimToady hi rindolf, happy solar new year
or at least, civic...
ruoso so, a Capture is just a container object that doesn't enforce any context, is it? 17:03
TimToady basically. context is enforced lazily by binding
rindolf TimToady: thanks.
TimToady: what's up?
TimToady that's how we get out of most of the nasty Perl 5 traps
and why signatures work much better than prototypes 17:04
and can work on methods as well as functions
PerlJam TimToady: more evidence of Laziness as a virtue.
ruoso ok... If i let the autovivification to be a feature of the interpreter in itself, instead of a feature of the array type
or the hash type
I mean
instead of the array and hash autovivify by themselves,
the binding code would do it
TimToady well, the binding code just knows how to tell the "nonexistence" Failure object to undo itself 17:05
and that object knows how to tell the hash or array to create the required value
but the hash or array still has to participate 17:06
ruoso Ok...
that clarifies a lot
TimToady most of the time, in rvalue context, a Failure just looks like "undef" to a Perl 5 programmer, but that's just because in real rvalue context it's never going to be bound to something rw 17:07
and, of course, if the compiler can detect that, it can maybe optimize away some of the autoviv apparatus, if it's heavy 17:08
but maybe it isn't.
ruoso but... wasn't Failure supposed to raise an exception?
or is this just yet another undef type and not exactly a failure 17:09
TimToady Failure throws an exception only if 1) you've said "use fatal" or 2) you try to use the actual value from it.
it's possible that most Failure objects are actually typed correctly for the return value expected, so they're really protoobjects that know they're also Failures 17:10
ruoso hmmm... I understood that the "use fatal" would make them to raise the exception in-time instead of lazy 17:11
TimToady so if you have a hash that you know returns Dog, you really get an undefined Dog out of it, and that Dog knows how to autoviv itself to a real dog object
er, that's what I just said under 1)
use fatal makes it throw and exception immediately 17:12
ruoso ah... ok...
So, if you just ignore the return is the same as catching the failure
TimToady so, I guess you don't get any autoviv under "use fatal" either...
ruoso that's odd
TimToady maybe the return protoobjects aren't considered failures then, unless you "use fataler" 17:13
ruoso remembers reading that the failure would raise when getting out of the scope... isn't ignoring return a way of getting the value out of scope?
TimToady hmm, yeah, I recall something like that too... 17:15
ruoso anyway...
wouldn't Unintialized a better definition of the non-existant?
TimToady that's what a protoobject means 17:16
ruoso so, uninitialized is not a failure, is it?
TimToady correct
ruoso ok..
TimToady so if autovivifyers return protoobjects instead of failures, that would allow autoviv under fatal 17:17
ruoso so the autovivification triggering belongs to the Uninitialized object
TimToady which seems right
lemme think about it in the shower
fglock (that's "ValueProxy" in kp6)
TimToady we may have just generalized that to Dog :)
ruoso so, the thing that triggers it is the binding process, right? 17:18
the binding would call Autovivify in the Uninitialized object...
TimToady yes, something like that
ruoso no matter if binding to a variable or to a signature
one other thing.. 17:19
TimToady a variable is just a degenerate signature
[particle] hums "officer krupkie"
ruoso my $a := %a<b><c>; my $b := %a<b><c>; $a = 1;
this is an interesting case, 17:20
TimToady $a and $b should be the same container
ruoso so, a capture for %a<b><c> is not for the value of %a<b><c>,
but for %a<b><c> in itself 17:21
TimToady correct, captures have to be able to do container aliasing
ruoso but, if %a<b><c> wasn't autovivified yet
what does $a points to
TimToady an abstraction
that's what the "a" is for, after all :) 17:22
ruoso so, the unintialized object captured in %a<b><c> would have to keep a reference to "%a<b> looking up for <c>"
which, in fact would be 17:23
(looking for <c> in (looking for <b> in %a))
TimToady when you autovivify, you have to create any missing elements, and also make sure to reuse and elements that were already created by someone else
(in the meanwhile)
yes
when nested arrays are referenced, they pass protoobjects down that get wrapped up by the lower down array in another protoobject, I think 17:24
ruoso feels like programming functional, and for the first time, really understands it
TimToady cool
shower & 17:26
fglock ruoso: kp6 implements it that way 17:27
ruoso fglock, ok... I need to adjust how yap6 does it 17:28
fglock except that binding autovivifies, I think
re binding, I think I read it somewhere in the spec
ruoso the difference is that I was returning a scalar from the list and the hash
and I should be returning captures 17:29
or not
should a lookup in an array return 1) a scalar 2) a value or 3) a capture? 17:30
17:30 penk joined
fglock I think Parrot doesn't do hash/array laziness either 17:30
ruoso scalar is probably out of the case, because that would pre-enforce scalar context
which is not the case 17:31
17:31 Psyche^ joined
ruoso I think it's between value or capture 17:31
as there's \%a<b><c>, it probably should return a value
fglock ruoso: it depends on the hash current content 17:33
ruoso for the uninitialized, i mean
actually, for the API, i mean
fglock kp6 returns a special case of scalar
17:34 TJCRI left
ruoso yeah... but then you're forcing scalar context 17:34
which may not be the case
fglock it's called "ContainerProxy"
it's not a scalar
it can be Hash, Array, or Scalar
ruoso ContainerProxy is what the Capture would be, isn't it? 17:35
fglock it depends on how you use it later
ruoso so it's the capture
fglock no
ruoso fglock, no?
fglock Capture is a collection 17:36
ContainerProxy is a single thing
ruoso \%a<b><c> is a capture
fglock but you can make a Capture with a single ContainerProxy
yes
ruoso which is the same as \(%a<b><c>) 17:37
which makes sense with what you're saying
fglock kp6: my %a; my $b = \(%a{1}); say $b.perl 17:41
exp_evalbot r19309: OUTPUT[\( undef, )ā¤]
fglock that doesn't help - .perl simplifies the output
ruoso kp6: my %b; my $a = %b<c><d>; say $a.perl; 17:42
exp_evalbot r19309: OUTPUT[syntax error at position 22, line 1 column 22:ā¤my %b; my $a = %b<c><d>; say $a.perlā¤ ^ HEREā¤]
ruoso kp6: my %b; my $a := %b<c><d>; say $a.perl;
exp_evalbot r19309: OUTPUT[syntax error at position 23, line 1 column 23:ā¤my %b; my $a := %b<c><d>; say $a.perlā¤ ^ HEREā¤]
17:42 thoughtpolice left
ruoso kp6: my %b; my $a := %b{'c'}{'d'}; say $a.perl; 17:42
exp_evalbot r19309: OUTPUT[undefā¤]
ruoso kp6: my %b; my $a := %b{'c'}{'d'}; say %b.perl;
exp_evalbot r19309: OUTPUT[{ }ā¤]
ruoso kp6: my %b; my $a := %b{'c'}{'d'}; say %b.elems;
exp_evalbot r19309: OUTPUT[0ā¤] 17:43
ruoso ops
kp6: my %b; my $a = \(%b{'c'}{'d'}); say %b.elems;
exp_evalbot r19309: OUTPUT[syntax error at position 13, line 1 column 13:ā¤my %b; my $a = \(%b{'c'}{'d'}); say %b.elemsā¤ ^ HEREā¤]
17:43 dlocaus joined
dlocaus yikes, reading 2 weeks of perl6 logs... 17:43
Hello! 17:44
17:46 allbery_b is now known as eviltwin_b
fglock dlocaus: welcome back 17:47
dlocaus thank you, I had a nice X'mas.
Did you have a nice New year?
17:47 Patterner left, Psyche^ is now known as Patterner
fglock yes, thanks :) 17:48
dlocaus fglock: I'm catching up (reading IRC logs on perlgeek.de) is there anything you need done? Before you head on home?
fglock dlocaus: there is lots to do, but I could not update the project plan yet 17:50
dlocaus ok.
I'll check around then, when I am done reading the IRC logs.
17:51 eviltwin_b is now known as allbery_b
fglock we are currently working on supporting Parrot, Perl5+Moose+Data::Bind, and C 17:51
we are blocked in several places
dlocaus ok 17:52
fglock which is the reason you deon't see many commits lately
don't
dlocaus Data::Bind as the one by Chia-liang Kao?
fglock yes
pmurias dlocaus: hi 17:53
dlocaus pmurias: hello!
pmurias Perl5+Moose+Data::Bind is mostly blocked by my lack of time 17:54
dlocaus I wonder if the the Perl6::* packages will have perl6 done before anyone else? 17:55
fglock dlocaus: see v6.pm
pmurias the Perl5+Moose+Data::Bind is avalible with -{C,B}perl5v6 17:58
17:59 TJCRI joined
dlocaus en.wikipedia.org/wiki/Transactional_memory : Interesting (I found it when looking at an IRC link) 18:03
/found/looked it up/
18:14 rindolf left 18:15 meppuru joined 18:16 Daveman joined 18:18 bwisti joined
ruoso so.... a capture object has the members: invocant, positional and named 18:19
it doesn't enforce any context
18:21 meppuru left 18:22 meppuru joined
fglock actually, kp6 captures now only have positional members - "named" is a special case of positional 18:22
but that's an implementation detail, probably 18:23
ruoso fglock, not sure...
i was reviewing s06
and it seems that the capture composition defines if it's named or positional
18:24 _sprocket_ joined
fglock yes, but you need to keep the ordering, for matching captures to signatures 18:24
ruoso I think (1,2,3,:a<b>,4) have 1,2,3,4 as positional and a<b> as named 18:25
I don't think a<b> counts as positional
fglock that's right, 18:26
but you need to record the position of "a"
you may need it later
pmurias fglock: when?
fglock it depends on the signature that the capture will match to 18:27
see the algorithm at Emit::Perl5, it needs to scan the capture in order 18:28
TimToady order matters if you have two :a
ruoso you shouldn't be able to fetch named as positional, if that's what you mean, fglock
TimToady, but that's at capture composition, isn't it? 18:29
fglock ruoso: no, I mean matching captures to signatures
TimToady question is, if you bind to |$capture, can you reconstruct the original call order and do something else
fglock this was implemented after a discussion here, about 2 months ago I think 18:30
ruoso fglock, why would you need the order for named there? (except for several of the same name?)
TimToady I tend to agree with the opinion of not forgetting anything that might be useful later
even if that later use is unconventional
fglock ruoso: I don't remember - looking
18:31 Jamtech joined
TimToady also, if the only thing you bind is a perl 5 style *@_, arguably that should contain the named args 18:32
ruoso TimToady, at some place in the synopsis, it says that the capture coerced to array should return the positional args
TimToady well, likely, but there needs to be some way to get at the original arguments in pristine form 18:33
ruoso *@_, *%_
TimToady that throws away position info on *%_ 18:34
what if you're writing a macro that does something different to its args?
maybe it's just "bind to |$capture and then call $capture.originalargs" or some such 18:35
ruoso TimToady, that's much more sane
TimToady or possibly it's the default binding of @_ when there's no sig
ruoso if you wish to use the args as a capture
you can just declare your signature accordingly
TimToady but maybe it's more useful if the no-sig case automatically sets *%_ as well 18:36
ruoso I would expect so
whereas @_ has only the positional and %_ only the named
TimToady however, that makes it a little harder to translate p5 to p6 18:37
ruoso list to hash coercion in Perl 6 won't do what p5 does already
TimToady it's pretty close
a => 'b' still does the same thing 18:38
just via Pair object
(assuming the original P5 code didn't get out of sync)
I suppose the p5-to-p6 translation must really turn => into ,
ruoso a => b does, but 'a', 'b' doesnt
TimToady yes, which is why it has to remove => and replace with ,
because p5 intermixes them freely 18:39
and you can't undo the %args = @_ idioms in the sub
maybe we need a p5-ish => equivalent
ruoso I, personally, wouldn't care too much with p5->p6 translations 18:40
the language is already too different
TimToady it's just one factor to bear in mind, but we don't want to make people miserable unnecessarily
we're already going to have various p5ish variants of some of the builtin functions 18:41
ruoso in Perl 6, when you have a list coercion to hash, you pair two by two?
TimToady so maybe a p5=> isn't so farfetched
unless the next arg is a Pair or a Hash
ruoso ok 18:42
TimToady so %foo = a => 1, 'b', 2; does the Right Thing
ruoso but anyway...
having @_ to return the named arguments seems a little bad 18:43
TimToady I think I like the p5=> solution. it means comma, but is really ugly and easy to search for when you want to convert to real =>
p5=> would suppress that
since it's just a comma
it would come in as @_ 18:44
ruoso hmmm
I see
TimToady when you switch to real => it comes in as %_
but you have to change the sub at the same time
ruoso sure
TimToady and we've already got p5foo emulator functions elsewhere, so it's not like a new meme
ruoso ok... so the default sig is to get all positional to @_ and all named to %_ 18:45
fglock ok, I reviewed the kp6 code - Capture does have separate named/positionals,
(the Capture is created from a plain list of named+positionals) 18:46
ruoso thinking in the low level 18:52
18:54 ebassi left
ruoso \%a<b><c> is really something like: "capture capture( %a: 'b' ): 'c' ", while plain %a<b><c> is something like "fetch capture(%a: 'b'): 'c' " 18:55
or even deeper... fetch(capture(capture(MY: 'a'): 'b'): 'c') 18:57
actually... fetch(capture(capture(MY: '%a'): 'b'): 'c'), as the sigil is part of the name 18:59
so... capture is a "method" of hash 19:00
that, just as fetch, receives the key name 19:01
19:01 Jamtech left
ruoso actually the key object 19:01
and the hash as the invocant
but I'm still missing the context... 19:02
maybe...
fglock ruoso: captures and lookups are different things 19:03
ruoso fetch(hash(capture(hash(capture(MY: '%a'):):): 'b'):): 'c') 19:04
fglock, but both are methods of the containers
and the values also, actually 19:05
you can do \3
fglock kp6: say \(3).perl 19:09
exp_evalbot r19309: OUTPUT[\( 3, )ā¤]
fglock but this is Capture.new( positionals => [ 3 ] )
ruoso what is just what I would mean in the pseudocode I written above as a call to capture without invocant 19:11
the thing is that a capture of %a<b><c> must relate to %a<b>: 'c' and not to %a<b><c> directly 19:12
because
my %a; my $b := %a<b><c>; my $c := %a<b><c>; $c = 1; 19:13
fglock I've got to leave & # will backlog
ruoso $c and $b are bound to the lookup of c in the lookup of b in %a 19:14
hmmm 19:15
but that's why capture autovivifies
but...
what happens when 19:16
my %a; my $b := %a<b><c>; %a<b> = { c => 1 };
TimToady, what should happen in the above code? should $b equals 1? 19:17
dlocaus moritz: irclog.perlgeek.de/perl6/2007-12-28 (next day doesn't link to 2007-12-29... (next day link is missing) fyi.
ruoso if not? what should $b point to?
PerlJam ruoso: $b should be 1 but that has nothing to do with Captures. 19:18
ruoso PerlJam, how so?
dlocaus, that was when the logger was out 19:19
dlocaus humm 19:20
PerlJam ruoso: caveat lector as I'm just a humble reader of synopses, but I don't think captures have replaced references quite like you think. %a<b><c> will lazily auto-vivify a hash (or two) as needed. There are no Captures there. 19:23
ruoso PerlJam, as I understood so far, binding is really Signature := Capture 19:25
PerlJam perhaps. I haven't read this stuff in a while so I'm just working from memory.
ruoso TimToady just said... "a variable is just a degenerate signature"
19:26 Limbic_Region joined
PerlJam What you're saying doesn't jibe with my memory. So one or the other is off :) 19:26
(or both)
ruoso PerlJam, S02 # immutable types 19:27
Capture (right side of a binding)
Signature (left side of a binding)
ruoso going home 19:28
ruoso probably gets online later today
ruoso will backlog
PerlJam ruoso: sure, but since you have a $scalar on the left side, I think what happens is that the Capture is optimized away into just its scalar component
ruoso hmmm... isn't that what the assignement would do? 19:29
I think the regular use of the variable will imply scalar context 19:30
but the container is still whatever it is
it may be a hash
PerlJam It's best to let people of TimToady proportions have a go at explanation. :-)
ruoso heh 19:31
ruoso really got to go
brb&
19:31 ruoso left
PerlJam yeah, I've got to get to work too 19:31
PerlJam work &
19:33 fglock left
TimToady I dunno, my proportions are rather skinny... 19:35
19:39 jisom joined
Limbic_Region My proportions are quite large these days. "Success goes to your head, but happiness goes to your hips" - Tye McQueen 19:39
dlocaus break & 19:47
19:56 jferrero joined 19:57 TJCRI left 20:04 TJCRI joined 20:06 rindolf joined 20:07 lorn left 20:09 lorn joined
rindolf Hi all. 20:10
20:11 Coke joined, TJCRI left 20:12 Coke left 20:13 jisom left 20:22 ruoso joined, lorn left
ruoso back 20:23
sub foo (|$capture) { say $capture[0] }; foo(bar()); 20:24
is bar() execution lazy?
better put... my $a := bar(); 20:25
does it execute bar?
or will it only execute when $a is used?
if the rlvalue of the binding is a capture, I would expect bar() to be executed during the binding only if I had 20:27
my $a := |bar()
so the binding would be a truly functional thing 20:28
otoh, this would mean that my $a := %a<b><c> wouldn't need to autovivify (except by being specced that way) 20:29
am I insane? or does it make any sense? 20:30
TimToady, what do you think # and sorry for being so picky today ;) I'm trying to realize how to proceed on yap6 20:33
20:44 justatheory left 20:51 justatheory joined, rdice joined 21:00 rindolf left
TimToady we are not that lazy. bar() is invoked immediately, but may return its value lazily. 21:05
bbl & 21:06
21:11 barney left 21:14 jjore-w joined, jjore-w left
[particle] @tell fglock jonathan++ implemented set_outer on Sub for parrot in r24453. have at it! 21:18
21:20 IllvilJa joined 21:34 tobeya joined
ruoso kp6: my %a; my $b = %a<b><c>; %a<b> = { 'c' => 1 }; say $b; 21:40
exp_evalbot r19309: OUTPUT[syntax error at position 22, line 1 column 22:ā¤my %a; my $b = %a<b><c>; %a<b> = { 'c' => 1 }; say $bā¤ ^ HEREā¤]
ruoso kp6: my %a; my $b = %a{'b'}{'c'}; %a{'b'} = { 'c' => 1 }; say $b;
exp_evalbot r19309: OUTPUT[ā¤]
ruoso kp6: my %a; my $b := %a{'b'}{'c'}; %a{'b'} = { 'c' => 1 }; say $b;
exp_evalbot r19309: OUTPUT[ā¤]
ruoso pugs: my %a; my $b := %a{'b'}{'c'}; %a{'b'} = { 'c' => 1 }; say $b; 21:41
exp_evalbot OUTPUT[ā¤]
21:42 Aankhen`` left
ruoso pugs: my %a; my $b := %a{'b'}{'c'}; %a{'b'} = { 'c' => 1 }; say $b; say %a{'b'}{'c'}; 21:42
exp_evalbot OUTPUT[ā¤1ā¤]
ruoso pugs: my %a; my $b := %a{'b'}{'c'};$b = 2; say $b; %a{'b'} = { 'c' => 1 }; say $b; say %a{'b'}{'c'}; 21:43
exp_evalbot OUTPUT[2ā¤2ā¤1ā¤]
ruoso is this correct? 21:44
pugs: my %a; my $b := %a{'b'}{'c'};$b = 2; say $b;say %a{'b'}{'c'}; %a{'b'} = { 'c' => 1 }; say $b; say %a{'b'}{'c'}; 21:45
exp_evalbot OUTPUT[2ā¤2ā¤2ā¤1ā¤]
21:54 Pengwn joined 21:57 Pengwn left 22:13 _sprocket_ left, rdice left 22:20 Schwern joined 22:22 cmarcelo left
ruoso I think I got it... 22:27
if all the container value-fetching returns Captures, we can postpone the context coercion and use the values directly in case of bind
for instance 22:28
%a<b><c> would mean a lookup for b in %a which would return a capture. this capture would be coerced to hash and then subject to another lookup, now for 'c', but at this time, the resulting capture will feed the call to bind 22:29
which would then check for uninitialized and call autovivify on it, if that's the case, which would end building the hash recursively
if the target container is rw 22:30
the difference for a assignment would be in the last step, 22:31
where the assign code would coerce to the proper context and copy the value. 22:32
the thing in all the container operations returning captures is that they can be coerced to any context afterwards... 22:33
like my %a = %a<b>
this would coerce to hash after the lookup
or even 22:35
in sub/method call
sub foo ($a, %b) { ... }; foo( %c<d><e>, %c<d><f> ); 22:36
%c<d><e> returns a capture, that in bind-time is coerced to scalar
%c<d><f> returns another capture, that in bind-time is coerced to hash
22:41 ebassi joined
ruoso maybe not... 22:42
the return for the container value-fetching return objects that behave like scalars 22:43
22:43 pmurias left 22:44 justatheory left, justatheory joined
ruoso I think the way I was thinking was right at the first place 22:46
22:47 TreyHarris joined 22:48 ispy_ joined
TreyHarris anybody have an example offhand of where paren-less control constructs wouldn't work in the Perl 5 grammar? 22:49
oh, i got it. "if $var { foo }", is it "$var<foo>", or is it "if ($var) { foo() }"? 22:56
pugs_svn r19310 | ruoso++ | [yap6] getting closer to something rational in the autovivification and capture issue. see NOTES_AUTOVIVIFY.txt 23:07
ruoso trying to get the ideas in order... 23:11
ruoso giving up for today
23:26 DaGo joined 23:31 BinGOs left 23:38 alester is now known as AndyAway 23:39 BinGOs joined 23:49 iblechbot left 23:55 felipe left 23:57 lichtkind left 23:59 han_ 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!