pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/ Set by TimToady on 25 January 2008. |
|||
00:05
thoughtpolice left
00:06
thoughtpolice joined
|
|||
meppl | good night | 00:32 | |
00:33
meppl left
00:38
polettix left
00:40
wknight8111 joined
|
|||
wknight8111 | Is Rakudo development still in the Parrot SVN at languages/perl6? | 00:41 | |
obra | I believe so | 00:43 | |
Tene | wknight8111: yes. | ||
wknight8111 | I've been having a lot of problems when testing Rakudo. Simple things like declaring and using variables fail | 00:46 | |
and I have the most recent version from the SVN, which is why I asked if it was the current development version | |||
Khisanth | svn log :) | 00:48 | |
00:49
justatheory left
00:52
justatheory joined
|
|||
wknight8111 | For instance, the following code fails: my $x = 5; say $x; | 00:54 | |
I'll either get an error that the second statement wasn't terminated correctly, or that there was specified scope for $x | 00:55 | ||
no specified scope * | |||
"No scope found for PAST::Var '$x'" | 00:56 | ||
01:03
Lorn joined
|
|||
ruoso | rakudo: my $x = 5; say $x; | 01:14 | |
exp_evalbot | OUTPUT[5ā¤] | ||
ruoso | wknight8111, are you sure you have it built right? | 01:15 | |
perl6: my $x=5; say $x; | |||
exp_evalbot | kp6: OUTPUT[5ā¤] | ||
..pugs: OUTPUT[5ā¤] | |||
..rakudo: OUTPUT[5ā¤] | |||
01:18
devogon left
|
|||
nothingmuch | @tell ruoso precisely.. it must be extened because you can't have every method call be implemented in terms of about 3 other method calls, it has to be faked at the lowest level, that's why it must be extended and not replaced | 01:23 | |
lambdabot | Consider it noted. | ||
wknight8111 | ruoso, I'm pretty sure I have it built right | 01:24 | |
i ran the makefile, no errors popped up | |||
although I am on Windows, so who knows what is considered "right" anymore | |||
nothingmuch | wknight8111: he's not in chan | 01:33 | |
dunno if he backlogs, but I'd use lambdabot | 01:34 | ||
01:42
sunnavy joined
01:46
achermov joined
|
|||
achermov | Is there a module that'll let me embed Perl code into web pages, PHP style? | 01:49 | |
01:54
adu joined
|
|||
wknight8111 | achermov, perl6 or perl5? | 01:57 | |
achermov | irrelevant now. I got an answer elsewhere. Thanks though. | ||
wknight8111 | no problem | ||
01:58
achermov left
02:02
zakame joined
02:04
eternaleye_ joined,
eternaleye left,
eternaleye_ is now known as eternaleye
02:21
adu left
02:23
lambdabot left
02:24
lambdabot joined
02:25
Jedai left
02:43
zakame_ joined,
zakame left
02:44
zakame_ is now known as zakame
03:04
zakame_ joined
03:05
zakame left,
zakame_ is now known as zakame
03:11
Auzon joined
|
|||
pugs_svn | r19884 | putter++ | [misc/red_STD] started circumfix support. "(2+3)*4" now barely works. | 03:22 | |
mncharity | fyi, it runs with off-the-shelf ruby (1.8, rather than the new 1.9). ruby std.rb will hand you a read-eval-print-loop to play with. currently parses almost nothing of course. | 03:25 | |
Auzon | What's red_STD? | 03:26 | |
mncharity | # A ruby transliteration of src/perl6/STD.pm | 03:28 | |
Auzon | Neat :) | ||
mncharity | basically, STD.pm currently runs by being highly massaged into p6 which runs on pugs. so you spend a great deal of time trying to work around pugs bugs, and the development process is slow. objective of red_STD is to be fully runable within a person week or two. to help shake down STD.pm, and perhaps be a front-end for something. | 03:32 | |
03:33
Andy_ joined
|
|||
mncharity | re Neat, :) yeah, could be. | 03:35 | |
03:45
zakame_ joined
03:46
alester left
03:51
zakame left,
zakame_ is now known as zakame
03:53
drbean joined
03:58
wknight8111 is now known as wknight-away
04:02
zakame_ joined
04:06
zakame left
04:19
zakame_ is now known as zakame
04:24
wknight-away left
04:27
eternaleye left
04:36
adu joined
04:39
chacha_chaudhry joined
04:41
chacha_chaudhry left
|
|||
pugs_svn | r19885 | putter++ | src/perl6/STD.pm: in UNIT, fixed typo in rule name. | 04:51 | |
04:52
thoughtpolice left
04:56
nerog left
05:14
drbean left
|
|||
pugs_svn | r19886 | putter++ | [misc/red_STD] can parse "3" from _TOP. also "3;4". tweaked eat_terminator. | 05:15 | |
05:19
zakame left
05:23
zakame joined
05:24
justatheory left
05:34
monomorph joined
05:36
mncharity left
05:52
monomorph left
05:57
zakame_ joined
05:59
zakame left
06:00
DarkWolf84 left
06:52
zakame__ joined
06:53
zakame__ is now known as zakame
06:59
devogon joined
07:02
eternaleye joined
07:03
zakame_ left
07:34
psapo joined
07:53
Aankhen`` joined,
iblechbot joined
07:57
drbean joined
08:00
polettix joined
08:01
zakame left,
zakame joined
08:15
polettix left
08:24
adu left
|
|||
moritz_ | @tell wknight8111 if you test rakudo, don't use the REPL loop for now, it causes rakudo to segfault on some variable declarations (known bug) | 08:27 | |
lambdabot | Consider it noted. | ||
08:42
meppl joined
08:45
blindfish joined
09:00
viklund joined,
zakame_ joined
09:04
zakame_ left
09:05
zakame_ joined
09:15
zakame left
09:21
zakame_ left
09:24
zakame joined
09:26
baest left
09:32
zakame_ joined
09:38
thepler_ joined
09:49
baest joined
09:50
zakame left
09:54
baest left
10:01
baest joined
10:07
IllvilJa joined
10:10
tooo joined
|
|||
wolverian | kp6: state $foo = 2; | 10:13 | |
exp_evalbot | r19886: OUTPUT[syntax error at - line 12, near ") ā¤;"ā¤syntax error at - line 18, near ","ā¤ (Might be a runaway multi-line '' string starting on line 16)ā¤syntax error at - line 21, near "1 }"ā¤Execution of - aborted due to compilation errors.ā¤] | ||
wolverian | hmm | ||
rakudo: state $foo = 2 | |||
exp_evalbot | OUTPUT[scope declarator 'state' not implemented at line 1, near "= 2"ā¤current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)ā¤called from Sub 'parrot;Perl6;Grammar;Actions;_block1295' pc 81842 (src/gen_actions.pir:2778)ā¤called from Sub | ||
..'parrot;Perl6;Grammar;Actions;_block1278' pc 80777 (src/gen_actions.pir:2358)ā¤ca... | |||
wolverian | does anything implement state yet? :( | ||
scsys.co.uk:8001/12729 I'm wondering whether this is what perl6 would do as well | |||
(jrockway noticed it) | 10:14 | ||
10:18
pbuetow joined
10:20
ebassi joined
10:24
ruoso joined
|
|||
moritz_ | wolverian: perl 5.10 does ;9 | 10:30 | |
pugs: state $foo = 3 | 10:31 | ||
exp_evalbot | RESULT[\3] | ||
10:33
zakame__ joined
|
|||
wolverian | moritz_, see the paste. I wanted to compare perl5 and perl6 in this respect | 10:33 | |
10:34
zakame__ is now known as zakame
|
|||
moritz_ | did you try pugs? | 10:35 | |
10:40
zakame_ left
10:53
zamolxes joined
|
|||
ruoso | hi | 10:54 | |
moritz_ | hi ruoso ;) | ||
obra | morning | ||
ruoso | well... it's monday... so... | 10:55 | |
moritz_ | ruoso: I see you found more followers ;) | ||
erm, commiters ;) | |||
ruoso | heh... | ||
I'm very happy by the fact that smop is getting into Perl 6 radar | |||
and specially happy to see #p5p people interested in it... | 10:56 | ||
obra | I'm happy about it too :) | ||
ruoso | @tell nothingmuch I'm not pretty sure I'm getting what you mean... :) | 10:58 | |
lambdabot | Consider it noted. | ||
11:00
zamolxes_ joined
11:02
zamolxes left
11:07
zamolxes joined
|
|||
ruoso | is there any documentation on what the API for Array and Hash must be? or are the implementations supposed to figure that out? | 11:07 | |
11:09
zamolxes_ left
11:10
funktio joined
11:15
zamolxes_ joined
11:17
zamolxes left
11:19
lisppaste3 joined
11:22
zamolxes joined
|
|||
cognominal_ | is there a for @argv -> $_, $i {} sometimes one wants to iterate but have a counter too | 11:24 | |
moritz_ | ruoso: in S29 there is an overview about available methods | ||
cognominal_ | arf, may be that means I get inti @arfv two by two | 11:25 | |
moritz_ | cognominal_: you'd use for @arv zip 0..* -> $a, $counter {...} | ||
11:25
zamolxes_ left
|
|||
cognominal_ | nice | 11:25 | |
I don't think about zip even if I learnt some haskell | 11:26 | ||
moritz_ | it will be a FAQ, trust me ;) | ||
cognominal_ | I read the synopses but not enough code, my perl6 is passive so far | 11:28 | |
STD.pm is good reading | |||
moritz_ | it's a harsh introduction, either way | 11:29 | |
11:29
zamolxes_ joined
|
|||
cognominal_ | but STD.pm a very good followup to the synopses | 11:29 | |
I am trying to translate Getopt/Obj.pir in a perl6 grokable by rakudo | 11:31 | ||
11:32
zamolxes left
|
|||
moritz_ | cognominal_: there is also ext/Getopt-{Long,Process,Std} in the pugs repo | 11:32 | |
cognominal_ | but none of them is an exact translation of Getopt/Obj.pir ? | 11:33 | |
11:36
zamolxes joined
11:39
zamolxes_ left
11:42
meppl left
11:44
zamolxes_ joined
11:46
zamolxes left
|
|||
moritz_ | I'd guess they're all hand coded | 11:48 | |
11:51
zamolxes joined
11:53
zamolxes_ left
|
|||
ruoso | moritz_, thanks | 11:54 | |
11:56
mj41 joined
11:58
zamolxes_ joined
|
|||
moritz_ | ruoso: I'll be at the German Perl Workshop this week... maybe I can ask some people if they are interested in smop, and where to get funding | 11:58 | |
ruoso | moritz_, that would be great | 11:59 | |
moritz_ | does thrading work atm? | ||
12:00
zamolxes left
|
|||
ruoso | in theory, yes... | 12:02 | |
I need to create a new test that deals with it, | |||
but all the code is supposed to be thread-safe | |||
that means you can have two threads running different interpreter instances | 12:03 | ||
and they can even call methods in objects they share | |||
moritz_ | ok, thanks | ||
12:05
zamolxes joined
12:08
zamolxes_ left
12:12
zamolxes_ joined
12:15
zamolxes left
12:20
zamolxes joined
12:22
kcwu joined
12:23
zamolxes_ left,
xinming joined
12:28
zamolxes_ joined
12:30
zamolxes left
12:35
zamolxes joined
|
|||
ruoso | I made a review in the REPR API, considering the realisation that "an Array is anything that identifies itself as one" -- www.perlfoundation.org/perl6/index....mop_oo_api -- as usual, any review is appreciated | 12:36 | |
lambdabot | Title: SMOP OO API / Perl 6 | ||
12:38
zamolxes_ left
12:41
cmarcelo joined
12:42
zamolxes_ joined
12:43
zamolxes left
12:47
ebassi left
12:49
zamolxes joined
12:50
ebassi joined
12:51
zamolxes_ left
12:54
zamolxes_ joined,
zamolxes_ left
12:58
zamolxes left
|
|||
pugs_svn | r19887 | ruoso++ | [smop] threading test added. And yes, it works :) | 13:00 | |
ruoso | moritz_, ^ | ||
13:00
lidden joined
13:01
zamolxes joined
|
|||
pugs_svn | r19888 | ruoso++ | [smop] now 09_threads.t have two rw threads and one ro thread... added a usleep also to make its more concurrent... | 13:06 | |
13:11
zamolxes_ joined
13:13
zamolxes left,
njbartlett left
13:15
njbartlett joined
13:17
zamolxes joined
13:21
zamolxes_ left
13:27
zamolxes left
13:32
Psyche^ joined,
Psyche^ is now known as Patterner
13:38
njbartlett left
13:43
renormalist joined
13:49
Zygo joined
13:56
andara joined
13:57
Lorn left,
Lorn_ joined
14:01
Andy_ left,
drbean left
14:04
monomorph joined
14:12
renormalist left
14:14
Jedai joined
14:26
stevan_ joined
14:56
ebassi is now known as ebassi|afk
14:58
alester joined,
andara left
14:59
jhorwitz joined
15:01
zamolxes joined
15:03
manfred joined
15:05
jferrero joined
15:12
chris2 joined
15:21
zamolxes left
15:24
viklund left
15:26
test left,
viklund joined
15:33
PerlJam joined
|
|||
pugs_svn | r19889 | ruoso++ | [smop] added the interpreter %p in the 09_threads.t test output to show that the code is being run by different threads. | 15:38 | |
15:41
rdice joined
15:46
zamolxes joined
15:54
ilbot2 joined
15:56
Auzon left,
moritz joined,
moritz is now known as moritz_
|
|||
ruoso | moritz_, did you see the new test? | 15:57 | |
moritz_ | ruoso: no, sorry, disconnect and all :/ | ||
ruoso | test/09_threads.t | ||
16:03
ebassi|afk is now known as ebassi
|
|||
ruoso | TimToady, I think I've reached a sane API for the SMOP OO... Could you please take a look at www.perlfoundation.org/perl6/index....mop_oo_api when you have some time? | 16:05 | |
lambdabot | Title: SMOP OO API / Perl 6 | ||
ruoso | If that's really sane, I should start implementing p6opaque | 16:07 | |
16:10
sri_work joined
16:11
pmurias joined
|
|||
pmurias | ruoso: what will the identifier part of a message call be in real smop code | 16:12 | |
? | |||
ruoso | pmurias, hm? | 16:13 | |
it's an Object | |||
the only difference is that the constant identifiers can be used to optimize the dispatch | 16:14 | ||
pmurias | ruoso: is it intended to be a string in no-optimized code? | ||
ruoso | yes | ||
as string reads "anything that complies to the string api" | 16:15 | ||
pmurias | ruoso: won't it be hard to call objects which take constant identifiers from "high-level" code | 16:22 | |
? | |||
ruoso | in theory, the compiler *should* use the constant identifiers from the high-level code | ||
whenever it can, of course | |||
this constant identifiers are Objects just like String | 16:23 | ||
they just have a different representation | |||
a different responder interface | |||
pmurias | ruoso: it could be possible to make the objects to accepts string also | 16:24 | |
ruoso: the idconst identifiers implement the String API? | |||
ruoso | they will | 16:25 | |
they don't do it yet | |||
but they must do it | |||
pmurias | are they a big speedup? | ||
ruoso | certainly | ||
if it is a constant identifier I can simply compare the pointers | |||
and avoid any string comparision at all | 16:26 | ||
in the lowlevel it can be translated to: if (identifier == SMOP__ID__new) | 16:27 | ||
while String will require a cast to a native type | |||
and then a comparision of the native type afterwards | |||
16:28
zamolxes left
|
|||
ruoso | if they have the same type | 16:28 | |
it is possible to have a direct cmp | |||
but even then, I think casting to native and comparing is probably faster than comparing in non-native | 16:29 | ||
pmurias | i get the picture | 16:32 | |
16:44
meppl joined
|
|||
pmurias | ruoso: if a class we inherit from changes it's ancestors we have to update our composition pile? | 16:49 | |
(under C3) | 16:50 | ||
moritz_ | a class can change its anchestors? scary... | ||
pmurias | moritz_: is it forbiden? | ||
moritz_ | pmurias: I think you can add anchestors, but can you delete them? | 16:51 | |
ruoso | pmurias, the composition pile only refers to *this class* ancestors | ||
moritz_ | $class is also { is Other::Anchestor } | ||
ruoso | not recursively | ||
the MRO is recursive | 16:52 | ||
pmurias | ok | ||
ruoso | cache must be external | ||
as it needs to be invalidated globally whenever some class is changed | 16:53 | ||
pmurias | s1p code is translated into C? | 17:07 | |
or sm0p? | |||
ruoso | s1p code is translated to C + sm0p | ||
with the code that builds that class | |||
17:08
rindolf joined
|
|||
ruoso | with probably two C functions | 17:10 | |
SMOP__S1P__Object__BUILD | |||
and | |||
SMOP__S1P__Object__DESTROY | 17:11 | ||
to initialize and destroy the prototype | |||
17:13
TJCRI joined
|
|||
pmurias | the c will be used for setting up and sm0p for the method bodies? | 17:14 | |
i guess not, based on www.perlfoundation.org/perl6/index....p_language | 17:18 | ||
lambdabot | Title: SMOP s1p Language / Perl 6 | ||
17:20
tooo left
17:23
kst joined
17:24
justatheory joined,
Psyche^ joined
17:35
smtms joined
17:40
Patterner left,
Psyche^ is now known as Patterner
17:55
Lorn__ joined
18:02
zakame left
18:05
rindolf left
|
|||
ruoso | pmurias, yes... the s1p method bodies will be translated to a set of sm0p blocks each | 18:06 | |
the C code will be the code sorrounding this blocks to build them | 18:07 | ||
TimToady | ruoso: okay, looked at it | 18:09 | |
basically sane, though I have some quibbles and questions | |||
18:10
meppel-san joined
|
|||
TimToady | Object's BUILD/DESTROY I envisioned as being methods that attempt to do something useful if the actual object doesn't define the submethod | 18:10 | |
some reprs could autogen a BUILD on demand, for instance | |||
but at minimum it could complain about there being no BUILD submethod for the class | |||
maybe that's not how it should be, but it's how I was picturing it | 18:11 | ||
lessee... | |||
you don't need any of those trailing semicolons | |||
a final } on a line always implies ; | |||
I don't think there's a WALK type as a return value, it's just a List of Routine or some such | 18:12 | ||
speaking of which, it would be nice if all your return types said what they're Lists or Hashes "of" | |||
might want to use --> List of Foo notation in that case | |||
rather than the front type | 18:13 | ||
18:13
justatheory left,
justatheory joined
|
|||
TimToady | it seems strange to think of an attribute as RO | 18:13 | |
but maybe it's just an attribute descriptor? | 18:14 | ||
the arguments for "can"-like calls should really be considered to be taking something more general than just a name, since we have to be able to qualify by argument types as well | 18:16 | ||
18:17
tobeya joined
|
|||
TimToady | things like $object.can(&foo:(Int,Str,*)) and such | 18:18 | |
so it's a little odd to call it $identifier | |||
18:20
meppl left
|
|||
TimToady | most of the .^ methods were also envisioned to have a corresponding method in Object | 18:20 | |
18:20
meppel-san is now known as meppl
|
|||
TimToady | so by default $object.can calls $object.^can, and .does calls .^does, etc | 18:20 | |
but that was just for convenience | 18:21 | ||
it's possible we could enforce the ^ | |||
18:21
TJCRI left
|
|||
TimToady | in fact, the way to enforce the ^ is to put methods into Object that *refuse* to delegate to .HOW :) | 18:21 | |
but maybe we just delegate, and then that gives users of Object the right to override .can and .does in subclasses, and maybe that's a good thing | 18:22 | ||
well, that's enough to start with. :) | 18:23 | ||
18:27
TJCRI joined
18:30
jjore-w joined
18:34
njbartlett joined
18:37
rindolf joined
18:51
njbartlett left
18:52
fridim_ joined
18:57
manfred left
18:59
stevan_ left
19:04
rindolf left
19:05
stevan_ joined
|
|||
cognominal_ | what is the ref equivalent in Perl 6 | 19:06 | |
how to get the class name of an object? | 19:07 | ||
Tene | $obj.WHAT iirc | 19:09 | |
pugs: my $s = 'foo'; say $s.WHAT | 19:10 | ||
exp_evalbot | OUTPUT[Strā¤] | ||
19:12
Aankhen`` left
|
|||
TimToady | .WHAT gives you the protoobject, which stringifies to the class name if there is one | 19:12 | |
but there doesn't have to be... | |||
and a normal class declaration basically does Foo::Bar ::= $anonclass.WHAT to attach it to a package name | 19:13 | ||
ruoso | TimToady, but... can we have both a submethod and a method of the same name? | 19:14 | |
I mean... | |||
I'm trying to figure out what to do about BUILD | |||
because Object's BUILD do something | 19:15 | ||
cognominal_ | thx Tene | ||
and TimToady | |||
ruoso | it sets all the public attributes of the object that are in the *%initialize argument | ||
TimToady | submethods are essentially subs that just think they are methods | 19:16 | |
and expect to be called with an invocant | |||
but their names live in sub space really | |||
ruoso | and also, if there's a BUILD method, the same BUILD will be called for every class in the hierarchy | ||
while a submethod will only be invoked for one specific class | |||
(unless I got it wrong...) | |||
TimToady | when a dispatcher calls them, they're really called as subs, not as methods | 19:17 | |
only Object defines a BUILD method generally, and mostly just to make sure the dispatch is handled well by default | |||
I guess it can be a submethod in Object and still work that way though | 19:18 | ||
ruoso | my guess was that the call to BUILD is $class->?BUILD() instead of ->BUILD | ||
which means that it is ok if a class don't define a custom BUILD | 19:19 | ||
but... | |||
there's the capture manipulation | |||
BUILD can "consume" elements from the capture... | 19:20 | ||
TimToady | sorry, distracted cooking lunch... | ||
ruoso | (if I got it right) | ||
cognominal_ | what should print ./parrot languages/perl6/perl6.pbc -e 'print undef.WHAT' | ||
ruoso | rakudo: print undef.WHAT | ||
exp_evalbot | OUTPUT[Statement not terminated properly at line 1, near ".WHAT"ā¤current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)ā¤called from Sub 'parrot;Perl6::Grammar;statementlist' pc 14911 (src/gen_grammar.pir:2402)ā¤called from Sub 'parrot;Perl6::Grammar;statement_block' | ||
..pc 12098 (src/gen_grammar.pir:1396)ā¤called from S... | |||
ruoso | rakudo: print undef.WHAT(); | ||
exp_evalbot | OUTPUT[Statement not terminated properly at line 1, near ".WHAT();"ā¤current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)ā¤called from Sub 'parrot;Perl6::Grammar;statementlist' pc 14911 (src/gen_grammar.pir:2402)ā¤called from Sub | ||
..'parrot;Perl6::Grammar;statement_block' pc 12098 (src/gen_grammar.pir:1396)ā¤called fro... | |||
cognominal_ | it dies on me | 19:21 | |
ruoso | rakudo: print undef().WHAT(); | ||
exp_evalbot | OUTPUT[Undef] | ||
cognominal_ | hum | ||
why I should pos-parenthesize the undef? | 19:22 | ||
rakudo: print undef().WHAT | 19:23 | ||
exp_evalbot | OUTPUT[Undef] | ||
TimToady | if you want a default BUILD submethod, where's the right place to store that? | ||
ruoso | Object | ||
19:23
rindolf joined,
funktio left
|
|||
ruoso | but that's not actually "default" | 19:23 | |
that will always be called | |||
(which I thought to be the pourpose on submethods after all | 19:24 | ||
TimToady | seems like it's repr dependent | ||
ruoso | not exactly... | ||
if I'm right, it'll use the REPR API | |||
which makes it repr independant | |||
as long as all repr implement the API | |||
TimToady | true | 19:25 | |
ruoso | (and I really think the REPR API could be considered standard Perl 6... I really don't know if it can be done without it) | ||
TimToady | I guess whether you think of Object::BUILD as a method or as a submethod depends on whether you think of the BUILD calls as method calls or a sub calls | ||
ruoso | but isn't hiding it the point of submethods? | 19:26 | |
TimToady | I was thinking of normal dispatch as @candidates = WALK; for @candidates { $_.() } | ||
ruoso | the only difference is that you would need to call | 19:27 | |
$class->BUILD($object: ) | |||
which would end up being | |||
TimToady | where as soon as you take a ref to a method, it basically turns into a sub as far as dereferencing goes | ||
ruoso | $class->can("BUILD")->call( \($object: ) ) | ||
cognominal_ | rakudo: say (undef).WHAT | 19:28 | |
exp_evalbot | OUTPUT[Undefā¤] | ||
ruoso | $object->BUILD would probably never dispatch anything... | ||
TimToady | but that's basically a double call of can, if each submethod is also dispatched as a method | ||
ruoso | you mean, to check for methods and for submethods... | 19:29 | |
so falling back to package::BUILD($object) would be natural | 19:30 | ||
as every failed method dispatch failover to sub dispatch | |||
so, there's no much point in submethds at all | |||
they could simply be regular subs | 19:31 | ||
TimToady | they're submethods so that we allow ($obj:) in the sig | ||
actually, I recently added the $object.*@candidates(@args); syntax | 19:32 | ||
but that's also essentially treating @candidates as a list of sub refs, not names | 19:33 | ||
ruoso | so, during BUILDALL, it would invoke each BUILD by package with sub invocation, not by method of the object | ||
19:33
rindolf left
|
|||
TimToady | note also that the call order is determined entirely by the WALK, and BUILD and DESTROY and normal dispatch are three different WALK orders | 19:33 | |
$object.*@candidates(@args); is really sub invocations, I'm saying | 19:34 | ||
assuming @candidates doesn't contain method names | |||
with names they'd be redispatched | |||
$object.?$candidate(@args) is also a sub call if $candidate is a Routine | 19:35 | ||
no real dispatch involved, except to make the call optional | |||
ruoso | I thought that it would always be a sub call in the $object.$anyhting... unless explicit $object."$anything" used... | ||
TimToady | er, yeah, what you said. :) | 19:36 | |
ruoso | I was thinking it was deterministic by syntax | ||
TimToady | so never mind about that redispatch :) | ||
ruoso | ok | ||
TimToady | if you want that you have to do your own walk | ||
I can't keep track of my own darn language, how will I expect other people to... :) | 19:37 | ||
ruoso | that makes me think... isn't an Iterator type missing? | ||
TimToady | List is the iterator type | ||
ruoso | List have index-based access | ||
TimToady | see "lazy" | ||
ruoso | Iterator must be able of not having index-based lookups | ||
ruoso thinking of a BDB Btree without recno | 19:38 | ||
TimToady | a List will consist of a number of determined elements followed by a number of undetermined elements | ||
ruoso | TimToady, that's the point | ||
TimToady | if you use .[] it just moves some of them from undetermined to determined | ||
ruoso | and what if you have a circular list | 19:39 | |
you can't tell where it start | |||
or a lookup in a bdb db | |||
where you don't know how many elements there are before the one you got | |||
TimToady | prefix:<=> is the destructive way to read a list | 19:40 | |
or := to Array and use shift | |||
ruoso | but that implies index-based lookup | ||
TimToady | what of it? | ||
ruoso | sometimes I can't have index-based lookups | 19:41 | |
TimToady | then you don't have an ordered type | ||
ruoso | you have | ||
but you just don't know its cardinal position | |||
it is ordered | |||
you just can't count them | |||
TimToady | you don't have a well-ordered type | ||
it's not transitive | |||
ruoso | you must navigate using .has_next, .next, .has_previous, .previous | 19:42 | |
TimToady | fine, but Perl doesn't care about your circular linked list enough to implement it | ||
and if you know what .next is, you can index from that position anyway | 19:43 | ||
ruoso | not in a berkeley db btree without recno | ||
TimToady | it's just a turing machine tape | ||
Lists have a beginning in Perl | 19:44 | ||
even if that's just notiationally the current position | |||
*notionally | |||
ruoso | I see... and that's why I was arguing... a pure Iterator type have several interesting use cases... | ||
TimToady | .[3] do .next 3 times, peek, do .previous 3 times to get back (in the worst case) | 19:45 | |
fine, but that's what =$iterator is for | |||
it's a scalar as far as Perl is concerned | |||
ruoso | sure... | ||
It's just a matter of what's in the built-in api | 19:46 | ||
for multi dispatch matters | |||
TimToady | note that @candidates can be as lazy as it likes | 19:47 | |
it doesn't have to go out to the end unless you ask it to do that | |||
19:48
pmurias left
|
|||
TimToady | if one of the candidates says whatever "last METHOD" has turned into these days | 19:48 | |
it doesn't need to calculate the rest of the candidates | |||
lastcall it is now | |||
[particle] | .onewhiskey() | 19:49 | |
TimToady | maybe it's the last altar call :) | 19:50 | |
19:51
jferrero left
|
|||
ruoso still think it's easier to implement MRO in terms of Iterator than in terms of List... | 19:52 | ||
TimToady | the main difference between List and Array is not their access interface; the main difference is that List presents an immutable interface to the order of the values, while an Array allows you to change out any elements you like | ||
ruoso . o O ( Iterator is just a cursor to a List or an Array or whatever... ) | 19:53 | ||
TimToady | @candidates := WALK gives you the iterator | ||
lambdabot | Unknown command, try @list | ||
ruoso thinking about self->NEXT::foo(), for instance... | 19:54 | ||
TimToady | that's spelled nextsame() these days | 19:55 | |
ruoso | anyway... | ||
TimToady | and it has to work for mmd as well as single dispatch | ||
anyway, making @candidates an object with potentially non-destructive readout allows you to cache the list | 19:57 | ||
an iterator with destructive readout would force you to re-walk | |||
ruoso | an iterator usually is read-only | 19:58 | |
rw iterators are an exception | |||
TimToady | an iterator evaporates once you've used it in my lingo | ||
ruoso | not if it can forward and rewind | ||
like a db cursor | 19:59 | ||
TimToady | but it's certainly not ro in the sense that nothing changes when you read it | ||
ruoso | it's an RO access to the list | 20:00 | |
the iterator itself is rw | |||
but an iterator usually don't write to the list | |||
TimToady | look, whether you spell it "for @candidates" or ".*@candidates", there's an iterator there somewhere, but the user doesn't have to keep track of it | 20:02 | |
ruoso | sure... | ||
but again... I'm in a much lower level right now | |||
I don't even have a parser atm | |||
TimToady | working on that... :) | 20:03 | |
ruoso | :) | ||
what I was arguing is that having Iterator as a built-in type | |||
makes some things easier in the low-level | |||
[particle] | how 'bout a Role? | 20:04 | |
ruoso | by type I really mean something that can be ~~'d to | ||
but the point is that if getting an Iterator from a List is part of the List API | 20:09 | ||
TimToady | well, you have to implement laziness somehow; I don't much care how much the implementation of List shows through to the user | ||
ruoso | but it needs to be part of the standard API | ||
so I can actually get an Iterator from a List | 20:10 | ||
TimToady | sure, but we actually try to hide the List api behind other apis in Perl, as far as mere mortals are concerned | ||
ruoso | we can't | ||
TimToady | "try to" | ||
ruoso | because anything can implement a list | 20:11 | |
we must have a very clear notion of what makes a List | |||
TimToady | we do, but the user doesn't :) | ||
ruoso | it must, if the user can implement a List on its pown | ||
PerlJam | Anything used in a List context is a List ;) | ||
ruoso | s/pown/own/ | ||
TimToady | then that user is not a mere mortal | 20:12 | |
ruoso | ah... ok... | ||
ruoso realises that the problem is defining when a user is or not a highlander | |||
TimToady | indeed, that's what Perl is all about. but yes, certainly you have to be able to iterate a list on some level | ||
ruoso | that's what I call the List API | 20:13 | |
TimToady | and in fact, it'll be very easy to generator iterators with ==> my $iter | ||
[particle] | maybe make it list rather than List? | ||
ruoso | [particle], that's not the point | ||
the point is really being able to deal with unknown types | 20:14 | ||
as long as they comply to some defined APIs | 20:15 | ||
TimToady | an iterator must store its state somewhere external to the list, because a list must support multiple iterators simultaneously | ||
ruoso is saying he doesn't want to access the list from the iterator using .[], and that's fine | 20:16 | ||
ruoso | yep | ||
[particle] | don't we have closures? | ||
TimToady | what mean "we", white man? | ||
[particle] | does smop have closures at this level | ||
ruoso | smop doesn't have lexical scopes yet | 20:18 | |
TimToady | closures are useful for generating more of the underlying list, but I don't see how that applies to iterators... | ||
ruoso | indeed.... | ||
20:18
Helios_ joined
|
|||
ruoso | an iterator to a regular list would hold a simple int pointing to some point of the list | 20:18 | |
TimToady | but then you're assuming a .[] api again | ||
or a .next.next.next.prev.prev.prev api :) | 20:19 | ||
20:19
sri_work left
|
|||
ruoso | which is what I would like to use in the low-level | 20:19 | |
ops... I've just understood what you said... | 20:20 | ||
TimToady | well, the really low-level api just uses scalar refs that point to subs, and doesn't care how it gets fed those... | ||
ruoso | the thing is that most of the time I won't have a regular list | ||
most of the time I'll use the list API to opaque data structures | 20:21 | ||
in the low-level | |||
TimToady | there's no list at all in $object.?$subref() | ||
so you're really talking about the not-quite-lowest level | 20:22 | ||
[particle] | ? meaning submethod? /me rechecks s12 | ||
ruoso | but $obj.^!isa returns a non-regular list | 20:23 | |
TimToady | meaning call $subref($object: ) optionally | ||
[particle] | ah, gotcha. | ||
TimToady | calling through a reference erases the distinction between subs and methods | ||
ruoso | by non-regular list I mean a opaque object that implements the list api | ||
that would probably return a non-regular-list-iterator when asked for an iterator | 20:24 | ||
and navigating with next and previous is probably more efficient than resolving the index of each lookup | 20:25 | ||
for that opaque object | |||
or it certainly is if the access is always sequential | |||
[particle] | btw i was thinking of generators when i mentioned closures, you're right, doesn't apply | ||
ruoso | like during MRO | ||
TimToady | sure, and when the user writes his own dispatcher with $object.*@candidates, the .* dispatcher will be iterating through the array/list/whatever | 20:26 | |
ruoso | exactly... | ||
can I get my pony^Witerator type now? | 20:27 | ||
TimToady | in fact, I suppose $object.*$iterator also falls out of that, which is what you're trying to get me to understand | ||
never said you couldn't :) | |||
ruoso | one important thing that I think is not yet clear... | 20:28 | |
is that what we call Perl 6 will also be defined by what the built-in APIs are | |||
and i think these should be considered specifications | 20:29 | ||
for instance... | |||
I'm considering that there is a native capture type | |||
now there are two options... or the native capture becomes part of the spec, or I have to forget about it... otherwise the SMOP Perl 6 won't be compatible with the Rakudo Perl 6 | 20:30 | ||
TimToady | to the extent that those apis are the only reasonably way to do things, we can certainly consider speccing them. but that's more something for various implementations to negotiate | ||
I try not to design too far out ahead of my own understanding. | |||
[particle] | ok, that's scary. | 20:31 | |
you already understand *a lot* :) | |||
ruoso | my point is... if we agree on an Iterator type... it must get to the specs | ||
as to make sure code from different implementations can interoperate | |||
[particle] | parrot's Iterator PMC doesn't have a 'previous' (most iterator implementations i know don't.) | 20:32 | |
TimToady | what, you don't back up lines with >STDIN< ??? | ||
ruoso still wonders if the .^!foo api shouldn't get to the spec also... | |||
[particle], Iterator is really just an API... as every non-native built-in type | 20:33 | ||
we could consider that Iterator can only go forward | |||
TimToady | that would be the base role | ||
a two-way iterator would add in .previous | |||
ruoso | exactly | 20:34 | |
and a rw iterator would include .add, .remove and .update | |||
20:35
hanekomu joined
|
|||
ruoso | one important realisation I had in SMOP is that the only objects you actually know are the native ones... everything else is just Design by Contract... even for the built-in types... | 20:35 | |
an Int is anything that says true to .does(Int) | 20:36 | ||
it can even have a different representation | |||
TimToady | I don't think that's the standard definition of DbC, but whatever | ||
ruoso | [particle], btw... how do you plan to support alternative representations in rakudo? | 20:37 | |
[particle] | i haven't really considered it yet. | ||
ruoso | hmmm... | ||
20:37
DarkWolf84 joined
|
|||
ruoso | I'd suggest you considering it early... | 20:37 | |
[particle] | :) | ||
TimToady | PMCs are parrot's God Object :P | ||
[particle] | right, we can always create another pmc. | 20:38 | |
but, i'm sure there are some better than others, | |||
and parrot's pmc model is under refactoring atm | |||
soon we'll have role-composition for pmcs. | |||
i have a feeling that will impact rakudo's model. so, i wait. | 20:39 | ||
ruoso | I mean... can you have a simple reference to a Glib object in a PMC? and delegate the object representation management to Glib? | ||
[particle] | pmc's encapsulate behavior behind the VTABLE api | ||
so, yes. | 20:40 | ||
ruoso | ok... so you probably won't have much trouble | ||
but one thing you must remember is that you must be able to do: | 20:42 | ||
my $foo = Int.CREATE(:repr<Glib>); my $bar = Int.bless($foo); | |||
so the object initialization code must not depend on a single representation | 20:43 | ||
that's exactly the point I'm stressing in the last week (what I'm calling the SMOP OO API) | |||
20:44
Psyche^ joined
|
|||
ruoso | and that probably means that the repr api should be standard | 20:44 | |
[particle] | well, we're not quite there yet, but that's partially because there's no way (in the spec) to query the object's representation afaik | ||
ruoso | and that would make a single core lib implementation that could be shared by rakudo and smop | ||
[particle] | ...that's why you have .^! | ||
20:45
zamolxes joined
|
|||
ruoso | yep... and the only thing that makes it SMOP specific right now is the fact that it's not in spec | 20:45 | |
[particle] | it's okay to be ahead of the spec. | 20:46 | |
TimToady always catches up :) | |||
note that '{*}' and '#= foo' still isn't specced | |||
ruoso | it would be amazing if smop and rakudo shared the built-in lib | 20:47 | |
PerlJam | Conventions shouldn't be specced so much :) | ||
ruoso | [particle], did you see smop/src-s1p/Object.pm | 20:50 | |
ruoso home & | |||
[particle] | looking now | ||
20:51
buchetc joined
|
|||
ruoso | it's outdated considering the last changes I made to the REPR api | 20:51 | |
but the point is that it should probably be the same code that rakudo is supposed to run... | |||
[particle] | ah, yes, looking at this reminded me that i need to add flattening to rakudo | 20:52 | |
ruoso | anyway... | ||
home & | |||
seeya | |||
20:53
silug joined
20:55
njbartlett joined
|
|||
pugs_svn | r19890 | buchetc++ | use contend to avoid race condition | 20:55 | |
20:59
Patterner left,
Psyche^ is now known as Patterner
21:01
blindfish left,
thoughtpolice joined
21:21
ludan joined
|
|||
ludan | hi | 21:22 | |
TimToady | howdy | ||
21:23
Helios_ is now known as Helios
21:40
sleskey joined
|
|||
cognominal_ | S4 mentions C<contend> but I can't see anywere else. What is it? | 21:49 | |
21:51
pbuetow left
|
|||
cognominal_ | I see it in the rakudo grammar.pg too | 21:51 | |
21:55
hanekomu left,
thepler_ left
|
|||
buchetc | cognominal_: Formely it was called 'atomically', I think. I currently understand it as a kind of locking mechanism | 21:55 | |
21:56
thepler joined
|
|||
cognominal_ | ok, makes sense | 21:58 | |
ho macosx 10.5.2 update and still no ps preview :( | |||
allbery_b | not surprising, word I hear is 10.5.2 is all about Time Machine / Time Capsule | 22:01 | |
buchetc | cognominal_: contend should be documented in S17. | ||
cognominal_ | ha, I searched in dev.perl.org/perl6/doc/, no S17 there | 22:02 | |
lambdabot | Title: Perl6 Architecture - perl6 | ||
22:02
ruoso left,
jhorwitz left
22:03
Jamtech joined
|
|||
buchetc | try svn.openfoundry.org/pugs/docs/Perl6...rency.pod; I don't know why it's hidden | 22:04 | |
cognominal_ | well, in fact, right now, I have no special interest in it. Just surprised to see mentionned only once in the synopses | 22:06 | |
22:10
jferrero joined
22:12
iblechbot left
22:14
psapo left
22:15
psapo joined
22:16
sleskey left
22:19
monomorph left
22:29
Auzon joined
22:32
peeps[work] joined
22:34
justatheory left
22:35
justatheory joined
22:36
Zygo left
22:37
Zygo joined,
Limbic_Region joined
22:39
Zygo left
22:40
Zygo joined
22:42
buchetc left
22:47
cmarcelo left
22:53
TJCRI left
22:55
Limbic_Region left
22:59
Jamtech left
23:06
ruoso joined
23:07
wknight-away joined,
peeps[work] left
23:10
rdice left
23:21
Zygo left,
Zygo joined
23:22
Limbic_Region joined
23:33
ebassi left
23:36
ludan left
23:38
jferrero left
23:40
Jedai left,
ruoso left
23:47
ruoso joined
23:48
eternaleye left,
zamolxes left
23:55
Zygo left
23:56
Zygo joined
23:58
Schwern joined
23:59
PerlJam left,
Zygo left
|