Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2011-03-16

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

All times shown according to UTC.

Time Nick Message
00:00 whiteknight lucian: Which assumptions? Parrot's implementation of it necessarily will be a little bit pluggable
00:00 lucian Tene: single dispatch, existance of methods on objects
00:00 jnthn_ joined #parrotsketch
00:01 whiteknight If single dispatch is the current reality of 6model, I can guarantee it isn't the final form
00:01 TimToady given that p6 is not assuming only single dispatch, I don't see how you can claim 6model won't support multiple dispatch
00:01 lucian there's also a method cache
00:01 whiteknight Parrot has and will always support multiple dispatch
00:01 Tene lucian: If objects don't have methods, then your object model's response to method calls should be to throw an exception.  Method dispatch can do whatever it wants in 6model; that's entirely up to you.
00:01 whiteknight lucian: we have (bad) method caching in Parrot now
00:01 whiteknight we cache vtable overrides at a level below the object model anyway, so there's currently no way to avoid that
00:01 lucian TimToady: i didn't say that. i only claim that 6model is at the very least not optimised for multidispatch and no-methods
00:02 lucian whiteknight: being able to flush the cache should be enough
00:02 whiteknight lucian: the most important questions we can ask right now are 1) what can we do to make 6model workable for the largest audience by default, and 2) what can we make pluggable about it so other people can get what they want?
00:03 whiteknight lucian: If you write all your requirements down, we will keep all of them in mind
00:03 allison whiteknight: those are the important questions for 6model
00:03 TimToady lucian: 6model is optimized with the assumption that if you know your dispatcher statically it can be optimized regardless of its single or multiple-ness
00:03 jnthn_ I don't really understand "not optimised for multidispatch", given that it has to support Perl 6 multi-dispatch efficiently.
00:03 TimToady but multiple such dispatchers are supported
00:03 allison whiteknight: the important question for pynie is just "what's the simplest way to get a simple implementation of Python running"
00:04 lucian jnthn_: then i may be misunderstanding
00:04 davidfetter left #parrotsketch
00:04 lucian allison: correction: simple, but complete
00:04 TimToady allison: the word "simplest" is completely fraught :)
00:04 whiteknight allison: We also have a timing issue. porting 6model into Parrot is a project we haven't even started planning for yet. There are certainly no relevant deprecation notices about it in place yet
00:04 allison lucian: yes, complete enough for now
00:04 whiteknight I suppose that a pynie rewrite will precede 6model
00:05 allison whiteknight: yes, "immediately available" is also important
00:05 lucian whiteknight: it'd be gsoc
00:05 lucian so i'm guessing yes
00:05 allison whiteknight: it doesn't preclude 6model at some later point
00:05 whiteknight right, but 6model probably won't be in place by the summer
00:05 jnthn_ I'm not sure what's not immediately available in 6model. :)
00:05 jnthn_ OK, I am. :)
00:05 allison whiteknight: it just means 6model is not looking like a good option for right now
00:05 jnthn_ It's a little bit too tangled with NQP in the odd place.
00:06 lucian jnthn_: https://github.com/jnthn/6model/blob/master/overview.pod isn't clear. could you explain/link multi-dispatch in 6model?
00:06 whiteknight if pynie is implemented now, whatever interface and capabilities it requires will be part of the interface our future object model must satisfy for compatibility purposes
00:06 jnthn_ But that's mostly about what files we stick lines of code in.
00:06 whiteknight so if you build your compiler, and we can put a new MOP in place preserving the majority of the interface and semantics, there's nothing to worry about
00:06 allison whiteknight: that's reasonable, making the immediate implementation a good prototype for future Parrot MOP needs
00:07 whiteknight and if you put together a custom object model, we'll make sure your custom object model continues to work after the advent of 6model
00:07 allison whiteknight: (in much the same way the Perl 6's needs are gradually working their way down to Parrot core)
00:07 whiteknight exactly.
00:07 Tene jnthn_: afaict, there's nothing in 6model that actually requires nqp; the worst is a bit of naming (rakudoobject)
00:07 jnthn_ Tene: Correct. I don't know what to rename it to.
00:08 jnthn_ 6MObject is an invalid identifier.
00:08 jnthn_ SMObject is...painful. ;)
00:08 lucian jnthn_: SixObject
00:08 Tene Which doesn't actually have anything to do with rakudo
00:08 allison SevenOfNine
00:08 jnthn_ Tene: No, the name leaked from a prototype.
00:08 lucian allison: +1
00:08 jnthn_ :)
00:09 jnthn_ lucian: The 6model core mostly just does enough to make sure one *can* implement an efficient multi-dispatcher.
00:09 jnthn_ Trying to provide on canonical way to do multi dispatch isn't really 6model's business. It's mostly interested in not defining too many ways you have to do things.
00:10 allison lucian: one consideration is performance
00:10 allison lucian: the only way to develop high-performance objects in Parrot currently is macroized-C
00:10 jnthn_ While trying to provide for decent performance along the way.
00:10 lucian allison: which i find evil
00:10 lucian i'm more interested in performance potential
00:10 allison lucian: and we are going to be desparate to demonstrate the performance of Python on Parrot compared to CPython and PyPY
00:11 lucian allison: i'm fine with it being slow
00:11 lucian if i can demo pynie and cardinal working together, i'll be satisfied
00:11 lucian Tene: ^
00:11 allison mmmm... can we try both strategies?
00:11 whiteknight over the course of gsoc, a working python compiler is probably more important than a fast one
00:11 whiteknight it will take more than 3 months to get it working right and then optimize it from top to bottom
00:11 allison that is, a set of winexed/pir objects, and a set of macroized-C dynPMCs?
00:11 Tene lucian: Me too.
00:12 whiteknight allison: in Lorito world, dynpmcs may not be in macroized C anymore
00:12 lucian allison: as a stop-gap optimisation, i guess
00:12 allison for a gsoc project, agreed, working is more important than fast
00:12 allison but, for getting any traction in the Python community, fast is critical
00:12 lucian parrot bytecode dispatch was supposed to be fast
00:13 whiteknight once we have pynie working, the same things that we need to do to optimize that will need to be done to optimize rakudo, cardinal, partcl, etc
00:13 whiteknight mostly the same things
00:13 lucian whiteknight: that's one thing i'm skeptical of
00:13 lucian it's part of why i think parrot will never be really fast
00:13 whiteknight lucian: you're skeptical of a lot of things :)
00:13 lucian whiteknight: yes :)
00:13 allison lucian: bytecode dispatch is one thing, objects are another, and PIR objects still have a lot of overhead
00:14 whiteknight lucian: Parrot is never going to be as fast as something uber-specialized like some of the modern JS VMs
00:14 lucian whiteknight: or PyPy, i'd say
00:14 whiteknight I consider PyPy to be pretty well specialized, right now at least
00:14 lucian they still have a lot of relatively low-hanging fruit
00:14 allison lucian: PyPy is fast in certain applications, not in all cases
00:15 lucian allison: but it does certain optimisations that are extremely python-specific
00:15 allison lucian: but, yes, they have lots of potential ahead
00:15 lucian which is my point
00:15 lucian parrot's jit will be relatively general
00:15 lucian it could still be quite fast (like the jvm is for mostly-static languages)
00:15 minusnine_ well, this all just got a lot more exciting. i have to go, but i'll read the irclogs later.
00:16 lucian minusnine_: bye :)
00:16 whiteknight Parrot intends to be very pluggable for exactly that reason: We will have opportunities to insert per-language specializations
00:16 minusnine_ i look forward to slinging code with you!
00:16 minusnine_ left #parrotsketch
00:16 lucian whiteknight: perhaps. i don't know what'll happen at language boundaries
00:17 jnthn_ So far as I can tell, at the moment, whatever it costs to dispatch a method (in so far as working out what to call) is swamped by the cost of actually doing the invocation of it (e.g. creating and setting up the call context, passing args, etc)
00:17 whiteknight lucian: I like to think that Parrot offers other advantages besides absolute raw performance for a single language
00:17 lucian jnthn_: right. that's totally the other way around in CPython
00:17 lucian whiteknight: of course, i wouldn't be here otherwise
00:17 TimToady the main point of 6model is, I think, to support gradual typing, which presumably means supporting *both* dynamic and static notions
00:17 lucian but i don't think we should be desperate about python perf
00:18 jnthn_ TimToady: *a* main point :)
00:18 lucian as long as it's reasonable
00:18 lucian TimToady: that's irrelevant for python
00:18 TimToady you think
00:18 jnthn_ TimToady: But yes, an important one.
00:18 whiteknight Parrot has always aimed to provide more features than any single language needs
00:18 lucian TimToady: how is it?
00:19 allison whiteknight/cotto: to loop back around to another thread in the conversation, dynpmcs won't be macroized-C in Lorito, but that's probably post gsoc?
00:19 whiteknight allison: I don't know the current lorito timeline, but I can't imagine there will be anything in place before the end of this summer
00:19 TimToady lucian: obviously, to support the bits that PythonThinks sweeps under the carpet of the runtime
00:20 whiteknight cotto is optimistic that once the spec is nailed down that implementation of the initial versions will go quickly
00:20 lucian TimToady: i'm not sure i understand
00:20 whiteknight but then there's the huge effort of rewriting our existing ops and PMCs in lorito, and that will certainly be a long phase out
00:20 allison whiteknight: me too (confident in initial versions going fast)
00:20 lucian TimToady: why would the python runtime need to use 6model at all?
00:20 TimToady a given problem has the same solution space, even if your language hides part of it from you
00:21 allison whiteknight: but, still a target for later versions of pynie, not current versions
00:21 lucian TimToady: i still don't get it. what does python hide?
00:21 whiteknight allison: yes, nothing you need to work into your current lans
00:22 allison to resummarize: it sounds like our best option for a current reboot of pynie is a pure CPython3 module that reads the CPython  AST, and dumps PIR, plus a winexed/PIR implementation of the Python core types
00:23 allison with options to depend on other core Parrot features later, as they become available
00:23 * lucian nods
00:23 whiteknight yes, I think that's the best
00:23 whiteknight the more of it you can write in python and bootstrap, the better
00:24 allison with the tempting option of writing the Python core data types in Python3, and translating them to PIR using the same method :)
00:24 lucian allison: i don't see how that'd work
00:25 lucian unless it defined a subset
00:25 lucian not even that, it'd have extra things to plug into parrot
00:25 allison because the translator itself runs in CPython, not in Parrot, so we don't use the core data types until we've already run the translator
00:25 allison but, I'd consider that a more advanced stage of bootstrapping
00:26 allison (not to be tried for gsoc)
00:26 lucian allison: sure, but in terms of what would you write those core types?
00:27 allison lucian: in terms of the core types
00:27 allison lucian: basically the same as if we'd written them directly in PIR
00:28 allison but, better to write them directly in PIR first
00:28 lucian allison: how would you use parrot's Hash from Python3?
00:28 lucian python3 translated to PIR with a compiler
00:29 allison lucian: do you mean "how would we instantiate it?" or "how would we hide the non-pythonic-features from Python3?"
00:29 lucian allison: second, i guess. how do you even reference it?
00:29 lucian dummy parrot module that the compiler knows about?
00:30 allison the generated PIR code has access to all Parrot core types, like all PIR does
00:30 allison but, you'd sure want to hide it from Python3
00:30 lucian sure, but the code it's generated from (python3) only has access to python3
00:30 allison the semantics of Parrot's Hash are wrong for Python
00:30 lucian yeah, i know
00:30 lucian but you'd still use the Hash to implement dict
00:31 allison it's a compiler, python3 doesn't understand the PIR code it generates, it just spits it out as a code string
00:31 lucian allison: but it accepts python3 code as input
00:31 lucian that input python3 code has to reference PIR things. how would it do it?
00:32 allison with some hacks in the translator
00:32 lucian allison: right
00:32 allison or dummy classes in the Python 3 code
00:32 allison one or the other
00:32 lucian also, there's a problem bootstrapping it
00:33 lucian the way i see it anyway
00:33 allison it's bootstrapping, the turtles have to end at some point
00:33 lucian you'd need two compilers
00:33 allison which brings us back to RPython
00:33 lucian one for regular python3 code, another for python3 code implementing core types
00:33 lucian allison: yes, sort of
00:33 allison let's not go there for the first implementation
00:34 allison lucian: do you have any preference between winexed and PIR?
00:34 Tene allison: "winxed"
00:34 lucian allison: for actually writing? i'd say winxed
00:34 allison lucian: or, a sense of which is the simpler starting point?
00:34 lucian i see no point in writing assembly if i don't have to
00:34 allison lucian: including the possibility of needing broader semantics for Python?
00:35 allison lucian: it seems like we can work around semantic limitations if we run into them
00:35 lucian allison: i don't really know
00:35 lucian the compiler output should likely be PIR, though
00:35 allison lucian: yes, agreed
00:35 allison lucian: generating assembly language is no trouble
00:36 allison lucian: it's a completely different problem than writing assembly language by hand
00:36 lucian allison: yes
00:36 allison lucian: winxed is likely better for getting gsoc on it too
00:37 allison (for the core types)
00:37 lucian yes. then we can move to specialised compiler + parrot mop
00:37 allison yah
00:38 lucian i'd much rather do that from the beginning
00:38 lucian higher entry cost, but potential lower cost for corner cases
00:38 allison do which from the beginning?
00:38 lucian specialised python3 compiler + parrot mop for core types
00:38 lucian not exactly possible with the state of 6model and so on
00:39 allison yeah, it's "ideal" versus "immediately possible"
00:40 allison now I'm itching to start the repository and experiment with CPython's AST :)
00:40 lucian heh
00:40 lucian me too, but i should probably concentrate on my dissertation for now ..
00:40 allison :)
00:41 lucian it's even more annoying, because that's interesting as well
00:42 allison I should go grab some dinner
00:42 allison this was really valuable
00:42 * lucian agrees
00:43 allison thanks to minusnine for starting it
00:43 lucian although the conclusion was similar to previous discussions
00:43 * lucian nods
00:44 allison on the core types side, yeah. but we know a whole lot more about the feasibility of pypy versus cpython for the parser component
00:44 allison fortuitous timing on the Python sprints
00:45 * allison afk -> dinner
00:45 lucian allison: have a good meal
00:48 lucian left #parrotsketch
00:59 cxreg joined #parrotsketch
01:09 whiteknight left #parrotsketch
01:11 cotto joined #parrotsketch
01:24 eternaleye_ is now known as eternaleye
01:41 jnthn_ left #parrotsketch
01:41 atrodo left #parrotsketch
02:15 ascent left #parrotsketch
02:38 ascent joined #parrotsketch
03:11 ShaneC left #parrotsketch
03:17 plobsing joined #parrotsketch
03:31 plobsing left #parrotsketch
04:08 ascent left #parrotsketch
04:13 ascent joined #parrotsketch
04:14 benabik left #parrotsketch
06:15 bacek left #parrotsketch
06:16 ascent left #parrotsketch
06:21 ascent joined #parrotsketch
09:59 contingencyplan left #parrotsketch
10:07 lucian joined #parrotsketch
10:30 lucian left #parrotsketch
10:40 bacek joined #parrotsketch
12:31 atrodo joined #parrotsketch
13:47 bluescreen joined #parrotsketch
14:25 bluescreen left #parrotsketch
14:36 bluescreen joined #parrotsketch
15:38 particle left #parrotsketch
15:54 lucian joined #parrotsketch
15:55 lucian left #parrotsketch
17:44 atrodo left #parrotsketch
18:13 contingencyplan joined #parrotsketch
18:16 ShaneC joined #parrotsketch
19:00 lucian joined #parrotsketch
19:02 bluescreen left #parrotsketch
19:04 lucian left #parrotsketch
22:34 whiteknight joined #parrotsketch

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