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
|