|
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:02
xiaoyafeng left
00:06
lichtkind_ joined,
lichtkind_ left
|
|||
| mncharity | I note gimme5, given '3 || 4', doesn't seem to actually mention the op anywhere. | 00:12 | |
| TimToady | strange | 00:14 | |
|
00:24
lichtkind left
00:40
jeja left
00:43
jferrero left
|
|||
| TimToady | I think I need to fix the cycles differently to avoid losing operator info like sym | 00:45 | |
| decommuting & | |||
|
00:49
kst`` left
00:50
kst`` joined
|
|||
| mncharity | ah, ok. | 00:57 | |
| pugs_svn | r22601 | putter++ | [elfish/STD_blue] Continuing to adapt IR constructors to gimme5. | 01:24 | |
| ruoso | hmm... s1p_array doesn't support push yet... | 01:30 | |
| mncharity | modulo circularity/op, some elf files are starting to look vaguely plausible. current plan is: () get to elf self-compilation; () running STD_blue against STD.pm, teach elf to generate IR for it; () incrementally teach elf to run STD, piece by piece. | 01:31 | |
| pugs_svn | r22602 | ruoso++ | [smop] starting to implement multi... blocking on s1p_array.push | 01:32 | |
| mncharity | hi ruoso. I've only the fuzziest idea what your current state is. is there a summary somewhere? | ||
| ruoso | mncharity, hi... the first page of the wiki explains it quite extensively | 01:34 | |
| specially the ROADMAP and Changelog parts | |||
| mncharity | thanks | 01:35 | |
| ruoso | mncharity, but there are some cool tests in the test/ directory | ||
| specially the .m0ld files | |||
| mncharity, one of my favorite tests is the test/35 | 01:36 | ||
| mncharity | looking... | 01:37 | |
| ruoso | that test demonstrates how SMOP implements lazy grep/map | ||
|
01:38
wknight8111 joined
|
|||
| mncharity | :) | 01:38 | |
| ruoso | we're actually very close of having enough runtime to comile src-s1p/P6Meta.pm to m0ld | 01:39 | |
| mncharity | re multi dispatch, any plans to write out the dispatcher in p6 first? I'd love to have a reference copy. | ||
| ruoso | well.. the dispatcher itself will be in m0ld probably... | ||
| unless pmurias manage to get mildew running more things quickly | 01:40 | ||
| which will then mean that we might have the sub dispatcher written in P6 | |||
| mncharity, but the method dispatcher is already going to be written in P6 anyway | |||
| mncharity, it should be written in the src-s1p/P6Meta.pm class | 01:41 | ||
| which is the 'default' p6 HOW implementation | |||
| mncharity | P6Meta interesting | ||
| ruoso | and then there's src-s1p/Object.pm | 01:42 | |
| our next major milestone is compiling both P6Meta and Object | |||
| which will mean that we've bootstrapped our type system | |||
| then it's just a matter of writing the built-in types in Perl 6 | 01:43 | ||
| and the native types in the RI DSL | |||
| which is the final step before porting the actual compiler to smop | |||
| mncharity | what are you parsing P6M and Obj with? | 01:44 | |
| ruoso | we aren't yet | ||
| we plan to parse it with STD | |||
| that's what mildew is about | |||
| actually, it should already be parseable by std... | 01:45 | ||
| hmm... it doesn't... it seems STD doesn't like pod yet | 01:47 | ||
| hmmm... ooops... it's actually my fault | 01:48 | ||
| mncharity | re mildew, ah, ok. sigh. we've ~no developers, so we duplicate each others work too. ah well. | ||
| ruoso | mildew is turning STD parse tree (actually it's viv AST iirc) into m0ld | 01:49 | |
| I'm not sure it's actually the same thing of STD_rgb | |||
| mncharity | re it's viv, yes | 01:50 | |
| mncharity greps for STD_rgb, then, d'oh. | 01:51 | ||
| ruoso | btw... STD does parse Object.pm (after some fixes I'll commit in a bit) | ||
| ;) | |||
|
01:51
hercynium joined
|
|||
| mncharity | STD _accepts_ Object.pm... ah, nm. :) there advantages to exploring two approaches to the same thing after all. | 01:53 | |
|
01:53
alester_ joined
|
|||
| mncharity | re STD_rgb, viv is a tree walker and AST class creator. STD_blue walks the same tree, but dispatches to functions identified by the node rule names (IRx1_FromAST). so, similar. | 01:56 | |
| ruoso | mncharity, but targeting different runtimes... which mean... not really mergeable... | 01:57 | |
| pugs_svn | r22603 | ruoso++ | [smop] small fixes to src-s1p... both files are parseable by std now | ||
| ruoso | for some reason STD accepts 'my List of Method @foo;' but not 'my List of Attribute @foo;' | ||
| std: my List of Method @foo; | 01:58 | ||
| p6eval | std 22602: OUTPUT[parsedā¤] | ||
| ruoso | std: my List of Attribute @foo; | ||
| p6eval | std 22602: OUTPUT[parse failureā¤] | ||
| mncharity | hmm. if the runtime is affecting AST handling, that's probably a design problem. even allowing the runtime to affect/infect the IR is problematic. | ||
| ruoso | mncharity, well... the line of where it's really AST and where it's an OPTree | 01:59 | |
| it's a very thin one | |||
| mncharity | basically, once smopish is running subs, lexicals, package vars, temp, a few other things, adding a smopish backend to elf, to go with the current p5 and CL, should be a few days work. | 02:00 | |
| ruoso | mncharity, that's basically the plan... yes | ||
| mncharity, and eventually porting the compiler itself to smop | |||
| TimToady, any expected reason for std accepting 'my List of Method @foo' and not 'my List of Attribute @foo' ? | 02:01 | ||
|
02:02
ab5tract left
|
|||
| ruoso | mncharity, anyway... there's a very important task we didn't start yet... which is writing "method dispatch()" in P6Meta.pm | 02:03 | |
| "method dispatch()" is the method that implements method dispatch | |||
| ruoso .oO( bootstrap is a curious thing, isn't it? ) | |||
| mncharity | re "the line of where it's really AST and where it's an OPTree", "it's a very thin one", eep. I very much suggest not. compiling p6 well, type inference, data flow, etc, is something to be done in p6, on a backend-neutral intermediate representation. | 02:04 | |
| re "bootstrap is a curious thing", ! :) ! | |||
| yeah, despite all the crud cruft and slogging, I truly love it. | |||
| ruoso | I mean... we all aim to a backend-neutral IR... but I'm still not sure we're going to get it | 02:05 | |
| mncharity | could you elaborate? I can't really imagine why not... | ||
| ruoso | hmmm... I have a reason to think that, I know I do... it's somewhere in my brain... | 02:06 | |
| ruoso EASLEEP | 02:07 | ||
| mncharity | even if we end up with several IR's, with different properties (immutable, tree swizzling, etc), well, that's what multis are for. | ||
| re sleep, yeah. end of day. | 02:08 | ||
| ruoso | well.. it probably just mean that I'm not very much worried about the AST being trully abstract... | ||
| as long as it runs... | |||
| I think my concern is really about having the separation of compilation and runtime | 02:09 | ||
| but I'm too asleep to think... | |||
| later & | |||
| ruoso zZzZzZzZ | |||
| mncharity | yeah. an advantage of the smopish close-to-the-metal approach the compiler can afford to be dumber. CL requires a bit more smarts. and p5 vastly more. | ||
| g'night rouso | 02:10 | ||
| good night all & | |||
|
02:10
mncharity left
02:11
kst`` left
02:12
kst`` joined
02:13
wknight8111 left
02:18
araujo left
02:30
agentzh left
02:55
agentzh joined
03:00
elmex left
03:01
elmex joined
|
|||
| partclCoke yawns | 03:04 | ||
|
03:06
ab5tract joined
03:08
partclCoke left
03:16
hercynium left
03:20
kst`` left,
kst`` joined,
coke joined
03:34
BinGOs left,
BinGOs joined
03:36
alester_ left
03:39
BinGOs left
03:42
rdice left
03:51
coke left
03:58
z80ASM joined
04:06
z80ASM left
04:08
z80ASM joined
04:11
alester_ joined
04:21
z80ASM left
04:37
alester left
04:47
kst`` left,
kst`` joined
05:11
ab5tract left
05:20
justatheory left
05:24
wilx_ left
05:59
kst`` left
|
|||
| pugs_svn | r22604 | lwall++ | [STD] revise cycle removal to preserve op fields other than PRE and POST | 06:00 | |
|
06:00
kst`` joined,
Psyche^ joined
06:13
zamolxes left,
Patterner left,
Psyche^ is now known as Patterner
06:19
jferrero joined
06:21
adc_Penner joined
06:26
alester_ left
06:36
mallory_ joined
06:38
BinGOs joined
06:39
ashizawa joined
06:54
pmurias_ joined
|
|||
| pmurias_ | ruoso: actually it should be possible to use (a slightly modified) mildew IR to target other backends | 07:05 | |
| pugs_svn | r22605 | pmurias++ | [mildew] unfinished infix:<=> handling, t/pure_prototype.t showing how far are we from defining a method | 07:11 | |
| pmurias_ | ruoso: have you seen mildew --desugar? | 07:12 | |
|
07:16
pmurias_ left
07:24
kst`` left,
kst`` joined
|
|||
| mallory_ | hi, agentzh | 07:26 | |
| agentzh | mallory_: hiya | 07:29 | |
| mallory_ | :D | ||
| agentzh | just a bit surprised to see you here :P | 07:30 | |
|
07:30
kanru left
07:32
kanru joined
07:35
sri_work joined
07:45
cosimo joined
|
|||
| mallory_ | just walk | 07:46 | |
|
07:48
zamolxes joined
07:50
iblechbot joined
07:51
adc_Penner2 joined
07:57
[particle] joined
07:58
He||Raiser|CFR- joined
07:59
He||Raiser|CFR- left
08:06
adc_Penner left
08:15
[particle]1 left
08:16
ejs joined
08:18
adc_Penner2 left
08:29
tomyan joined
08:44
lambdabot left,
r0bby left,
pugs_svn left,
lumi left,
baest_ left,
fullermd left,
yahooooo left,
buu left,
alech left,
Maddingue left,
wolverian left,
zamolxes left,
sri_work left,
apeiron left,
smg left,
lisppaste3 left,
ting left,
clkao left,
allbery_b left,
diakopter left,
[particle] left,
ruoso left,
Jedai left,
Khisanth left,
|Jedai| left,
aindilis left,
gantrixx left,
bennymack left,
cxreg left,
jiing_ left,
avar left,
c1sung left,
tomyan left,
tcliou left,
jan_ left,
jfredett left,
bjorn` left,
spinclad left,
idemal left,
SamB left,
Tene left,
integral left,
cj left,
kanru left,
mallory_ left,
Patterner left,
elmex left,
smtms left,
pmurias left,
REPLeffect left,
literal left,
jjore left,
mtve left,
kane_ left,
PerlJam left,
iblechbot left,
PZt left,
orafu left,
sirhc left,
TreyHarris left,
drbean left,
mj41 left,
kolibrie left,
xuser left,
preflex left,
TimToady left,
Guest16015 left,
falesca left,
hcchien left,
meteorja1 left,
ilbot2 left,
moritz_ left,
Juerd left,
IRSeekBot left,
buubot left,
kst`` left,
cookys left,
simcop2387 left,
silug left,
c9s left,
rakudo_svn left,
Guest70230 left,
Caelum left,
japhb left,
yves left,
jiing left,
audreyt left,
pasteling left,
jferrero left,
p6eval left,
pjcj left,
Southen_ left,
bennymac1 left,
rhr left,
nothingmuch left,
pmichaud left,
kcwu left,
gbacon left,
BinGOs left,
funktio left,
cognominal left,
cosimo left,
bacek left,
insert_coins left,
charsbar left,
tewk_ left,
felipe left,
Aisling left,
Gothmog_ left,
speckbot left,
Grrrr left,
szbalint_ left,
nnunley_ left,
broquaint left
08:45
perlbot left,
jrockway left,
beppu left,
StephenPollei left,
ejs left,
cls_bsd left,
dalek left,
sunnavy left,
ewilhelm left,
obra left
08:47
TimToady joined,
AzureStone joined,
tomyan joined,
ejs joined,
[particle] joined,
iblechbot joined,
zamolxes joined,
cosimo joined,
sri_work joined,
kanru joined,
kst`` joined,
BinGOs joined,
mallory_ joined,
jferrero joined,
Patterner joined,
elmex joined,
ruoso joined,
bacek joined,
cookys joined,
p6eval joined,
smtms joined,
Jedai joined,
insert_coins joined,
PZt joined,
orafu joined,
tcliou joined,
pjcj joined,
Southen_ joined,
jan_ joined,
pmurias joined,
simcop2387 joined,
Khisanth joined,
bjorn` joined,
gantrixx joined,
jfredett joined,
charsbar joined,
apeiron joined,
sirhc joined,
lambdabot joined,
TreyHarris joined,
cls_bsd joined,
drbean joined,
r0bby joined,
tewk_ joined,
smg joined,
lisppaste3 joined,
mj41 joined,
|Jedai| joined,
felipe joined,
irc.freenode.net sets mode: +o TimToady,
silug joined,
aindilis joined,
REPLeffect joined,
literal joined,
cognominal joined,
c9s joined,
Aisling joined,
perlbot joined,
Gothmog_ joined,
speckbot joined,
StephenPollei joined,
funktio joined,
bennymac1 joined,
nothingmuch joined,
broquaint joined,
audreyt joined,
yves joined,
japhb joined,
jiing joined,
rakudo_svn joined,
Guest70230 joined,
pasteling joined,
yahooooo joined,
wolverian joined,
baest_ joined,
buu joined,
Maddingue joined,
Grrrr joined,
hcchien joined,
preflex joined,
kolibrie joined,
falesca joined,
buubot joined,
IRSeekBot joined,
ilbot2 joined,
clkao joined,
bennymack joined,
ting joined,
allbery_b joined,
avar joined,
jiing_ joined,
cxreg joined,
rhr joined,
mtve joined,
kane_ joined,
SamB joined,
integral joined,
jjore joined,
fullermd joined,
pugs_svn joined,
cj joined,
Tene joined,
diakopter joined,
moritz_ joined,
kcwu joined,
alech joined,
c1sung joined,
meteorja1 joined,
lumi joined,
jrockway joined,
beppu joined,
nnunley_ joined,
szbalint_ joined,
spinclad joined,
Guest16015 joined,
gbacon joined,
idemal joined,
ewilhelm joined,
sunnavy joined,
obra joined,
dalek joined,
pmichaud joined,
Juerd joined,
PerlJam joined,
Caelum joined,
xuser joined
08:49
masak joined
08:50
mallory__ joined
08:53
masak left,
pmichaud left,
rhr left,
pjcj left,
Southen_ left,
bennymac1 left,
nothingmuch left,
gbacon left,
p6eval left,
kcwu left,
jferrero left
08:55
nnunley_ left,
pjcj joined
08:56
szbalint_ left
09:01
schmalbe joined,
AzureStone_ left
09:04
szbalint joined,
masak joined,
jferrero joined,
p6eval joined,
Southen_ joined,
pmichaud joined,
gbacon joined,
kcwu joined,
rhr joined,
bennymac1 joined,
nothingmuch joined
09:05
nnunley joined
09:08
mallory_ left
09:09
kst``` joined,
kst`` left,
bjakb joined
09:30
mallory__ left
09:31
Maghnus joined
09:39
masak left
|
|||
| ruoso | pmurias, Can't locate object method "term__S_386identifier" via package "STD" at ../../src/perl6/STD.pm line 1002. | 09:42 | |
| pmurias, does that mean I'm missing compiling something? | |||
|
09:52
bacek left
09:56
bacek joined
10:07
sri_work_ joined
10:09
[particle] left
10:12
sri_work left
10:13
[particle] joined
10:21
Khisanth left,
Khisanth joined
10:28
nothingmuch left
10:36
ruoso left
10:38
kst``` left
10:39
kst``` joined
10:41
bacek left
10:43
bacek joined
11:07
bacek left,
bacek joined,
rdice joined
11:12
ruoso_ joined
11:15
araujo joined
11:26
rdice_ joined
11:27
rdice_ left
11:29
bacek left
11:32
zamolxes left,
iblechbot left
|
|||
| ruoso_ | if a multi can be used anywhere a sub can be used, that means it should implement postcircumfix:<( )> | 11:49 | |
| but considering lexical variants | |||
| the implementation of that specific multi is not aware of all the variants available... it's only aware of the ones declared in the same scope | 11:50 | ||
| this might mean: | |||
| 1) that it goes looking in the CALLER for other variants | |||
| 2) that calling postcircumfix:<( )> directly on the object means looking for variants only in that multi object ignoring all the lexical variants | 11:52 | ||
| 3) that multi is not really a Code, but just a container, and therefore, it doesn't implement postcircumfix:<( )> at all | |||
| I should say that I'm assuming the (multi)sub dispatch is something external to each sub.... | 11:53 | ||
| I just realized that Multi is not even a type... | 12:05 | ||
| hmmm... | |||
|
12:06
kst``` left
12:07
kst``` joined
|
|||
| ruoso_ | bbiab & | 12:09 | |
|
12:09
ruoso_ left
12:12
ruoso__ joined,
ruoso__ is now known as ruoso_
12:13
Bzek joined
12:16
cognominal left,
zamolxes joined
12:25
insert_c1ins joined
|
|||
| ruoso_ | I think I'll assume a multi is just a container... let's see if #parrot folks have something to say about it... | 12:25 | |
|
12:31
aindilis left,
aindilis joined
12:41
insert_coins left
12:50
apeiron left
12:52
iblechbot joined
12:55
alester joined
12:59
Lorn joined
13:01
alester left
13:04
jferrero left
13:06
ashizawa left
|
|||
| ruoso_ later & | 13:14 | ||
|
13:14
ruoso_ left,
alanhaggai joined
13:18
pmurias_ joined
|
|||
| pmurias_ | @tell ruoso you should recompile STD had exactly the same error when i used an old one and rm -fr lex | 13:19 | |
| lambdabot | Consider it noted. | ||
|
13:19
pmurias_ left
13:20
schmalbe left
13:22
PZt left
13:34
Pzt joined
13:39
kst``` left
13:40
kst``` joined
13:46
silug left
13:57
TJCRI joined
13:59
sri_work_ left
14:00
TJCRI left
|
|||
| rakudo_svn | r31946 | pmichaud++ | [rakudo]: spectest-progress.csv update: 204 files, 4380 passing tests | 14:03 | |
|
14:03
TJCRI joined,
sri_work joined
|
|||
| rakudo_svn | r31947 | pmichaud++ | [rakudo]: Don't use leading '::' for storing generic type lexicals. | 14:03 | |
| r31947 | pmichaud++ | This gets us closer to supporting interpolated namespaces. | |||
|
14:31
cognominal joined
14:47
silug joined
14:52
ejs left
14:58
jferrero joined
14:59
[particle]1 joined
|
|||
| rakudo_svn | r31948 | pmichaud++ | [rakudo]: Eliminate <generic_binder> and remove '::' as a <sigil>. | 15:09 | |
|
15:09
[particle]2 joined
15:10
[particle] left
15:12
pedrob joined
15:18
zamolxes left
15:20
kst``` left
15:21
kst``` joined
15:27
[particle]1 left
15:29
silug left
15:30
cosimo left
15:39
silug joined
15:51
pedrob left
15:58
silug left
16:00
armagad joined
16:02
jan_ left
16:04
alanhaggai left,
hercynium joined
16:10
jan_ joined
16:14
armagad left
16:20
jhorwitz joined
16:23
pedrob joined,
kanru left
16:24
pyrimidine joined,
justatheory joined
16:26
kanru joined
16:34
alanhaggai joined
16:37
pedrob left
16:38
alester joined
16:40
nothingmuch joined
16:43
OsamaK joined,
pedrob joined
16:45
kane_ left,
kane_ joined
|
|||
| TimToady | so should it be ceil or ceiling? or ā...ā :) | 16:49 | |
| moritz_ | the answer is usually "yes" ;) | 16:51 | |
| TimToady | pugs implements the first two o_O | ||
|
16:52
jferrero left
|
|||
| [particle]2 | ceiling, please | 16:56 | |
| we don't say floo for floor | |||
|
16:56
[particle]2 is now known as [particle]
16:59
pmurias_ joined
|
|||
| TimToady | but we say abs for absolute and sin for sine | 17:03 | |
| sin for sine is completely as(sin)ine | 17:04 | ||
| I can kinda understand abs for absolute though | 17:05 | ||
|
17:05
adc_Penner joined
|
|||
| moritz_ | and 'sin' is what you always use in math anyway | 17:05 | |
| TimToady | but the fact is that mathematicians write "sin" | ||
| but not "ceil" | 17:06 | ||
| they use ā...ā | |||
| 'course we've made it impossible to use |$x| :) | |||
| moritz_ | I did a quick search with google code search for \bceil\b and \bceiling\b | 17:07 | |
| ceiling: 121k | |||
| TimToady | well, given that it's ceil in C | ||
| moritz_ | ceil: 256k | 17:08 | |
| TimToady | can you tell what languages use ceiling? | ||
| or is it all in comments? :) | |||
| moritz_ | it seems most is user defined, or in weird programming langues that I don't recognize ;) | 17:09 | |
| public class Ceiling extends NumericFunction { | |||
| TimToady | heh | ||
| moritz_ | that might be over-engineering - but of couse I don't know that | 17:10 | |
| *course | |||
|
17:10
OsamaK left
|
|||
| TimToady | well, I think huffman probably calls for ceiling | 17:11 | |
|
17:11
ruoso joined
|
|||
| TimToady | and looking at how it's used in t/, I'm sure of it | 17:13 | |
| push @p, $x unless grep { $x % $_ == 0 }, 2..ceil sqrt $x; | |||
|
17:13
ZuLuuuuuu joined
|
|||
| ruoso | TimToady, is it really impossible to catch |$x| as different from |$x ? | 17:14 | |
| lambdabot | ruoso: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
| TimToady | ceil sqrt sounds like some kind of sea creature | ||
| It's possible with ferocious backtracking | |||
| but we don't do ferocious backtracking | |||
| ruoso | hmm... ok... | 17:15 | |
| (we could always change '|' to something not used by math) | |||
| TimToady | |$x + $y + $z| | ||
|
17:15
pedrob left
|
|||
| moritz_ | 2+|$x|+3 # a junction, or a sum? | 17:15 | |
| TimToady | could have a +|...| circumfix, I suppose | ||
| and a -|...| circumfix | 17:16 | ||
| moritz_ | I don't think it's a very good idea | ||
| TimToady | me too | ||
| [particle] | so leave it to someone else to do it :) | 17:17 | |
| TimToady | plus we've already taught mathematicians to write abs when talking to computers :) | ||
| ruoso | heh | ||
| [particle] | abs-minded professors? | ||
| TimToady cringes | |||
| ruoso | pmurias, mildew still fail to parse test-mildew/pure_... | 17:18 | |
| pmurias, it gives me another error... but it still fails... | |||
| TimToady | it might be that capture interpolation is too short, huffmanwize | ||
| pmurias_ | ruoso: maybe, i'm the one with the old copy, checking... | 17:20 | |
| ruoso: did you rm -fr v6/mildew/lex/ | |||
| ruoso | pmurias, yes | ||
|
17:20
Juerd_ joined
|
|||
| ruoso | pmurias_, kill your ghost, please ;) | 17:20 | |
| pmurias_ | the irssi is run on a machine i don't can't ssh to and i'll have access to in ~2weeks | 17:21 | |
|
17:22
Juerd left
|
|||
| ruoso | pmurias_, you can always /msg NickServ ghost | 17:22 | |
| pmurias_ | hmm? | ||
| ruoso | pmurias_, /msg NickServ ghost pmurias yourpasswd | ||
| [particle] | that will remove pmurias, then you can /nick pmurias | 17:23 | |
| and /msg nickserv identify pmurias password | |||
|
17:23
pmurias left
|
|||
| ruoso | [particle], hi... have you seen my comments on multi? | 17:23 | |
|
17:23
pmurias_ is now known as pmurias,
pmurias_ joined
|
|||
| [particle] | ruoso: not anything since last wednesday | 17:24 | |
| ruoso | irclog.perlgeek.de/perl6/2008-10-14#i_620509 | ||
| lambdabot | Title: IRC log for #perl6, 2008-10-14 | ||
| ruoso | I'd really appreciate some thoughts on that... | ||
| pmurias | ruoso: the one in mildew/t is the one that actually parses the one in test-mildew is the intenended test | 17:25 | |
| lambdabot | pmurias: You have 3 new messages. '/msg lambdabot @messages' to read them. | ||
| ruoso | pmurias, oh... ok... | ||
| [particle] | ruoso: aren't all subs multis unless declared only? | ||
|
17:25
ZuLuuuuuu left
|
|||
| pmurias | [particle]: no | 17:25 | |
| [particle] rereads the spec | 17:26 | ||
|
17:26
apeiron joined
|
|||
| ruoso | [particle], but it doesn't change the problem | 17:26 | |
| [particle], either way you have lexically-declared variants... | |||
| pugs_svn | r22606 | lwall++ | [S29] settle on "ceiling" | 17:27 | |
| ruoso wonders if some module could define |$x| to be a syntax for abs() and redefine junctions and capture interpolation to something else... | 17:28 | ||
| pmurias | ruoso: the way I view it a lexical variant creates a new multi | ||
| ruoso | pmurias, yes... I see that way too... but the problem is, what does $multi.postcircumfix:<( )> do? | ||
| pmurias | ruoso: |$x| isn't particularly good syntax | ||
| ruoso | for general code, yes... but for some more specific use, maybe not | 17:29 | |
| pmurias | it takes into account all the variants in place when $multi = &multi happened | ||
| ruoso | pmurias, that would mean creating a clone for the multi at every new re-declaration | 17:30 | |
| (sort of, but the consequence would be the same) | 17:31 | ||
| pmurias | ruoso: yes, but it's better for the creation to be expensive than for the call | 17:33 | |
| ruoso | well... I was considering that as a possible optimization... | ||
| I mean... | 17:34 | ||
| considering sub dispatch fallback to the package lookup | |||
| or even CANDO | |||
| pmurias | does it? | ||
| ruoso | yes... sub dispatch is 'no strict' | ||
| pmurias | no | ||
| ruoso | pugs: &Foo::bar := sub { 1 }; module Foo { sub baz { bar() } }; say Foo::baz(); | 17:35 | |
| p6eval | pugs: OUTPUT[1ā¤] | ||
|
17:36
ejs joined
|
|||
| pmurias | ruoso: S02:2824 | 17:37 | |
| ruoso | pmurias, I'm not sure I see what you mean | 17:38 | |
|
17:38
ejs is now known as ejs0
17:39
jferrero joined
|
|||
| [particle] tries to follow, but is on the phone... | 17:39 | ||
| ruoso | pmurias, "The postdeclaration may be in any lexical or **package** scope" | ||
| pmurias | they are checked at compile time | 17:40 | |
| ruoso | pugs: module Foo { sub baz { bar() } }; say Foo::baz(); INIT { &Foo::bar := sub { 1 } } | 17:41 | |
| p6eval | pugs: OUTPUT[1ā¤] | ||
| pmurias | S02:2831 | ||
| ruoso | hmmm... ok... I think I see what you mean... | 17:43 | |
| but... | |||
| does that mean that no new variants can be added in runtime to a pre-declared proto? | |||
| I would doubt that | |||
| oh... wait... but in that case, it would be to an already known multi object.. | 17:44 | ||
| pmurias | if the multi was a package scoped one you could propably change it | ||
| ruoso | if Foo::bar() is a multi, what happens if you &Foo::bar := somethingelse()? | 17:45 | |
| does it add a variant? | 17:46 | ||
| or does it replace the entire multi with all variants by a new thing? | |||
|
17:48
pedrob joined
|
|||
| pmurias | i think it replaces the entire multi | 17:48 | |
|
17:48
kst``` left
17:49
kst``` joined
|
|||
| ruoso | so it seems it needs to be late-dispatched anyway... | 17:53 | |
| and the cloning doesn't seem to solve the problem | 17:54 | ||
|
17:55
pedrob_ joined
|
|||
| pmurias | what's the problem btw ;) | 17:55 | |
|
17:55
pedrob_ left
|
|||
| ruoso | the problem is: 1) Multi isa Code? 2) .() looks in the CALLER? | 17:56 | |
|
18:01
tomyan left
18:02
mncharity joined
|
|||
| mncharity | @tell pmurias re mildew as duplication (last night), I was wrong. eg, elf doesn' | 18:02 | |
| lambdabot | Consider it noted. | ||
| pmurias | 2) .() looking in CALLER seems too magical for me, and i think Multi isa Code as treating it an object instead of a bunch of variants allows you to do fancy stuff with it such as using it as a callback | 18:03 | |
| lambdabot | pmurias: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
| pmurias | mncharity: hi | ||
| mncharity | t duplicate rakudo. focus on "usable and p6" vs "solid foundation". distinct impacts on language dev, different pragmatics. | ||
| hi pmurias. :) | |||
|
18:03
ejs0 left
|
|||
| ruoso | pmurias, so you think .() on the multi object causes an invocation on the variants inside that multi object only? | 18:04 | |
| pmurias | yes | ||
| mncharity | potential to share ideas, code, blur together. similarly, mildew compliments elf's currently narrow focus on getting to bootstrap. | ||
| pmurias | ruoso: but i might not see the big picture | ||
| mncharity: mildew tries to express everything in terms of method call | 18:05 | ||
| * calls | |||
| mncharity | witness yesterday's(?) kludgery to force temp() back to being a scope_declarator, because updating to current spec isn't critical path. | ||
| ruoso | pmurias, in my head it's one of 1) traverse CALLER, 2) call only this variants or 3) doesn't implement .() at all | ||
|
18:05
bjakb left
|
|||
| ruoso | I'd vote for 3 or 2 | 18:06 | |
| mncharity | re calls, yes. no method calls existed when elf's version was started, and until bootstrap and macros, doing something more plausible doesn't seem critical path. | ||
| so, I was wrong to characterize it as duplicated effort. | |||
| back later. err, or perhaps more likely tomorrow. cheers. | 18:07 | ||
| pmurias | mncharity: could common lisp handle doing everything in an OO way? | ||
|
18:07
Bzek left
|
|||
| mncharity | really have to run. | 18:07 | |
| pmurias | ok | ||
| TimToady | what do multis have to do with caller? | 18:08 | |
| it's all lexical | |||
| ruoso | TimToady, the question is if Multi isa Code in the first place... | 18:09 | |
| mncharity | briefly, there are CL instance-based oo impls with good performance. hoping to perhaps take ideas/code from one of them. but, different backends, different properties. | ||
| TimToady | define Multi | ||
| mncharity | cheers. & | ||
|
18:09
mncharity left
|
|||
| ruoso | TimToady, the stuff that holds the variants | 18:09 | |
| where each variant is a code object | |||
| TimToady | we can have &code objects that represent multiple candidates | 18:10 | |
| ruoso | yes... but it can't represent all the candidates | ||
| TimToady | sounds like Multi is just a Code that does a null .assuming :) | 18:11 | |
| ruoso | the problem is really about having several &code objects that represent different multiple candidates | ||
| and what happens when you &code.() on one of that objects | 18:12 | ||
| TimToady | what do you think &foo.assuming() should return, besides all the candidates? | ||
| moritz_ | or maybe &code is really a junction of multis? | ||
| ruoso | itself? | ||
|
18:12
schmalbe joined
|
|||
| pmurias | buying food& | 18:13 | |
| ruoso | moritz_, that's not the issue... | ||
| the issue is the fact that we have several "variant container"s | |||
| TimToady | any &code represents one or more candidates | ||
| ruoso | but the sub dispatch need to find all declarations of &code in the lexical scope | 18:14 | |
| which mean several objects holding each one several variants | |||
| the question is what happen when you &code.() on one of those specific objects... | |||
| TimToady | well, the compiler finds the lexical variants, not the dispatch | ||
| the dispatch just needs to look at the available candidates in &code produced by the compiler and call one of them | 18:15 | ||
| ruoso | TimToady, can't a new variant for infix:<+> be added at runtime? | ||
| doesn't it affects the code globally? | 18:16 | ||
| TimToady | yes, in which case you need to recalculate, but I think of that as recaching, not as dispatch | ||
| ruoso | right... so let's leave caching aside by now | ||
| TimToady | it affects anything that can see it lexically, where global is "most lexical" | ||
| s/most/outermost/ | |||
| pmurias | TimToady: is there a way to prevent adding a new variant at runtime | 18:18 | |
| ? | |||
| TimToady | don't let your candidate list generate from any namespaces that can be changed at run time | ||
| if you put a proto in your outermost lexical, it hides anything outside it | 18:19 | ||
| ruoso | hmmm | ||
|
18:19
rdice_ joined
|
|||
| moritz_ | a proto in an *outer* scope hides something? | 18:19 | |
| moritz_ finds that confusing | 18:20 | ||
| ruoso | moritz_, hides the outer outer scope | ||
| pmurias | TimToady: and eval("multi foo {...}")? | ||
| TimToady | an "only" sub also hides anything outside of it | ||
| without a scope qualifier, it goes into your current package | |||
| which gets looked at somewhere just outside your outermost ordinary lexical scope, I thing | 18:21 | ||
| *think | |||
| ruoso | TimToady, I'm assuming the dispatcher is the one that looks in the package | 18:22 | |
| TimToady, but pmurias pointed that pugs is wrong about being 'no strict' on the sub names... | |||
| TimToady | so, outer scopes go something like PROCESS < GLOBAL < prelude-lexical < package < file-lexical < block-lexicals, give or take | 18:23 | |
| ruoso | I still see that as two different axes | ||
| TimToady | which axis is $foo on? | 18:24 | |
| ruoso | ordinary lexical scope, which ends in the prelude-lexical | ||
| TimToady | which includes package | ||
| ruoso | not really... | 18:25 | |
|
18:25
pedrob left
|
|||
| TimToady | if your current package includes $foo, you see it | 18:25 | |
| whether or not it was declared with "our" | |||
| ruoso | because 'our $foo' creates a local bind to $package::foo | ||
| TimToady, which is the other way to declare $foo, besides 'our $foo'? | 18:26 | ||
| (and besides my $foo also, of course) | |||
| TimToady | package variables don't need to be declared | ||
| $::foo = 42 is enough | |||
| ruoso | but then you need to access them through the package, don't you? | ||
| and that's a different lookup | |||
|
18:27
abz_ joined
|
|||
| TimToady | the current package is implicit | 18:27 | |
| PerlJam | wait a second ... you still get a warning with stricture, yes? | ||
| TimToady | but yes, $foo as an rvlaue fails under strict | ||
| PerlJam | ah. ok | ||
| ruoso | so... {package Foo; $bar = 1} is valid... | 18:28 | |
| PerlJam goes back to lurking | |||
| TimToady | but if foo() doesn't call through the package, there's no way to override prelude at run time with a multi | ||
| since all lexical scopes freeze after compilation | |||
| ruoso | TimToady, that's the part of sub dispatch being 'no strict'... maybe S02 is wrong... | 18:29 | |
| ruoso actually meant that as a question... is {package Foo; $bar = 1} valid? | |||
| TimToady | if prelude defines a proto multi, then you can't see any multi of that name in GLOBAL | ||
| under no strict it's valid | 18:30 | ||
|
18:30
pedrob joined
|
|||
| ruoso | TimToady, right... so it falls back to package lookup under 'no strict' | 18:30 | |
| TimToady | but $::bar = 1 is probably better style in Perl 6 | ||
| ruoso | or "our $bar = 1' | 18:31 | |
| which is probably even better | |||
| TimToady | but that can have ramifications if there are other packages in scope | ||
| and those ramifications may be good or bad | |||
| so yes, "probably" :) | |||
| ruoso | that's the part of "under no strict, it *falls back* to the package" | 18:32 | |
| which means that it will only lookup in the package if no strict *and* if no lexical is found | |||
| TimToady, but that brings us back to the same problem... | 18:33 | ||
| TimToady | whereas &foo is looked up in the order I listed above, more or less | 18:34 | |
| ruoso | right... I just try to keep my mind strict... | ||
| 'no strict' will be handled later... | |||
| package Foo { proto foo; package Bar { my multi foo (Int $a) {1} } } | 18:35 | ||
|
18:36
silug joined
|
|||
| ruoso | TimToady, the above example shows the issue I'm trying to address... | 18:36 | |
| the lexical declaration 'my multi foo' needs to be stored somewhere different from the outer 'proto foo' | |||
| because it's lexical | 18:37 | ||
| unless I'm just crazy and that is simply not supporte | |||
| TimToady | probably proto should be limited to lexical scope | ||
| ruoso | TimToady, that meaning the above example is not valid? | 18:38 | |
| TimToady | well "proto foo;" by itself is illegal syntax | 18:39 | |
| regardless of whether we decide to require "my" | |||
| and if you have "proto foo () {...}" then the multi would be an inconsistent signature | 18:40 | ||
| a bare "my proto foo {...}" would merely hide any outer foo without constraining the sig | |||
| ruoso confused... | 18:44 | ||
| package Foo { proto sub foo ($a) {...}; package Bar { my multi foo (Int $a) {...} } } | 18:45 | ||
| TimToady, the above example seems more on-the-point... | |||
| TimToady | that looks fine in the sigs, since Int is more restrictive | 18:47 | |
| ruoso | right... but where is the inner variant stored? | ||
| TimToady | but as I say, we might require "my" on the proto to prevent run-time mods | ||
| either that, or the compiler can't actually rely on a proto in a package to mean anything | 18:48 | ||
| so it might as well not be there | |||
| the main point of a proto is to tell the compiler what it can assume for optimization | |||
| ruoso | right... let me try to be even more specific... | ||
| TimToady | otherwise the name hiding can be done with an "only" sub | ||
| ruoso | package Foo { my multi foo (Str $a) {...}; package Bar { my multi foo (Int $a) {...} } } | 18:49 | |
| TimToady | illegal | ||
| ruoso | oh... right... | ||
| so there isn't lexically-scoped variants for a multi | |||
| TimToady | oh, sorry | 18:50 | |
| misread | |||
| that's fine | |||
| and yes, those would be considered both viable candidates | |||
| and they compete on equal terms | 18:51 | ||
| ruoso | but on the outer scope, only the outer declaration is seen | ||
| TimToady | true | ||
| ruoso | rigth... | ||
| that means we have two different storage for the variants | |||
| TimToady | yes, &foo means two different things | ||
| ruoso | what does it mean in the inner scope? | 18:52 | |
| TimToady | it means both candidates are used if you call foo($x) | ||
| ruoso | that's sub dispatch | ||
| TimToady | multi dispatch is sub dispatch | ||
| ruoso | yes yes... | ||
| but I mean... | |||
| foo(); and &foo.() would mean different things? | 18:53 | ||
| TimToady | no | ||
|
18:53
hercynium_ joined
|
|||
| ruoso | so postcircumfix:<( )> needs to look in the caller scope for the other available variants | 18:54 | |
| TimToady | there is no "other", either the object knows it is dealing with more than one candidate, or it is dealing with only one candidate | 18:55 | |
| ruoso | TimToady, so it implicitly references the outer multi from inside it? | ||
| TimToady | the reason we have "only" subs is so that at least some &foo can know they have only one candidate at compile time | ||
| &foo is inside neither multi | 18:56 | ||
| if you will, &foo is the only sub that delegates to all multis of the same name that are visible | 18:57 | ||
| and if there is only one candidate, it can be coelsced with the the only at compile time | 18:58 | ||
| s/one/one possible/ | |||
| *coalesced | |||
| but &foo is the "short name" abstraction, basically, and it might or might not represent multiple actual Code objects | 18:59 | ||
| ruoso | that way &foo.() on a multi is undetermined | 19:00 | |
| ? | |||
| TimToady | or maybe &foo is the Code object, and there are multiple Sub objects. not picky about the names | 19:01 | |
| undetermined? | |||
|
19:01
azawawi joined
|
|||
| TimToady | &foo.() is the same as foo() | 19:01 | |
| azawawi | rakudo: say "ping" | ||
| p6eval | rakudo 31953: OUTPUT[pingā¤] | ||
| ruoso | what do you mean by " it might or might not represent multiple actual Code objects"? | 19:02 | |
| TimToady | once you've use .() it must find a single code object and call it | ||
| *used | 19:03 | ||
| ruoso | right... but bare &foo ? | ||
| TimToady | bare &foo represents all candidates of that short name (unless otherwise bound) | ||
| &foo := &bar.assuming(42) can put a different candidate list into &foo | 19:04 | ||
| pmurias | all candidates as seen from the lexical scopes where it appears? | 19:05 | |
| ruoso | or all candidates including the ones that can be added at run-time in the package? | ||
| TimToady | if the package names are visible | 19:06 | |
| which depends on where the proto (if any) is declared | |||
| ruoso | just to make clear... that is the key point to determine if the multi sub dispatch belongs inside the sub object or outside of it... | ||
| TimToady | which is why I put the package inside prelude | ||
|
19:07
kst``` left
|
|||
| TimToady | all Code objects respond to .(), but some of them must dispatch to a shorter list of candidates. | 19:07 | |
|
19:08
kst``` joined
|
|||
| TimToady | whether a Code object is singular or plural is hidden info | 19:08 | |
| ruoso | so the innermost declaration of a name should respond to .() including all the outermost candidates... | ||
| TimToady | yes, and it would be good to include the innermost candidate as well :) | 19:09 | |
| ruoso | :) heh | ||
| ok... | |||
| so the dispatch belongs inside the sub, not outside... | 19:10 | ||
| TimToady | which probably means that the infrastructure uses some hidden .invoke rather than overloading .() | ||
| ruoso | TimToady, it actually overloading .() just fits | 19:11 | |
| TimToady | fine if it works | ||
| ruoso | s/it// | ||
| and the invocation only see the innermost declaration | |||
| TimToady | whenever I get confused about roles I take it as a sign that I should let the implementations fight it out | 19:12 | |
| &foo is intended to be a simplifying abstraction, yes | |||
| it represents the current overloading | |||
| ruoso | ohwkay | ||
| TimToady | lexically current | 19:13 | |
| where that might or might not extend out through a run-time modifiable package | |||
| ruoso | so my plan is... | ||
| TimToady | in which case the cache has to be invalidatable | 19:14 | |
| ruoso | every multi declaration creates a Multi object that holds all the candidates declared in that level | ||
| an additional "our multi foo" adds a candidate to an existing multi (or creates the global one if non-existant) | 19:15 | ||
| TimToady | note also that multies can be postdeclared in a scope | ||
| ruoso | TimToady, which then mean adding more candidates to the same Multi object | ||
| TimToady | yes | 19:16 | |
| and all the &foo in that block refer to the same Multi | |||
| ruoso | yes | ||
| an inner Multi holds a reference to the lexical scope in which it was declared, giving a path to access the outer Multi object | |||
| TimToady | but also note that postdeclarations can come from outer scopes as well :) | ||
| ruoso | TimToady, the key is keeping late-dispatch | 19:17 | |
| and having cache as optimization | |||
| TimToady | right | ||
| or, if not run-time late, at least CHECK-time late | 19:18 | ||
| ruoso | 'our multi foo' in an inner scope means adding a local alias to the global Multi object that now has one more candidate | ||
| TimToady | and run-time late if packages are involved | ||
| ruoso | hmm... | ||
| actually... | |||
| not really | |||
| (not what you've said, but what I've said | 19:19 | ||
| TimToady | biab & | ||
| ruoso | 'our multi foo' in an inner scope means creating an empty Multi object, and the global Multi object would have one more candidate | 19:20 | |
| anyway... I think everything is settled now.. | 19:21 | ||
| pugs_svn | r22607 | particle++ | [t] add more 'is export()' trait tests | 19:22 | |
| rakudo_svn | r31954 | particle++ | [rakudo] add 'infix:=:=' and 'infix:!=:=' ops | 19:23 | |
|
19:23
schmalbe left
|
|||
| pugs_svn | r22608 | pmurias++ | [mildew] sigils are part of the variable's names | 19:23 | |
| rakudo_svn | r31955 | particle++ | [rakudo] refactor 'is export()' trait code to prepare for handling taglists | 19:24 | |
| pmurias | ruoso: does mildew --desugar --file t/pure_prototype_how.p6 work for you? | ||
| ruoso | yes... the output doesn't make much sense... | 19:25 | |
|
19:26
cathyal joined
19:28
bacek joined
|
|||
| pmurias | ruoso: --desugar prints out the IR before it is broken down into opcodes | 19:31 | |
| pugs_svn | r22609 | pmurias++ | [mildew] fixed my, --desugar uses mold {...} instead of {...} | 19:33 | |
| pmichaud | std: sub foo() is export(:DEFAULT :others) { ... } | 19:34 | |
| p6eval | std 22608: OUTPUT[parsedā¤] | ||
| pmurias | ruoso: it doesn't make sense as in not being clear what it is, containing bugs, or t/pure_prototype_how.p6 not making sense yet (as mildew can't handle some stuff yet) | 19:35 | |
|
19:39
jferrero left
|
|||
| pugs_svn | r22610 | pmurias++ | [mildew] infix:<=> with a method call on the left side | 19:44 | |
| pmurias | TimToady: STD parses anonymous methods incorrectly | 19:47 | |
| pmichaud | std: 3 + :a :b | ||
| p6eval | std 22610: OUTPUT[parsedā¤] | ||
| pugs_svn | r22611 | moritz++ | [t/spec] clarified where.t a bit, as suggested by TimToady++ | 19:55 | |
| r22612 | pmurias++ | [mildew] anonymous subroutines | 19:56 | ||
|
19:57
alanhaggai left
19:58
greatflamingfoo joined
|
|||
| azawawi | how can i autoflush $*OUT for prints in p6? | 19:58 | |
| moritz_ | did you look in S16? (I have no clue) | 19:59 | |
| azawawi | i only found a quick reference on it in draft S28 | 20:00 | |
| pugs_svn | r22613 | moritz++ | [t/spec] some unfudging for rakudo, [particle]++ | 20:01 | |
| azawawi | moritz_: 'print "your choice:"; my $foo = =$*IN' does not show anything until you press enter... | 20:06 | |
| moritz_ | azawawi: which implementation? | ||
| azawawi | moritz: rakudo & pugs | 20:07 | |
| moritz_: and =<> returns -1 on perl6 without waiting for input on rakudo | 20:08 | ||
| moritz_ | azawawi: yes, it's known to be b0rked :( | ||
|
20:13
ab5tract joined
20:15
[particle]1 joined
20:16
humo85 joined
20:17
humo85 left
20:19
justatheory left
20:20
justatheory joined,
rdice_ left
|
|||
| TimToady | pmurias: I believe I've found the problem--EXPR was reducing till @termstack had 1 term rather than until @opstack had 0 ops, so it never reduced unaries that were not otherwise forced | 20:20 | |
| testing | |||
| pugs_svn | r22614 | lwall++ | [STD] EXPR quit reducing too soon on unaries | 20:24 | |
| r22615 | moritz++ | [src/perl6/Makefile] don't rm -rf lex/ on every 'make'. | 20:26 | ||
| r22615 | moritz++ | Use /usr/local/bin/perl in Makefile, because that's what all the scripts use | |||
| r22615 | moritz++ | anyway. | |||
|
20:27
_Jedai_ joined,
Torment joined
20:28
zamolxes joined
20:31
[particle] left,
[particle] joined
20:32
jferrero joined,
adc_Penner left
20:42
ruoso left
20:44
Jedai left,
[particle]1 left,
|Jedai| left
20:50
meppl joined
21:01
jferrero left
21:06
jferrero joined
21:07
TJCRI left
21:11
Pzt left
21:12
spx2 joined
|
|||
| spx2 | :) | 21:12 | |
|
21:17
pmurias left
21:22
ab5tract left
21:23
kst``` left
21:24
kst``` joined
21:34
pyrimidine left
21:45
bacek left
21:48
azawawi left
21:52
[particle]1 joined
22:03
wknight8111 joined
22:09
[particle] left
22:18
iblechbot left
22:26
ruoso joined
22:38
hercynium left
22:40
alester left
22:47
silug left
22:48
hercynium_ left
22:52
jrockway left
22:54
pedrob left
|
|||
| meppl | good night | 22:55 | |
|
22:59
literal left
23:03
jrockway joined
23:06
literal joined
23:14
meppl left
23:16
explorer__ joined
23:17
jferrero left
23:24
dolmen joined
23:28
greatflamingfoo left
23:30
Limbic_Region joined
23:34
dolmen left
23:35
jrockway left
23:37
PZt joined
23:39
jrockway joined
23:46
kst``` left,
kst``` joined
23:49
Limbic_Region left
23:56
xuser left
|
|||