Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2006-02-10

Perl 6 | Reference Documentation | Rakudo

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:03 lisppaste3 joined perl6
00:26 frederico joined perl6
00:38 avar joined perl6
00:51 azuroth joined perl6
00:53 stevan joined perl6
01:01 xinming joined perl6
01:16 xinming seen audreyt
01:19 obra andreyt mentioned to me yesterday that she is largely offline dealing with work and life these days
01:22 bsb left perl6
01:31 stevan_ joined perl6
01:35 xinming obra: How about the seenbot? go with audreyt ? :-P
01:35 drbean joined perl6
01:35 obra heh
01:42 b00t joined perl6
02:01 vel joined perl6
02:02 frederico joined perl6
02:09 putter joined perl6
02:09 putter stevan: ping?
02:14 putter Anyone up for a chat by the imaginary whiteboard?  Topic: How to get perl6 by April 1st (yes, _this_ year - 6wks)
02:15 b00t joined perl6
02:15 azuroth the imaginary whiteboard, eh?
02:16 putter yes, the one over there.  next to the pub.  and the munchies.  good for brainstorming.
02:16 putter interested?
02:17 azuroth sure. I'm not sure just how much input I could have, though
02:17 obra putter: how do you propose to get the spec finished by then?
02:17 * putter really needs someone to say "what?!? 6 week?  you must be insane!: ;)
02:17 obra I believe that's what I said ;)
02:18 putter azuroth: awesome
02:18 putter obra: "perl6" is many things.  I mean...
02:19 * obra waits for it
02:19 putter something which runs everything we believe it should.  not as fast as one might wish, but sufficient to use it as the platform in which to rectify that.  I don't mean...
02:20 putter that the spec is finished, or that there has been any kind of release process, or anything like that.  simply that ever line in the spec actually runs.
02:20 putter make sense?
02:20 obra ah.
02:20 obra that'd be a very cool effort.
02:21 * putter waits for "but 6 weeks?!?"... ;)
02:23 putter or "I don't believe that's possible - explain"?
02:23 azuroth I like the second one
02:24 * putter thinks best with a foil, someone point out bugs and areas which need clarification (like with the "what is p6")
02:25 obra putter: the biggest problem is making sure that you have a good test suite
02:25 obra do you have any sense of how close pugs is yet?
02:28 drbean_ joined perl6
02:29 putter The pugs test suite?  distant.  how distant depends on what one means by "good".  coverage is uneven.  some things, eg parser constructs (eg, token, statement_control) are completely absent.  somethings, like objects, are quite superficial.  some things, like say arrays, aren't too bad.  nothing is very intense.  
02:29 putter re "the biggest problem"...
02:31 putter only if you're doing TDD. (test driven development - write test before code).  otherwise... the absence of code is a bit of an issue ;)
02:33 putter given a full language coverage but perhaps buggy p6 implementation, which passes the existing suite, the current limitations of that suite would seem a secondary issue?  no?
02:35 putter though i should note that a subsequent part of this argument is that the implementation is largely written in p6 itself.  so one can be fairly confident that at least those idioms used by the implementation are working correctly if the thing can past the test suite.
02:35 kattana_ in 6 weeks there may simply not be enough time to right all the tests, righting higher level test, that require more things to be working to pass might encourge things to speed up?
02:36 kattana_ *writing
02:36 kattana_ is now known as Kattana
02:37 obra I'd argue that writing the tests is the best way to make sure that we have an implementation
02:37 obra and doing it without tests, I think it just won't happen at all
02:38 putter i'm not sure what you just said...  ok, "6 wks isnt enough time to write all the tests", and... a question on whether writing "higher level tests" would speed pugs development??
02:39 obra Sorry. I meant that if you don't think the relevant tests can be written in time, I don't think there's any way the implementation can
02:40 putter obra: re "the best way to make sure that we have an implementation", ah, but I don't claim that (or maybe I did, but I don't just now).  simply 1- coverage (everything in the Snn runs), and 2- the existing suite passes.  or I suppose and
02:40 obra how is 1- different than what I'm describing?
02:41 putter 3- that the implementations use of objects and parser constructs would itself serve as a test of these currently less tested features.
02:43 putter obra: ah, i see.  all the _code_ in the Snn works.  confirmation of sentence by sentence compliance would indeed require a non-trivial increase in test size.   I guess...
02:45 putter I'm thinking of sentence-level conformance as being less interesting than coverage, if only because so much isn't specced that even a happily working implementation is likely to become non-conforming with every other sentence added.
02:46 obra putter: yeah. but that's also tests that a lot of people could get involved to write.
02:46 obra it's a lot easier to write tests than haskell ;)
02:46 putter yes.
02:46 obra it might help with nothingmuch's concerns that pugs development is slowing
02:46 putter but...:)
02:46 rantanplan_ joined perl6
02:46 obra even if you start with one syn ;)
02:46 putter my argument is basically going to be that we should do a complete p6 implementation _in_ p6.
02:47 obra well, that's certainly audrey's intent
02:47 putter so there is no shortage of p6 writing opportunities...
02:47 putter right.  my understanding is the pugs path is basically...
02:48 putter move stuff out of the hs core into p6... unfortunately,
02:49 putter painful compile time on the Prelude.pm blocked unloading Prim.hs to there, as was the original plan... hmm...
02:50 putter there was, more that half a year ago(?), the follow up task of making the existing prelude compilation mechanism work with multiple files...  I'm not sure if that proved technically impossible, or if the task was just forgotten...??
02:53 putter any way, so slow Prelude compilation killed that effort to unload Prim.   Unloading Prim is now on the todo list of PILn.  Beyond unloading Prim, and likely moving most of the p6 prelude (Array's etc) into p6 as well (I think), there is the question of a p6 implementation of the p6 runtime core.  That I think
02:54 putter is a ways out on the pugs intent timeline.
02:54 putter My proposal / "hand wavy thingy", is it be moved right up front.
02:56 putter there is a lot of overlap with what will be needed (I want to say soon, but a PIL which understands classes has been "rsn" for quite a while... sortof soon, but probably not in time for an Apr 1 win)... needed for piln.
02:57 putter the whole object space basically.
02:58 putter I want the rest of a p6 implementation too (parser, namespace, dispatch)
02:58 putter etc
03:00 putter because given that, it is *easy* to transform it into a equivalent code in a similarly dynamic and wizzy language (ruby or common-lisp basically).  by hand.  and write a simple p6 ast crawler which emits say ruby.
03:02 putter obra, Kattana, azuroth: still around?
03:02 Kattana pong!
03:02 putter :)
03:02 azuroth I'm listening
03:02 obra sorry. busy
03:03 putter tnx.  np :)
03:03 putter ok...
03:03 Kattana I have absolutly no clue about whats going on with anything or I would say more.
03:03 putter ok.  but if you have any questions at all, just jump in.  explaining things is a great way to think...
03:04 azuroth so basically we want all the code in S* to compile without errors, and maybe even do something useful?
03:05 putter yes :)
03:06 putter p6 being hands-down the best language around for implementing languages.  better than ruby or CL or ML or ... .  it's one nagging flaw being non-existance.
03:06 putter we have a language we want to implement.  so we try to fudge the non-existence part.
03:07 putter then we can get on with implementing it
03:07 Kattana where is the bottleneck there, not enough fudge packers?
03:08 putter on the path through backends like pil2js and the old pilrun on p5, the bottleneck is pugs's pil not providing any class information.  mostly.  on the path through pure pugs,
03:10 putter it's the broken class implementation (partially due to some type inferencer bugs I believe).
03:11 putter so for a while it looked like one might add information on class decls to pil, and the backends could do the right thing.  that was the original vision for pil2.  now for piln.
03:12 azuroth hmm, okay
03:12 putter the prelude compilation issue I mentioned.  So that's why a lot of p6 writing hasnt happened yet, incrementally on existing implementations.
03:14 putter if we had say an unstuck pil2js tomorrow morning... well, there is a lot to be said for building on working code... but the object stuff is only the _start_.  ideally, you want to write
03:16 putter p6 code which cleanly describes the spec.  but you have an obstacle course.  pugs has to be willing to parse it, and emit it as pil, and then you get to play with it in the backend.  and...
03:17 putter the code you really want to write has things like  statement_control:<while>  rather than having it built in and hardwired in your parser.  so orchestrating the nature of the p6 code, the pugs parser and typesystem and pil emitter, and the backend's implementation, is... performance art.
03:19 putter BEGIN, \d in regexps, for/while/unless... they are all traits/roles/parser directives.
03:19 putter most everthing is, since the idea is p6 should be able to evolve.
03:20 azuroth up 'til now, I thought I vaguely understood what you were saying
03:21 putter so I'm suggesting that it could be (much) faster to write the code for a p6 on p6, using lots of eyeballs and discussion, and then transcode it, than to fight an incremental battle.
03:21 putter azuroth: let's see...
03:21 putter take \d in regexps.
03:22 azuroth as in, [0-9] in p5?
03:22 putter there is actually a (I dont remember what's called without checking)  general \SOMELETTER hook, so one writes... err, macro?...   macro mumble:<d> { [0-9] }    or some such.
03:22 putter yes
03:23 putter its the same in p6
03:23 putter but is simply declared in the prelude.
03:23 azuroth gee
03:23 azuroth that's crazy. I guess it makes sense
03:24 putter :)
03:24 putter the key point is, most all of p6 is like that.
03:25 putter while, as in while true { say "hi" },  is simply... something vaguely like...  macro statement_control:<while> err...  (Match $m) is parsed(rx:w/while <expr> { <statement>* }/) { ... }   or something vaguely like that.
03:26 putter basically, you are filling in the  rule statement { ... }  part of the p6 grammar dynamically.
03:27 azuroth hmm. I like it.
03:27 putter you do somehting similar with <expr>, where you add tokens  (with grammar category token,  token:<whatever>, and with the familiar  infix:, postfix: etc).
03:28 azuroth and it will put out an AST for the thingy to change to whatever backend is necessary?
03:28 putter ok, let's see, ast and backends...
03:29 azuroth or my real question I guess was more like, "how do you define if without using if"
03:30 putter first, all backends arent created equal.  if we already had a language like p6, env and temp and hypothetical variables...
03:30 putter ok, will work around to that in a sec...
03:31 putter and compatible multi methods and inheritance and parameter/argument handling, etc, then it would be very very easy to do a backend for it.  just crawly the ast, emitting the equivalent code in imaginary language X, and you're done.  a few pages of code.
03:33 putter if one's backend is C... then, well, you have a several man-year project.  though perhaps notably faster by _first_ booting p6 on a more appropriate language, and only _then_ attempting the compile-to-C, writing it _in p6_.
03:33 putter as for if,
03:35 azuroth writing the C-emitter in p6? :D
03:36 putter in the p6-written-in-p6 file, the <if> implementation deals with everthing like extracting simple boolean from random objects, and then handwaves.  or just calls the usual if.  when you do the transliteration to say ruby,
03:36 putter you just splice in ruby's if there, in the handwave.   more generally re bootstrapping...
03:36 azuroth hmm, okay
03:39 putter the idea is for the p6-in-p6 to be... executable spec, but not necessarily executable in bulk.  hmm, perhaps compilable but not necessarily executable.  so the ruby implementation can stomp on <if> with it's own prelude, or perhaps just special case if's ast node when doing the compiling...  one still has to worry about
03:40 putter bootstrap, but I'd like to separate it from getting a p6-in-p6 "spec".  the spec is hard enough without worrying about bootstrapping.  and you wont know just how you want to bootstrap until you see it, and compare it with what your, say ruby, has to offer.
03:41 Kattana It all sounds overly complicated.. though thats the whole problem isnt it.
03:42 putter eg, the spec would just say  class Object is Class{} and class Class is Object{};  and  multi sub trait_mumble:<is>(...){...}.  and once you have all that, you can figure out how to fudge the bootstrap.
03:43 putter Kattana: just as given p6, it would/will be easy to do ruby/javascript/basic/apl/etc/etc front-ends and runtimes, given p6, it would be easy to do p6.
03:44 mtgh joined perl6
03:46 putter so we currently have the two challenges of 1- writing p6, a non-trivial language, perhaps the most complex of those just listed, and doing it without a working implementation or language standard, and 2- finding some way to run it. ;)
03:48 putter I'm suggesting that now, perhaps unlike a year ago, one could write a complete p6 in p6.  no doubt with a lot of "fill in the unspecced gaps".  but still something recognizable as the form of the ultimate p6 implementation
03:48 putter and the key, vis the "by apr 1", is writing that is completely parallelizable, and requires only p6 knowlege.
03:50 putter so a bunch of people could plow through the spec, talking on irc, generally avoiding (or batching) the slow path of p6l questions by "plausibly filling in the gaps".
03:50 azuroth we can try, I suppose
03:51 putter "spec says BEGIN etc are all traits, ok, based on the prototype LEAVE that means...<spew code>"
03:54 azuroth how do we start, then. ;-p
03:54 azuroth probably by printing out all the synopses
03:55 putter some are larger chucks, like do quick framework for the rules engine (say procs taking global state and a "continuation" similar proc).  then lots of folks can fill in the conjunction, the "take longest match rather than first" generator, the backtracking operator-precedence rule generator, the definition-may-change-dynamically rule generator, etc, etc
03:55 putter hmmm, how to start then...
03:56 reZo joined perl6
03:56 azuroth hmm. will rules be a huge priority? we have PGE
03:59 putter my understanding is pge doesnt currently do any of the dynamic specification stuff.  so while one might give it say the default p6 grammar (hasnt been tried yet), it's not really taking the approach a p6 parser would.  at least currently.  so as a bootstrap tool it could be quite valuable.  but I don't think it ends up in the final "thing working on apr 1".
03:59 azuroth ahh, okay
04:00 putter re huge priority, well, one _could_ write the p6 implementation in an s-exp form of p6...:)  but it's kind of painful.
04:01 azuroth s-exp?
04:01 putter and the things that make writing a rules engine not too hard, hypothetical variables for instance, have to be done anyway.  once one has all of p6 without a rules engine, the residual amount of work to do a rules engine isn't that big.
04:02 azuroth okay then. excellent
04:03 putter (multisub ((category infix) (name "+")) (....
04:03 azuroth ohhh
04:03 putter s-expression.  think lisp.  without all the extra bits which make real lisp non-trivial to parse.
04:04 putter I suppose you could write the code in yaml... *shudder* ;)
04:05 Kattana you could put it on punch cards if you *really* wanted to.
04:06 putter I'm pretty sure it ends up easier just to do the rules engine.  even if some bits make your head hurt for a while (write a operator precedence parser, which you can fail back into to change what is considered end-of-string, and you can fail back into the longest-token-first selector, and...:)
04:07 * putter wonders, if you combined p6 with punchcards, how productive would you end up being...??
04:09 * Kattana thinks it would depend on the speed with which you could move punchcards around
04:09 putter Kattana: having to retype lines when you make a typo really sucks.  and dropping and having to resort the stack.  and changing anything is painful.  run away, run away.
04:10 putter ok, re how to start...
04:11 putter the fast, apr1 form of the exercise, probably requires several people.  or one skilled but insane person with no life.
04:11 azuroth apr1?
04:12 azuroth oh, right
04:12 putter so a group formation process, of bashing around the idea to make sure it isn't cracked, and what its real shape is and how best to approach it, and thereby getting group buyin, and working out how much time and when people can contribute, ie, some real project planning...
04:14 azuroth sounds good
04:14 Kattana putter: that 2nd requirement, i think i would fit it, but I still have yet to figure out whats going on.
04:15 putter well, tonight's whiteboard exercise is the beginning of "bashing around the idea"...
04:16 vel joined perl6
04:17 putter with your feedback, maybe I'll put together an email "How to have perl6 by Apr 01... 2006".
04:18 putter I'll see what other folks think as the backlog.
04:18 putter s/the/they
04:19 putter basically, I think there are lots of people who would like to contribute, if they could see a way to.
04:20 putter so if a plan was sufficiently bashed at that it seemed likely, drawing people my just happen.  leaving the "minor matter" of orchestrating them.
04:21 putter ???
04:21 azuroth !!!
04:21 putter ;)
04:22 Kattana where does PGE fit in, and what is its role exactly? im just looking at parrot and PGE at the moment, and there is some very familar stuff.. eerily familiar
04:23 putter I'd probably be more gung ho if I didn't have a $job search to do.  Trying to write p6 in a couple of weeks would be fun... but not what I should be doing just now. :/
04:23 joepurl joined perl6
04:24 azuroth heheh. I'm all for helping, when I can. it looks like this semester of TAFE will be busy, but I should have time to spare
04:24 putter azuroth: neat
04:24 putter Kattana: re pge...
04:24 putter ;)
04:25 putter well...
04:26 Kattana putter: you are the one that was encouraging questions.
04:26 Khisanth for parsing perl6 :)
04:27 Khisanth well that was the idea anyway
04:27 putter it's the most working p6 rules engine in existence... (well, in use?  Text.Rules exists but isnt wired in)... and thus figures large in incremental development schemes (which the apr1 project isn't)...
04:28 putter and on a parrot backend, one might be able to use it rather than a compiled-from-p6 rules engine...
04:28 putter but, compiling to pir is _nontrivial_.  both inherently, and in that it still requires a dual track of debug generator, debug parrot.
04:30 azuroth hmm. good point
04:30 putter for this exercise, the objective is an "easy as humanly possible" bootstrap.  which i think technically means ruby or common-lisp, and thus socially means ruby.  which means targetting parrot is something which happens later, once one can write it in p6.  under the apr1 senario.
04:31 putter so I'm not sure pge helps much with an apr1 project.
04:32 putter skimming it's code can give some ideas perhaps...
04:35 putter Kattana: basically, I think gluing to pge, and extending pge in pil, would be far more difficult than simply writing an engine from scratch it in p6, and then transcoding to ruby.
04:38 putter sound plausible?
04:38 Kattana very, like I said, pge is eerily familiar, I think I could do that if I knew what I was doing ;)
04:41 putter right.  and that's one aspect of doing a quick push.  it would make it easy to
04:44 putter have one person grovel through the Snn to find the \d definition syntax, another? to hit the rules Snn for a list of the \d \s etc, maybe hit pge to grab the regexps for them, though I'm not sure pge is doing the unicode versions yet, and spew the p6 definitions for them (using a macro or not).  but the definition of this
04:45 putter plan of action, and the selection of some of the design choices, is something easy to do if there are people about, and rather less so in a "go off and do X by yourself" mode.
04:46 drbean joined perl6
04:48 putter also, it would be nice to have some of the folks who follow p6l around, so you can ask "i'm defining uintN as  subset uintN of ValueType where { $^o ~~ Int and 0 <= $^o <= 2**N };  does that look plausible?"
04:49 putter rather than having a much higher-latency loop of writing the code, and then getting feedback hours/days later.
04:54 putter stevan: btw, what do types look like?  Any does Type?  is there a  subset ValueType of Type where { $^x !~ Object }; ?    role Any does Type{} role Type does Any{} class Class does Type{} class Range does Type{} ??
04:56 putter Kattana: reading, or rather, repeatedly skimming the Snn, and the few Ann sections they reference, is in the "always a useful thing to do" category.  :)
04:59 putter doing little exercises like, ok, it says LEAVE is a trait/role, where does that role get does()ed, etc.  though that kind of exercise is more fun if you're working with someone else.  the study group approach to learing stuff.
05:03 putter I suggest skimming-loop rather than straight reading because random access to answer questions isnt a strength of the current docs, so one may be best off skimming, accumulating questions, which then later get answered in passing.  rather than a top down approach.
05:03 * putter contemplates having/writing an index to the synposes...
05:05 putter ah well.  end of day for me.  good night folks &   thanks for all your help.
05:06 azuroth good night. hopefully we can get rolling sometime soon
05:07 putter yeah.  but in which direction? ;)
05:07 putter &
05:13 Southen joined perl6
05:27 Khisanth eval? my @a = (1..10);
05:27 azuroth ?eval my @a = (1..10);
05:27 evalbot_8956 is now known as evalbot_8958
05:27 evalbot_8958 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
05:27 Khisanth d'oh
05:28 Khisanth ?eval my @a = (1..10); [+] @a
05:28 evalbot_8958 55
05:28 azuroth I always forget what it is too. @eval, ?eval,... so many choices
05:28 Khisanth ?eval my @a = (1..10); ([+] @a)/@a.elems
05:28 evalbot_8958 11/2
05:28 Khisanth hrm that is not so useful!
05:29 azuroth ?eval my @a = (1..10); +(([+] @a) / @a.elems);
05:29 evalbot_8958 11/2
05:29 azuroth ?eval my @a = (1..10); ~(([+] @a) / @a.elems);
05:30 evalbot_8958 "5.5"
05:30 azuroth hmm. that's interesting
06:00 weinig joined perl6
06:09 stennie_ joined perl6
06:11 Khisanth joined perl6
06:14 r0nny joined perl6
06:20 stennie joined perl6
06:21 spinclad putter and whiteboarders: I'd be inclined to target PIL2/PIL^N, already intended to be the point of fanout to various backends.
06:25 spinclad (already the second generation design in pugs, based on first-gen backends, and steven and audrey's object model work.)
06:30 spinclad PIL2 and/or PIL^N serve as nothingmuch's Perl6Core layer nicely, I think.
06:31 azuroth I like them apples
06:31 * PerlJam idly wishes he'd kept up with the PIL work
06:31 spinclad we have -- luqui I think? -- working on a port of pge to the pugs arena.  not sure which language: Haskell (parsec), PILN, or some higher level of P6.
06:32 PerlJam spinclad: audrey was working on a PGE-in-Haskell (using Parsec)
06:33 drrho joined perl6
06:33 spinclad ah, that must be it...
06:34 GeJ joined perl6
06:37 PerlJam It's utterly amazing that a "non-existant" language like perl6 has such a huge following ;)
06:37 spinclad I could see looking to translate that to PILN, then in whatever-perl6-we-can-currently-parse...
06:39 spinclad a similar sized bootstrap knot to the meta-object one, just maybe...
06:43 spinclad I'd call Apr 1 insane; my only question there is _is it insane *enough*?_
06:43 spinclad (and then just go ahead and let deadlines fall where they may)
06:45 spinclad (oh, and: _am I insane enough to match?_)
06:46 spinclad __END_
06:46 spinclad _
06:47 lypanov __DATA__
06:47 spinclad __SPEC__
06:47 spinclad __CODE__
06:47 lypanov "
06:48 Khisanth PerlJam: depends on how you look at it :)
07:17 drbean joined perl6
07:35 szbalint_ joined perl6
07:36 scook0 joined perl6
07:48 pdcawley_ joined perl6
07:57 szbalint joined perl6
08:23 stennie_ joined perl6
08:25 Supaplex __SLEEP__
08:26 G2 joined perl6
08:45 stennie joined perl6
09:28 j0sephi joined perl6
09:29 gaal_ joined perl6
09:33 Cryptic_K joined perl6
09:41 kanru joined perl6
09:43 gaal_ is now known as gaal
09:51 xern joined perl6
10:09 feng123 joined perl6
10:21 xinming joined perl6
10:37 elmex joined perl6
10:48 ValeFiona joined perl6
11:01 Aankhen`` joined perl6
11:01 iblechbot joined perl6
11:16 SamB joined perl6
11:33 bsb joined perl6
12:07 feng joined perl6
12:09 penk joined perl6
12:12 chris2 joined perl6
12:21 dada joined perl6
12:32 theorbtwo joined perl6
13:22 avar joined perl6
13:27 kolibrie joined perl6
13:34 hexmode joined perl6
13:42 feng123 joined perl6
13:46 avar joined perl6
14:04 wilx joined perl6
14:04 stevan_ putter++ # your make all use look sane ;)\
14:04 stevan_ is now known as stevan
14:10 avar joined perl6
14:15 avarab joined perl6
14:16 icman joined perl6
14:16 icman left perl6
14:26 Qiang joined perl6
14:30 bsb_ joined perl6
14:38 rantanplan_ joined perl6
14:41 wilx joined perl6
14:42 vel joined perl6
14:46 drbean left perl6
15:04 ingy joined perl6
15:04 gugod joined perl6
15:18 TMTOWTDIt joined perl6
15:25 iblechbot joined perl6
15:46 robkinyon joined perl6
16:29 grayson joined perl6
16:39 svnbot6 r8959 | bsb++ |  Add env and ::ENV to quickref/namespace.
16:39 svnbot6 r8959 | bsb++ |  Fix "let" example to match S04/"Definition of Success".
16:48 sahadev joined perl6
17:10 Juerd rafl: Have you arranged travelstuff to .be yet?
17:10 Juerd rafl: It's about time we picked a place to stay, by the way
17:32 Steve_p joined perl6
17:37 putter joined perl6
17:37 putter stevan: ping?
17:39 putter I realized falling asleep last night that the organizational difficulties I had with the "p6 prelude to flesh out piln" code was exclusively a limitation of implementations, not p6.  Given that  sub foo(){ multi sub *bar(){} } only defines bar _when foo is called_, (and using a "redefine" or whatever it's called trait to avoid errors), one can
17:41 putter can say   sub p6_my_way () { sesame_bun_lightly_tosted(); burger_medium_rare(); onions_but_only_if_fresh() }  BEGIN { p6_my_way }
17:41 putter :)
17:41 putter add a  sub foo($pkg) { multi sub ::($pkg)::bar ...} and you can inject it anywhere you want.  yay.
17:42 putter that of course also makes import very easy to write
17:43 stevan hey putter
17:44 * stevan wonders what kind of orange juice putter drinks.. and if it is legal in his state ;)
17:44 putter If the official line is/becomes that bar should be defined at compile time, then one can workaround by simply doing  sub foo { my multi sub bar ...;  FIRST { *bar := bar } }  or some such.
17:44 putter hey stevan
17:46 putter does that look plausible?  it makes the "assemble the p6 prelude out of assorted alternate implementations ad backend-specific pieces" quite straightforward, no?
17:46 stevan putter:  i think the goal should be to have a universal prelude first
17:47 stevan ignoring for the moment the back-end specifics
17:47 * stevan is actually pondering giving up PIL^N for PIR
17:47 putter *shudder*  putter cries "don't do it stevan!"
17:48 putter but taking it in order...
17:48 * stevan queues the booming nationalistic music
17:48 stevan putter: someone has to ;)
17:48 putter re universal relude,
17:48 putter laugh
17:48 stevan putter: chromatics point about cost of entry has got me thinking
17:49 stevan and I think that if we follow nothingmuch's plan about breaking things up,.. but all the while making sure to keep the implemenations acessible,.. then we might get back the momentum which does (I hate to say it) seem to be lost
17:49 hachi joined perl6
17:51 putter say you are fleshing out the Array methods.  there is often a non-obvious choice of building foo on top of bar or on hee.  key point: just making that choice, _even if it's always right and never has to be changed_, is harder than just spewing out the two versions.  do I build this on splice, or on push/pop?  doing both is a seconds work, trying to decide
17:51 putter which way the Array impl should go is _hard_.   and then as just shown, combining the pieces is trivial.
17:52 putter so it's actually _easier_, faster, to write a mix and match prelude, than to try and get a unified set of choices all lined up.
17:52 stevan putter: I dont think we need to make unified set of choices
17:53 stevan I think we need to ignore the idea of the multiple backends and create a single prelude for a single puporse
17:53 stevan s/pupose/backend/
17:53 putter Ok.  then I think we are in violent agreement. ;)  
17:53 stevan after which it will be much easier to tweak it for a particular backend
17:53 stevan :)
17:53 stevan Perl 6 has enough facilities to redefine ANYTHING, so we need to worry about boxing ourselves in
17:54 putter re recent thread on p6l, I haven't read it.  though I backloged irc.
17:54 putter I agree momentum is lacking
17:54 stevan putter: read it if you are procrasinating on your job search,.. but otherwise probably worth ignoring
17:54 stevan other than Yuval's mails
17:54 stevan which are about the "what we can actually do" part
17:55 putter and cost of entry argument is valid, even if not in some particulars, certainly in the "there are lots and lots of people who would contribute if they could, but dont see a way to".
17:56 putter a people-resource under-utilization state seems clear
17:56 stevan yup
17:56 * stevan is definitely under utilizing putter
17:57 putter one of the things I liked about the apr1-spike idea is that _everyone_ wants to learn p6, and all the work is in p6
17:57 stevan I am not clear on that idea
17:57 stevan just ran full force to write it in p6?
17:57 stevan what will it run on
17:57 stevan what will we test it on?
17:57 iblechbot joined perl6
17:57 stevan how do we know its not all broken
17:57 stevan many assumptions will need to be tested,.. approaches hacked out, etc etc etc
17:58 * stevan dodges peices of falling sky ...
17:58 putter transcode a core of it into a semantically similar language (ruby or CL).
17:58 putter re many assumptions, etc, could you give an example?
17:58 stevan hmm
17:59 stevan I think only CL would give us the right amount of flexibility
17:59 putter one counter arg to the spike idea is "but we _can_ write a complete p6 implentation in p6 because... something".
17:59 stevan but there is our barrier to entry again,.. I mean not as high as Haskell,.. but higher than most
18:00 r0nny joined perl6
18:01 Khisanth just do it in C! ;)
18:01 * stevan runs screaming from the room... noooooottttt CCCCCeeeeeeee
18:02 stevan I would sooner do it in PIR ;)
18:02 putter in thinking ruby v CL, my thoughts were:  rb - no macros - makes tree transforms more of a pain.  CL - much more verbose; larger appearance divergence vs p6, making transcoding harder.  Neither has unification or even good pattern matching.  CL has env. but that's easily faked.  rb will run sllooooowwweer.  so
18:02 obra . o O { Perl6 in rails }
18:02 stevan :D
18:02 obra Just because I want to be difficult, putter: am I missing the bit where you discarded perl5?
18:02 stevan hell yeah,.. I mean you can write anything in RoR
18:02 * obra grins
18:02 Khisanth so how many different interpreters and compilers are peopel going to need to install to build perl6? :)
18:03 * obra is building Jifty 2.0 in rails.
18:03 * obra is also pulling your leg
18:03 stevan putter: CL has great pattern matching cl-pcre is supposed to be very fast
18:03 putter the first order of business for a p6-on-rb is likely to do a p6-to-CL compiler or somesuch.  Though rb may be close enough to p6 semantically to do a p6-to-rb compile with not horrible performance (if one can map a lot direct to ruby wo an abstraction layer).
18:03 * putter backlogs
18:04 * stevan slips some valium into putters coffee in hopes to slow him down just a little
18:05 stevan oh hey,.. I just realized,.. obra is in boston too,.. we now have our third member of the first NE P6 monger group
18:05 PerlJam stevan: great!  Now perl6 will be even *more* delayed!
18:05 * putter back from call, backlogs
18:05 stevan PerlJam: slow and steady wins the race ;)
18:06 obra stevan: who else is in boston?
18:06 stevan putter:
18:06 stevan and I am in CT
18:06 stevan just down the road
18:07 putter awesome, NE P6 Monger group established! :)
18:09 putter re CL pattern match, sorry, I meant structure match.  for more declarative tree transforms w/o having to grovel around.  but actually, under the current senario, that doesn't matter at all.  because p6 doesn't (yet) have it, and the only CL code which get's written, at least in the first/only "let's get p6 running" phase, is transcoded from p6
18:10 putter obra: re p5
18:10 * stevan bangs his gavel - I call the first meeting of the NE P6 mongers group to order,.. who brought the pizza
18:11 * putter mutters, "oops, I knew I forgot *something*..."
18:12 bsb_ left perl6
18:12 putter p5 clearly has the lowest barrier to entry for our potential-helper pool.
18:14 stevan I am not sure p5 is a good language to write a compiler in though
18:14 stevan that is always been my concern
18:14 stevan is P::RD up to the task?
18:14 stevan or do we need a Parsec port?
18:14 putter but... ok, two parts:  ugly/broken/slow, and the transcoding should be a small number of people, short duration, throw away the code afterward exercise.
18:15 stevan or even better a Perl6::Rules port?
18:16 putter ugly- both ruby and cl have better metaprogramming.  ruby will also be syntactically much clearer.  since bug hunting at the "transcode and bootstrap" phase will likely be very painful to deal with, clarity is quite important.
18:18 putter broken - well, that's too strong.  but we'd have to take p5, add a one or more of the class and/or multimethod libraries, and ...  at which point one might have a poorly speced version of rb or cl's out of the box capabilities.  (oh yeah, rb disadd vs cl - lack of native multimethods)
18:19 obra note also there was the whole p6c effort way back when
18:20 PerlJam was?
18:20 PerlJam you mean in p5?
18:20 putter slow - the regexp engine should use exceptions extensively.  it p5... ouch.  rb is quite bad enough.  (that's another cl add, but oh well).  but actually, this is all just rationalization.  the _real_ motivator is...
18:20 Juerd putter: Ruby has clean syntax, but surprising symantics. I'm not sure if it's good for writing a compiler. In addition, it's slow.
18:21 PerlJam How much does slow matter to a bootstrap?
18:21 Juerd PerlJam: Obviously a great deal, as that's the most important argument against using pugs for it.
18:21 GeJ hum, pardon me, but when talking about "CL", you mean? Common Lisp?
18:21 putter I am confident I can quickly transcode large bunches of p6 code into rb/cl which is no more buggy than the original p6.  I am not at all confident, indeed dont think I can, do the same into p5.  But maybe that's just me.
18:22 PerlJam Juerd: I think that a foolish argument.
18:22 Juerd PerlJam: I see. Then why not use Pugs?
18:22 stevan GeJ: yes that is correct
18:22 putter GeJ: yes
18:22 GeJ thanks
18:22 Juerd It has much of the language already implemented, which gives things away for "free", reducing the "cost"
18:22 PerlJam Juerd: Is it "complete" enough though?  
18:22 Juerd Which makes having a somewhat higher "entry level" less of a problem
18:23 * PerlJam hasn't looked at pugs in a while.
18:23 Juerd PerlJam: I think it is, and those things that need implementation badly, can perhaps be prioritized.
18:23 putter stevan/obra: am i synced with you?  missed anything?  backlogs...
18:23 * stevan attempts to read putters mind and check......
18:24 stevan maybe we need to look at the smalltalk model
18:25 stevan put it all on top of the object model and just compile code method by method to the VM
18:25 obra putter: mostly, I'm just making trouble. I haven't had the cycles to think hard here.
18:25 Juerd I think that in any case, it's probably a good idea to wait until Audrey is back. She can estimate better than any of us, if Pugs will be suitable for bootstrapping.
18:25 PerlJam 30+ years later and unix is still the best OS model and smalltalk the best OO model  ;)
18:25 PerlJam Juerd: I agree.
18:26 stevan Juerd: I dont know if it is a suitability issue,.. I think it is (like chromatic said) a barrier to entry model
18:26 stevan work stalls without audrey around
18:26 putter Juerd: re surprising semantics, slow.  yes.  but quite good metaprogramming.  semantics - the oddities tend to be avoidable with care.  this would be quite stereotyped code.  re slow, undoutably.  but basically, the only thing it will ever have to run is p6-ast-to-something-else (direct to rb, or cl, or whatever is faster) compiler, "once", over the p6 implementation.  then it's trash.
18:26 Juerd stevan: But what is worse? Having to re-implement everything that pugs already did, or having that somewhat higher level of entry?
18:27 Juerd stevan: I don't think that what was done with Haskell in a year can be redone in any other language in two.
18:27 stevan Juerd: pugs is already re-implementing everything pugs did ,.. that is the whole new runcore idea
18:27 PerlJam stevan: *pugs* work stalls, but perl6 work doesn't have to.
18:27 stevan Juerd: you may be right on that point (the time point)
18:27 stevan PerlJam: I know,.. but that is a seperate issue
18:28 putter obra: trouble is most valuable.  forces things to be explained/thought through.  my worst case fallback for "cant find anyone to have a design discussion with" is sometimes (well, once or twice) to fire up Eliza. :)
18:28 Juerd stevan: I equate time to "cost", for easier discussion. This common business model may perhaps not work for open source. I'm not sure.
18:28 stevan PerlJam: I do think that speed of work on Perl 6 (the design) is directly releated to speed of pugs development though
18:29 obra putter: mostly, I worry that this implementation will take effort away from the other two, which is why I see the test suite work as so valuable
18:29 stevan somet things just need to get tried out before descisions can be made
18:29 Juerd I think it'll be valuable to search for optimizations in Pugs.
18:29 Juerd From what I've heard, there's lots of opportunities to be explored.
18:29 stevan Juerd: very true
18:29 Juerd I found gaal's FPS suggestion very interesting.
18:29 * stevan really enjoys spring cleaning :)
18:29 PerlJam stevan: sure, but now that there's enough of pugs working, I think there's only a small factor in the relation.
18:30 PerlJam stevan: i.e., there's a direct relation, but the pugs end of it isn't as big as it once was and is, in fact, quite small
18:30 stevan PerlJam: not true re: object model,.. there are some questions I have which had not been answered and I dont think will be answerable until someone (probably me) make a prototype to test it out
18:31 stevan Perl 6 is an OO engine - so sayeth S02 ( i think thats the one )
18:31 Juerd stevan: Why a prototype? I believe that no time is wasted by starting on the real thing, and skipping prototypes, which is quite the same as starting with prototypes and then using them in production, only it results in much higher quality of work.
18:31 PerlJam stevan: yes, I know,  I was being flippant.  It's the mood of my Friday.  :-)
18:31 stevan PerlJam: :)
18:32 stevan Juerd: a prototype is sometimes easier to write because you can hyper focus and not worry about effecting other parts of the system with your proddings
18:32 DesreveR joined perl6
18:32 putter obra: one key point is the "write p6 prelude (Prim.hs plus objects(Array,etc)) in p6" task is both on the piln "next steps todo list", and similarly on a apr1-spike.  so one could do that first ;)   though the social dynamics of the two are very different.  so while it's worth, say me, doing first to explore whether a spike
18:32 Juerd stevan: So can you in the real thing.
18:33 stevan Juerd: meta-models have a tendency to dive into infinitely recursive recusion if you poke them the wrong way
18:33 Juerd putter: whether a spike$
18:33 putter is posible, I wouldn't want to drum up group activity unless people had examined and bought into a spike model.  getting lots of people excided, and then hitting "but piln can't really run it, and pugs can't really parse it", would be a no-no.
18:33 Juerd stevan: Then perhaps making mathematical models out of them mathematically proving them is a good idea. I think luqui is strong in that area.
18:34 stevan Juerd: $proof != $working_code though
18:34 Juerd stevan: No, but if you have proven something, you probably know what way to poke it :)
18:35 stevan Juerd: most of the details which I am talking about are closer to implementation details anyway,. and not theoretical anyway
18:35 Juerd I see
18:35 stevan Juerd: its the meta-circularity that gets you,.. which is not very math-like (or so I have been told)
18:36 putter stevan:Juerd: perhaps I shouldn't say "p6".  how about, an acceptably performing bootstrapped implementation of pX.  where pX can tightly follow the changing spec.
18:38 putter I think of the details as less important than bootstrapping.  In fact, one idea for an apr1-spike is _no requests for clarification_.  Perhaps no great effort even to extract clarity from the Snn.  What matters is a _flexible_ (ie, pX) implementation _running_.  Then the rest, syncing with Snn, etc, becomes easy.
18:39 Juerd putter: I fear you're speaking on a somewhat higher language than my parser can handle.
18:39 putter Hmm, maybe that's a core argument: "we have enough to bootstrap now, and a bootstrapped pX is the most appropriate place for rapid further development".
18:40 stevan Juerd: I think we all feel that way about putter sometimes ;)
18:40 * stevan wanders off to handle some $work business ... be back later
18:41 PerlJam putter: you'd better get more of a concrete noun than "pX" if you vet this on p6l  :)
18:42 putter Juerd: ok, and stevan: :)  the argument is 1-we can currently, with reasonable effort and good use of people resouces, create a self hosting (implemented in itself) implementation of pX, where pX is a language similar to that currently in the p6 spec docs.  and 2- such a language and implementation is a good (best?) platform for developing p6.
18:42 audreyt putter: I parsed you, and I agree. :-) but it's 2:41am and I'm totally burnt out from $job, so I'm afraid I can't help you much on elaborating this though stream :)
18:42 audreyt s/though/thought/
18:43 putter Bascially the "p6 is platform for developing hypothetical ideal language p7" argument shifted.  "pX is the platform for developing a hypothetical nifty language p6". ;)
18:43 PerlJam putter: s/pX/pugs/ and we're good to go :)
18:44 putter audreyt: lol :)  neat!
18:44 stevan putter: I totally agree, the question is what will pX run on?
18:44 * putter has to go off for lunch soon anyway.  but I'd love to hear your thoughts at some point.
18:44 audreyt (I parsed you as: "instead of limiting ourselves to prelude, write _everything_ in the p6 as supported by pugs, and focus pugs's Hs toolchain to compile that subset into something that runs in reasonable space/time"
18:44 audreyt )
18:45 Juerd putter: And why could this pX not be p5 with additions?
18:45 PerlJam Juerd: because there would be too much work to do in p5.
18:45 audreyt where the everything includes but not limit to the object space, parser, semantic analyzer, etc.
18:45 Juerd I see
18:46 PerlJam Juerd: and it would be like starting form scratch again with a slightly broken (perhaps mismatched is a better word) tool
18:46 PerlJam in other words, I (at least) don't think p5 is the right tool for this job.
18:46 audreyt putter: although, to fruitfully write the compiler (tree transformation) part in perl6, we still need to get 6.281.x level support -- i.e. with sane roles and rules support
18:46 putter audreyt: ah, no, there's a key divergence/point.  I'm proposing that discarding the limitation of "p6 as supported by pugs" buys so very much, that it's worth losing the ever valuable "keep the code running" and doing a pure p6, unconstrained by implementation, spike.  and then transcoding bits of it at the end, to get back to something running.
18:47 audreyt putter: I think we are in vehement agreement.
18:47 audreyt I meant:
18:47 audreyt pretend we have 6.281.0.
18:47 audreyt and write a p6 compiler in p6 targetting that.
18:48 PerlJam audreyt: so putter's "implementation spike" == 6.281.0 ?
18:48 audreyt and meanwhile, either improve pugs's support, or (as you said) selectively desugar it in adhoc ways back to something (ruby? parrot? clos? pugs?)
18:48 audreyt to get it running in the end
18:48 putter ah, yes :)
18:49 audreyt PerlJam: I think it makes sense. writing a compiler in a dynamic language that has no typechecking semantics is possible
18:49 audreyt and the compile-time type semantics is too unreliable at this moment
18:50 audreyt s/unreliable/unspecced/
18:50 PerlJam works for me.
18:50 dduncan joined perl6
18:50 audreyt that even if the spike is to be written with advanced type features, we wouldn't agree enough to make it work productively
18:50 audreyt (unlike the OO/rules part, where we could agree how they should work on the surface)
18:50 PerlJam though it suddenly feels like we're talking about bootstrapping perl6 by using N languages rather than just 1 and that's a little weird.
18:51 audreyt PerlJam: but in effect, each milestone of Pugs is a different language
18:51 audreyt (or at least that's how I perceived it to be)
18:51 dduncan gree tings
18:51 PerlJam audreyt: yes, that's the way to look at it.
18:51 PerlJam audreyt: I just didn't get there until a few minutes ago.  :-)
18:52 audreyt putter: so... this is very exciting :)
18:52 putter PerlJam: it's more, just write p6 in p6.  including a compiler to whatever-easy-target.  then handwave magic briefly.  and then it's running, and self hosting, and you can forget about the magic.
18:52 audreyt putter: but the p6 you write p6 in is p6-as-we-understand-today
18:53 audreyt that is, without luqui's type magicks
18:53 audreyt or advanced ast-transforming macros
18:53 audreyt but with everything else
18:53 putter yes.  but the parser and oo multi models seem flexible enough to arbitrarily evolve pX, no?
18:53 audreyt sure... we are in vehement agreement. :)
18:54 putter :)
18:54 PerlJam And pmichaud and Allison's work provides a nice counterpoint?
18:54 * putter pictures the amount of work involved and wishes for someone with an insightful "but that wont work / doesnt make sense  because..."
18:54 putter ;)
18:54 audreyt PerlJam: counterpoint to what? :)
18:55 PerlJam to putter's imagined workflow.
18:55 * audreyt is feeling very rejuvenated -- just finished reading a draft "history of haskell" paper by Hudak/Hughes/SPJ/Wadler
18:56 audreyt titled "Haskell: the dream that stuff is made of"
18:56 putter oooh, neat.  online?  or behind the evil ACM DL event horizon?
18:56 PerlJam Perhaps it's just me, but I see what pmichaud is doing as more of "traditional compiler writing" and what putter/audreyt just described as "post-modern compiler writing"  (if I can borrow from Larry ;-)
18:56 audreyt putter: no, private copy :)
18:57 audreyt and GHC went through this early imaginative-bootstrap (over a very slow and very leaky LML-hosted bootstrap) long ago
18:57 putter oh, draft.  neat.  look forward to it.
18:57 audreyt with help from some very adhoc desugaring evail scripts written in p5
18:57 audreyt s/evail/evil/
18:58 r0nny joined perl6
18:58 putter ah, I was wondering where the p5 involvement in ghc came from
18:58 audreyt it would be like your planned use of ruby ;)
18:59 audreyt not yet convinced it'd be neccessary, but I'm cool if it turns out to be useful.
19:00 audreyt putter: ok. so, how's your cycles looking like in the next 40 days? :)
19:01 putter yeah.  it would be simpler if one could transcode to p6-as-running-in-pugs.  I'm specing ruby mostly because it has lower risk / "gotcha" potential.  It seems clear one can do a rb transcode.  with a pugs transcode, one might hit something which requires non-trivial pugs implementation changes to work around.  rb is a more distant, but firmer platform.
19:02 putter re cycles... I really have to think about that one.  I'm just not sure.
19:03 audreyt I'm thinking of transcode to yarv.
19:03 audreyt maybe we can get sasada or matz on the yapc::tokyo hackathon.
19:03 audreyt (which would dramatically speed up this)
19:03 audreyt s/tokyo/asia/
19:03 binary42 joined perl6
19:04 audreyt putter: in any case... I'd like to make p6 a good language to write compilers with :)
19:05 audreyt (which would be this spike's primary contribution to the ongoing design evolution, if nothing else)
19:05 putter I suspect (I think) that the transcode target mostly affects the "oh, no, try to keep that section of code simpler since we'll have to transcode it" choices of simpler.  I'm not sure how much variation that actually introduces.  and the transcode target needn't be the first pX compiler target.
19:06 audreyt no, but it makes more sense (and is more smooth) if it could be.
19:06 putter yes
19:06 putter err, yes, to earlier line, re "no, more sense"...
19:07 audreyt (and as long as you are transcoding, p5+MOP is no worse than ruby really.)
19:08 penk left perl6
19:08 audreyt since you wouldn't touch the surface syntax; it's all codegenned
19:08 audreyt and ruby isn't that easier to gen than p5.
19:08 audreyt (as compared to read/write by humans, which it could be significantly easier)
19:08 obra MOP?
19:09 audreyt meta-object protocol.
19:09 obra ah
19:10 putter re "no, more sense"... I'm not sure.  the constraints the two operate under (human transcode of small bits and eyeball similarity,  vs easy to write in working p6) are quite different.  also maybe the time frame for when they get written.  the main thing they could share is the design discussion/though of how to target the platform.
19:10 audreyt right. so whatever works works :)
19:11 audreyt putter: are you going to write this up in a more structured english text?
19:11 putter :)  re code gen, codegen leaves me with a "it should work, but I wouldnt really bet my arm on it" kind of feeling.  I was thinking that the bit which needed to be transcoded was small enough that one could actually type it by hand.
19:13 audreyt putter: ah, but there is this gray zone between full-parse-compile-codegen and transcode-by-hand
19:13 audreyt namely, adhoc rewrite rules, with regexes
19:13 audreyt (think your average html scraper.)
19:13 putter re write, this up... yeah, I should.  ok, I'll try to get something out today.  we still haven't talked about the social and logistical stuff of trying to make it happen fast.  actually, what aspects would you like written up?  putter ponders...
19:13 rantanplan_ joined perl6
19:13 putter audreyt: re rewrite, agreed.
19:15 putter but yes, I can sketch out the argument I've been running.  then we can fiddle from there.
19:15 audreyt I'd like a problem statement; a requirement statement; an overview of the spike's architecture (i.e. plan of attack); and then it's a matter of writing up the docs/interfaces for the components.
19:15 audreyt the latter part I already agreed to do with nothingmuch/gaal in israel; I'd also love to annotate it with spike p6 code.
19:16 * putter isnt sure there are docs/interfaces or components ;)
19:16 audreyt the spike p6 code... is the docs/interfaces ;)
19:16 audreyt at least that's how I write my CPAN modules.
19:16 audreyt this one wouldn't be different :)
19:17 audreyt (to elaborate: I think the toplevel API, as expressed in p6 module syntax, makes good interface spec.)
19:19 putter it would be nice if the implementation could be kept "light weight", few files in flattish directories.  so it would be easy for anyone to copy a couple of them, mutate them, and say, "this is what I had in mind".  almost a linux like process.
19:19 * stevan is back from doing $work stuff
19:19 stevan putter: why is transcode better than codegen?
19:20 * stevan ponders a set of p5 scripts to desugar p6 code and what that might ential
19:20 audreyt stevan: codegen implies full semantic parsing of the px
19:20 audreyt which is considerably harder
19:20 stevan true
19:20 stevan what if we did several desugaring passes
19:20 audreyt so transcode (via adhoc regexes and/or wetware) is a mean of winging it
19:21 audreyt aka champagne prototyping
19:21 audreyt (which is another SPJ paper -- this one is sillier, but still fun)
19:21 stevan and eventually arrived at something that looked like the p5 object prototype code??
19:21 putter I guess I'm also thinking of a more bottom-up than top-down design approach.  we know what, say, the declaration of \d for regexps should look like, it's in the spec.  so writing a little macro and fleshing out all of the \X's can be done, without having any idea how that will get integrated into the regexp engine.
19:21 audreyt stevan: er, that's what I meant by "p5+MOP is as valid as ruby as transcode target"
19:22 putter The regexp engine can just assume it's given a list of such things.  and the final rxmumble:<X> macro can glue the two together.
19:22 audreyt putter: yup
19:22 stevan audreyt: BTW - Class::MOP now does Scala style mixins (although that version is not on CPAN yet)
19:22 audreyt stevan: you're crazy
19:22 stevan audreyt: very simple actually,... easier than roles ;)
19:22 audreyt it's easy to implement something when you know what you are implementing l;)
19:22 stevan i needed something to avoid metaclass incompatibility issues
19:23 stevan so audreyt before you go to sleep,.. what is the rough .il hackathon schedule,.. I want to carve out some time in my schedule
19:25 audreyt let's see
19:25 putter so rather than components and apis, I was thinking more along the lines of pour spec into p6 code, which should be implementation-design independent.  and then fill in the gaps with something plausible.  some chunks like the overall architecture of the parser could use a doc.
19:25 audreyt starts at 15th
19:25 audreyt is the prehackathon
19:26 audreyt putter: but those are components and apis :)
19:26 audreyt anything that is relatively independent of other chunks should be split out
19:26 putter yeah, but they are emergent, they don't get speced before hand.
19:27 audreyt and what I was saying is, that the emergent p6 spike code would serve as the defacto spec/interface.
19:28 putter and one can imagine having simultaneous - "oh, we need a lexical namespace system.  who feels like sketching one... ok, C looks good, lets add mumble from B, and go...".
19:28 audreyt stevan: the real hackathon is 21-25
19:28 audreyt putter: yup
19:29 audreyt putter: basically, force^Wnudge^Wencourage p6l to talk in code.
19:29 audreyt which, $deity be blessed, would be a Good Thing.
19:29 putter ah, ok.  thought you were looking for api's and component breakdown in the hypothetical thing to be written today.  
19:29 gaal hola
19:29 audreyt putter: er no, "then it's a matter of writing up" means "after you write this thing today, we can start playing with"
19:30 * gaal backloggeth
19:30 stevan hey gaal
19:30 audreyt sorry for the mistextgen
19:30 gaal hey mr stevan!
19:30 audreyt stevan: conf is 26-28; if I get visa in time, GPW will follow and then it's a 10-day hackathon with leo
19:30 stevan cool
19:30 putter there _are_ advantages to being unconstrained by an implementation.  paper vs metal airplanes an all (design phase vs construction phase).  I haven't been involved enough in p6l to comment on whether the balance could fruitfully be different..
19:31 audreyt stevan: if I don't, then it's another 12-day israel posthackathon
19:31 gaal and if you get it at the last minute, it's a packathon!
19:31 audreyt heh
19:31 gaal is .il secured?
19:31 audreyt yup
19:31 audreyt single entry
19:31 gaal whew
19:32 audreyt ok... I need to sleep really. it's 3:30, and I have this laser operation thing booked in the morning.
19:32 audreyt I'll check back later :)
19:32 gaal laser operation? eyes?
19:32 audreyt nah, removal of facial hair
19:32 gaal take sunglasses with you on your trip if so
19:32 obra my friend rachel's been doing that. "fun"
19:33 * audreyt waves &
19:33 gaal night!
19:33 stevan nice
19:33 stevan thanks for the dates audreyt :)
19:33 putter good night &   (and I'm about to be distracted for a bit)
19:34 * gaal thinks it'll be possible to get away with visas from here
19:53 arcady joined perl6
19:57 hcarty joined perl6
20:08 larsen joined perl6
20:28 hcarty left perl6
20:38 cm joined perl6
20:38 cm yo
20:38 ingy seen whiteg?
20:52 PerlJam I just looked at the PyCon schedule and it seems they only have development stuff after Sun Feb 26.  The conference proper is from Thu Feb 23 to Sun Feb 26
20:53 PerlJam oops
21:15 rantanplan_ joined perl6
21:29 Shillo joined perl6
21:29 Shillo Hullo, all!
21:31 kanru joined perl6
21:32 KingDiamond is now known as KingDiamond|away
21:39 DesreveR joined perl6
21:40 rafl Juerd: Not yet arranged, but it's planed and I'll be there.
21:40 DesreveR is now known as r0nny
21:45 Medvekoma joined perl6
21:47 jsrn joined perl6
21:55 putter ok, I'm going to grab some dinner, and then draft up a  pX project sketch.  hopefully run it by anyone who is still awake for comments.
21:58 diotalevi joined perl6
22:01 * putter goes to briefly read the "streamlining" thread on p6l.   realizes "briefly" isn't going to cut that...
22:01 Shillo putter: :) :)
22:12 justatheory joined perl6
22:12 putter audreyt: I note http://www.nntp.perl.org/group/perl.perl6.language/24658  didn't like your email encoding ;)
22:16 putter nothingmuch++
22:17 putter nothingmuch: I realize you are probably off snowboarding by now, but it would be great to talk.
22:21 putter pX and your proposal have the same objectives and motivation I think.  my very quick impression is the divergence is part technical (sacrifice "keep the code working" to avoid "have to implement in haskell first") and one social (do an intense short-term project with flexible code "ownership" independent of
22:23 putter section-of-perl6 (eg, no foo owns Bar::Hee, the thingamagic implementation), vs doing the more traditional project decomposition you describe).
22:23 putter s/one social/part social/
22:24 putter ideas on social scheme will be in pX sketch.  though if anyone is around who wanted to ask questions...? ;)
22:28 putter guess not.  ah well.  bbl &
22:31 putter oh, and social/techical - a non-monolithic code set.  think you have a better way to implement widgits, code it and toss it into the pile.  it looks like extracting a coherent set of code from that pile is something that can happen whenever convenient, even as late as compiletime.
22:35 putter btw, if anyone, at all, doesn't buy any part of this, or has any questions, however "dumb", please please please say something.  it will, at a bare minumum, help us understand what we are doing, and thus help us do things differently/better.  thanks.
22:35 putter dinner. bbl
22:35 putter will backlog :)
22:36 Shillo putter: Er....
22:36 Shillo putter: Can't read my normal email now... where's that document?
22:40 Shillo Ick, too late. :)
22:45 pdcawley_ joined perl6
22:51 Shillo left perl6
22:54 knewt joined perl6
23:03 DigitDuke joined perl6
23:03 DigitDuke left perl6
23:28 drbean joined perl6
23:36 Juerd I made the same syntax mistake 5 times in Perl 5 today.
23:36 Juerd map { }, list
23:39 wilx :)
23:39 wilx You need to take a break.
23:47 drbean left perl6
23:48 Cryptic_K joined perl6

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo