|
svn switch --relocate svn.openfoundry.org/pugs svn.pugscode.org/pugs/ | run.pugscode.org | spec.pugscode.org | paste: sial.org/pbot/perl6 | pugs.blogs.com Set by avar on 16 November 2006. |
|||
|
00:58
spoop joined
01:26
fayland joined
01:27
fayland_ joined
01:31
fayland__ joined
01:48
gnuvince joined
01:53
Khisanth joined
01:57
Khisanth joined
02:00
fayland___ joined,
fayland___ is now known as fayland,
bonesss joined
02:13
fayland___ joined
02:19
rdice joined
02:25
kisu joined
02:32
EisnersAntonia joined
02:38
EisnersAntonia left
02:42
dmq joined
02:47
fayland____ joined,
fayland____ is now known as fayland
03:07
nothingmuch joined
03:16
lyokato joined
03:19
spoop joined
03:38
kanru joined
03:42
nipotaway is now known as nipotan
04:04
spoopithy joined
04:20
nothingmuch joined,
spoop joined
04:28
LordBrain joined
04:39
avarab joined
05:05
imperator joined
05:16
justatheory joined
05:26
mok joined
05:28
Aankhen`` joined
05:36
luqui joined
05:40
nipra joined
06:09
mok is now known as imperator
06:13
kanru joined
06:15
BooK joined
06:21
RHainsworth joined
06:22
RHainsworth left
07:54
cognominal joined
07:55
stef_ joined,
cognominal joined
08:10
elmex joined
08:23
iblechbot joined
|
|||
| gaal mooses | 08:24 | ||
| gaal notices a moose- (well, reindeer-) related typo in spj's cool chapter on stm and beautiful haskell here: haskell.org/haskellwiki/Talk:SantaClausProblem | 08:27 | ||
| lambdabot | Title: Talk:SantaClausProblem - HaskellWiki | ||
|
08:28
pnu joined
09:11
stef_ joined
09:18
b_jonas joined
09:28
ofer1 joined
09:51
integral_ joined
09:54
larsen_ joined
09:55
integral_ is now known as integral
09:57
chris2 joined
09:59
stef_ joined
10:00
stef_ joined
10:16
nipotan is now known as nipotaway
10:24
Lorn joined
10:44
avarab is now known as avar
11:04
kanru joined
11:10
buetow joined
11:13
nekokak joined
11:20
kanru joined
11:24
BooK_ joined
11:39
turrepurre joined
11:54
iblechbot joined
12:04
jiing_ joined
12:06
autark joined
12:30
AtomicStack joined
12:40
ruoso joined
13:07
ruz joined
13:09
RHainsworth joined
13:10
RHainsworth left
13:14
dduncan left
13:36
prism joined
13:42
devogon joined
13:55
b_jonas joined
14:02
b_jonas joined
14:28
[particle] joined
14:35
vel joined
14:41
marmic joined
14:45
bonesss joined
14:53
penk joined
|
|||
| bonesss is away: takedown | 15:33 | ||
|
15:47
meppl joined
15:48
nipra joined
15:53
kanru joined
16:20
kanru joined
16:24
fglock joined
|
|||
| fglock | nothingmuch: would you provide an example on how a simple p5 program using MO should look like (a class declaration, a 'new' method, and instantiation) | 16:27 | |
| the example/ files don't run here | |||
| nothingmuch | the examples run like normal perl 5 | ||
| due the native package emitter thingy | |||
| the registry takes care of that bit | 16:28 | ||
| for other things, see t/si.t | |||
| fglock | I'm getting 'Can't locate Generate/PMC/File.pm' | ||
|
16:28
ruoso joined
|
|||
| nothingmuch | nothingmuch.woobling.org/cgi-bin/darcs.cgi | 16:29 | |
| lambdabot | Title: Darcs repositories | ||
| fglock | thanks | 16:30 | |
| the t/ files seem to take some time to load - can this be speed up by generating lower level code, or is it not worth the trouble? | 16:31 | ||
| I mean, if mp6 generated "less readable" code, would it possibly be faster? | 16:33 | ||
| nothingmuch | the tests do no caching | ||
| otoh, if you write a small .t file for one of the example files the example .pm gets a .pmc generated | 16:34 | ||
| this cannot yet deal with complex class definitions or stuff like imports yet | |||
| but it's as fast as hand written code in every way | |||
| when you load $foo->meta then the original .pm file gets loaded as well, for the meta def | 16:35 | ||
| fglock | I wonder if mp6 could generate "pmc-level" mo code | ||
| nothingmuch | why bother? | 16:36 | |
| MO does it for you | |||
| MO takes the meta class bits and installs them into the package | |||
| and then uses data::dump::streamer to serialize the package | |||
| and massages the output a bit | |||
|
16:36
ashleyb joined
|
|||
| fglock | one reason would be to make it easier to port MO to native mp6 | 16:38 | |
| because it would require less hacks | 16:39 | ||
| nothingmuch | uh? | ||
| the data structures describing the meta classes can be serialized as YAML | 16:40 | ||
| and moved from p6 space to p5 space | |||
| there is no pmc-level mo stuff | |||
| there's MO::Emit::P5 which takes meta classes and flattens them into packages | |||
| which is a concept p6 doesn't even have | |||
| in the same sense | 16:41 | ||
| TimToady | sorta by design... :) | ||
| mostly because I'm proxying for everyone who doesn't want to think about meta classes. | |||
| nothingmuch | what does mp6 want to get out of using MO? | 16:42 | |
| TimToady | I'm glad you guys are thinking about it though. | ||
| nothingmuch | less code in writing a p5 runtime with OO? | ||
| because the runtime bits of MO are opaque by design | |||
| TimToady | we're trying to bootstrap the real P6 compiler. | ||
| nothingmuch | well, in that case a port of MO::Compile and some of MO::Run to p6 will be fruitful | 16:43 | |
| and a port of all of MO::Run + code that replaces MO::Run::Aux on the target platform | |||
| if the target platform is perl 5 then it's ready | |||
| TimToady | that plus a translated v6 gets us most of the way there. | ||
| nothingmuch | if it's parrot it should be fairly trivial to make a set of responder interface type stuff to talk to parrot's native O | 16:44 | |
| O | |||
| then the compiler must parse classes, build meta objects at compile time, and make them into responder interfaces which are basically an OO specific compilation unit | |||
| then it serializes that | |||
| and whammo | 16:45 | ||
| even easier wuold be to simply serialize the data structure used to construct the meta class | |||
| and then do the whole meta calc in p5 land with my implementation | |||
| that design is flawed though | |||
| because the whole point is making the meta model separated from the runtime | 16:46 | ||
| makes sense? | |||
| TimToady | treating P5 as a form of assembly language, yes. :) | ||
| you want to express it in something more portable? | |||
| nothingmuch | =) | ||
| well | |||
| responder interfaces are in a sense dumbed down meta classes | 16:47 | ||
| i think it's safer to standardize a few of these | |||
| i don't like my ones so much | |||
|
16:47
ashleyb joined
|
|||
| nothingmuch | ideally the pipeline is that the compiler loads code, uses MO::Compile::* to make MO::Run::*, serializes MO::Run::* | 16:48 | |
| TimToady | Is there a reasonably compromise between what is possible and what is easy? | ||
| s/y/e/ | |||
| nothingmuch | well | ||
| the problem is that with p6-on-p5 we're trying to get a bit more goodnbess | 16:49 | ||
| TimToady | goodness is good... | ||
| nothingmuch | si si | ||
| when it's all purely MO::Run::* then the runtime simply has to support the targetted responder interfaces (natively or using a library or previously compiled code) | |||
| TimToady | I mean, how close can we get to the "perfect" interface, and how much do we have to settle for a "perfectible" interface? | 16:50 | |
| nothingmuch | however, to get better results in terms of integration with the host language we want more info in there | ||
| the "perfect" way is perfect for systems which are not p5 | |||
| because perl 5 has things like @ISA in the output | 16:51 | ||
| so MO::Emit::P5 digs into the meta class and then makes that more "native" | |||
| we have that | |||
|
16:51
ashleyb joined
|
|||
| nothingmuch | we can also have an extremely slow runtime which is completely "perfect" | 16:51 | |
| TimToady | I just don't want to get stuck with an interface that is warped towards P5 and then can't be upgraded. | ||
| nothingmuch | we can also have a somewhat ugly runtime that doesn't have native perl 5 stuff | ||
| i think the wisest thing is to go in baby steps | 16:52 | ||
| start with MO::Compile only | |||
| and push it all to perl 5 for now | |||
|
16:52
ashleyb joined
|
|||
| nothingmuch | later we simply move MO to really live inside the compiler | 16:52 | |
| TimToady | we can Officially Break Anything till 6.0.0 comes out. :) | ||
| nothingmuch | i doubt we'll need to | ||
| TimToady | whatever gets us to the bootstrap quickest without unnecessary long-term damage... | 16:53 | |
| nothingmuch | this, i think | ||
| the 'damage' in a sense is more work writing other runtime | |||
| s | |||
| but as long as we stop before that starts | |||
| fglock | the plan for mp6 is to compile modules to simplified-mp6, and then to native. That's how it supports grammars. I wonder how much slower this would be for MO | ||
| TimToady | is simplified-mp6 simpler than mp6? | 16:54 | |
| nothingmuch | i doubt MO comes into play there | ||
| fglock | yes, it doesn't support grammars :) | ||
| nothingmuch | hmm | 16:55 | |
| i don't see a problem with it being plugged after simplified-mp6 | |||
| whereby mp6 with grammars contains e.g. macros for classes etc | |||
| and simplified-mp6 has BEGIN { $mo_meta_calls } | |||
| then simplified -> native means running the BEGIN stuff, and making sure the resulting data structures simply make it out of there | 16:56 | ||
| as long as native is still p5 that's 0 work | |||
| just serialization | |||
| if we want to support more runtimes we'll have to refactor some | |||
| sounds sane? | |||
| TimToady | how much refactoring for, say, parrot? | ||
| nothingmuch | fas long as we have hooks for another pass in the compiler before emitting it should be trivial | 16:57 | |
| again, the diff is that instead of outputting "raw" MO structures we want to output dumber ones, which are more portable | |||
| and the translation from raw to dumbed down is MO itself, plus any custom metaclasses | |||
|
16:58
ashleyb joined
|
|||
| TimToady | basically moving from definitional toward operational, I guess... | 16:58 | |
| nothingmuch | that is a good way to put it | ||
| of course, operational is also pluggable | |||
| but reaching that stage the person extending operational will almost always want to do a per native-runtime port of the operational stuff | 16:59 | ||
| or it'll be slow | |||
| i have to go make salad | |||
| i hope i helped instead of confused ;-) | |||
| TimToady | use a circularity saw on your salad. :) | ||
| nothingmuch bought a big chef knife | |||
| very sharp | |||
| TimToady | avoid digits | 17:00 | |
| fglock | making both parrot and perl5 work at the same time would assure the design is sane... | ||
| TimToady | well, saner. :) | ||
| nothingmuch | hehe | ||
| TimToady | I'm quite certain there are ways in which Perl and Parrot are similarly misguided. :) | ||
| nothingmuch | that's still a bit further off... will you guys be here in about 1 hour to discuss? | 17:01 | |
| TimToady | might be commuting about then, but likely around give or take 10 minutes. | ||
| nothingmuch strongly believes that his model will work well in real ASM, his second (or maybe third) love | |||
| okies.. I'll be back | 17:02 | ||
| TimToady | compiling P6 to straight ASM would be cool. | ||
| fglock | I'll have a meeting soon, then will be around until 3h from now | ||
| I was considering an asm output to mp6, but I guess it's better to start with C first | 17:03 | ||
| and I think audreyt said she would work on the Haskell backend | 17:05 | ||
| pugs.blogs.com/photos/visiolization...strap.html - shows how the grammar implementation plugs back into mp6 | 17:10 | ||
| lambdabot | Title: Visiolization: Mp6bootstrap | ||
|
17:20
justatheory joined,
wamiks joined
17:33
diotalevi joined
|
|||
| diotalevi | So is there syntax in Perl 6 yet for saying "this next bit is in prolog?" | 17:39 | |
| fglock | I think it's like: eval "...", :lang<prolog> | 17:44 | |
| diotalevi | Oh bummer. Bummer. Bummer. bummer. | ||
| Well... eval <<'...', :lang<prolog> wouldn't be so bad though. Maybe? | 17:45 | ||
| No wait.... it wouldn't be piles of awesome. I'm back to 'bummer.' | 17:46 | ||
| allbery_b | hm, I would have thought there would be something like: grammar Prolog { ... } (...) { use Prolog; ... } (akin to "use perl5;") | 17:50 | |
| TimToady | macro this_next_bit_is_in_prolog ($ast) is parsed(Prolog) {...} | ||
| diotalevi | Oh. Well happy day then. | ||
| TimToady | Perl 6 is not a language. Perl 6 is many languages. | 17:57 | |
| nothingmuch | btw, i'd like there to be an "official" micro perl 6 | ||
| which contains just enough features to bootstrap extensible grammars, and the notion of BEGIN etc | 17:58 | ||
| diotalevi only wanted the Perl 6 that'd let him speak a few languages simultaneously (or at least adjacently) | |||
| nothingmuch | that is, the thing without all the "just a macro" features | ||
| which is no fun to work with, but is well defined and easier to port | 17:59 | ||
| TimToady | how is this different from mp6? | ||
| allbery_b | "official"? | ||
| nothingmuch | i thought fglock said a bit earlier that the "simpler" form has no extensible grammars? | 18:00 | |
| that said, I have another answer: the purpose is slightly different | |||
| miniperl 6 is mini enough to bootstrap | |||
| but is not mini out of minimalism | |||
| fglock | it is bootstrapped | ||
| yes | 18:01 | ||
| nothingmuch | we could milk a bit more mini out of it, theoretically | ||
| and the reason *I* am interested is that this language interests me | |||
| because it's the mother of all meta languages ;-) | |||
| TimToady | seems like the opposite approach to a circularity saw, but maybe you'd write your circularity saw in this eventually... | ||
| nothingmuch | it hasn't much to do with it | 18:02 | |
| it's like a "For later" thing | |||
| it would just be a nice spec layer | |||
| for the language underlying all the ergonomics that is perl 6 | |||
| TimToady | the problem with designing meta stuff is you never quite know what you'll want to be meta about later... | ||
| nothingmuch | well, the language *is* in there | 18:03 | |
| macro processing, BEGIN { }, the notion of subroutines and data types | |||
| but on the other hand I don't think that e.g. gather/take is part of that | |||
| TimToady | and I think the circularity saw is related to that distinction | 18:04 | |
|
18:04
Lorn_ joined
|
|||
| nothingmuch | it is related, but it's purpose is different | 18:04 | |
| because gather/take is very useful for writing a perl 6 compiler | 18:05 | ||
| but gather/take is not very useful when you're extending a core language to make a language that is not anything like perl 6 | |||
| you'd have many bits to take away first | |||
| TimToady | I don't see how gather/take would be useful for writing P6 and not other things too. | 18:06 | |
| fglock | did you see miniperl6.spec ? | ||
| nothingmuch | TimToady: because by design when you make a DSL in perl you are normally "subclassing" the perl 6 grammar | 18:07 | |
| but for writing non perl 6 related tools maybe you'd rather have a higher base class | |||
| fglock: no, I haven't | |||
| wow, my sister is really talented | 18:12 | ||
| today she didn't come home from school | |||
| so i went looking for her | |||
| in the rain | |||
| now my shoes were drying in the bathroom | |||
| and to thank me she spilled more water into them | |||
| *sob* | |||
| diotalevi | Oof! | 18:13 | |
| What a nice sister. | |||
| TimToady | I never had a sister... | ||
|
18:14
BooK joined
18:16
Lorn joined
|
|||
| fglock | nothingmuch: svn.pugscode.org/pugs/v6/v6-MiniPer...6-spec.pod | 18:21 | |
|
18:30
Lorn_ joined
|
|||
| TimToady | commuting & | 18:34 | |
| fglock | nothingmuch: so do you have a use for mp6? | 18:51 | |
| nothingmuch | not now | ||
| but I will be studying at some point in my future, i'd like a nice putty language to make some weird ones with ;-) | 18:52 | ||
|
19:31
b_jonas joined
19:53
koye joined
20:08
Lorn joined
20:09
polettix joined
20:10
DaGo joined
20:32
Lorn joined
20:36
marmic joined
20:37
Dr_Pi joined
|
|||
| Dr_Pi | Would I be mistaken if I said pugs is the most important software development project written in Haskell? | 20:39 | |
| Tene | important to who? | 20:40 | |
| integral | .oO( some important bits of Pugs are written in Perl 6 |
||
| Dr_Pi | Maybe significant might be a better word. | 20:41 | |
| kolibrie | darcs might be considered an important software development project written in Haskell | ||
| and is part of the reason pugs uses Haskell (IIRC) | 20:42 | ||
| stevan | Dr_Pi: Actually GHC is written in Haskell | 20:50 | |
| That would probably be the most signifigant, since it compiles Haskell :) | 20:51 | ||
|
20:51
Lorn_ joined
21:11
elmex joined
21:13
weinig is now known as weinig_,
weinig_ is now known as weinig
21:15
Aankhen`` joined
|
|||
| allbery_b | ghc is certainly the largest. most significant? IIRC Deutche Bank hires Haskell programmers --- it occurs to me a financial application for a multinational bank is potentially more significant than ny of the above :) | 21:25 | |
|
21:28
Lorn joined
21:33
weinig is now known as weinig|bbl
21:40
DaGo joined
21:44
Lorn_ joined
|
|||
| stevan | allbery_b: that assumes that they use Haskell in a production environment for a financial app | 21:46 | |
| just cause they are hiring, doesnt mean they are running the bank with it :) | |||
| and of course,.. if they use GHC to compile their Haskell, then it seems we might be back full circle | |||
|
22:10
xpika joined
22:49
stevan joined
22:53
elmex joined
23:05
weinig|bbl is now known as weinig
23:07
frankg joined
23:09
stevan_ joined
23:11
dduncan joined
23:18
Psyche^ joined
23:32
Psyche^ is now known as Patterner
|
|||