Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autrijus (1505)

  (email not shown publicly)

Journal of autrijus (1505)

Sunday October 30, 2005
07:48 PM

Day 240: Second day at Liz's - ObjSpace, S17

[ #27375 ]

Yesterday and this morning was a lot of fun, and also very productive.

I had a SubEthaEdit+Skype session with Stevan; we worked out a sketch of the Object Space and primitive operations that supports them. Back when the focus at 6.2.x was about flow control semantics, I designed PIL with Chip and Leo to simplify the possible semantics Perl 6 can take. Now for 6.28.x, the ObjSpace and PrimOps are the logical counterpart for the OO part of the language. We learned whatever we can from Python's PyPy and Ruby's YARV (cf. Online Compiler), as the goal is identical to theirs -- have a shared minimal interface that all runtimes ought to provide, to support a consistent, fast and portable metamodel on top of it.

I also worked with Liz in two design sessions, which produced some rough notes of S17: Concurrency. Many of Liz's Threads::* modules on CPAN are workarounds for Perl 5's principle of most surprise ithread model, and we spent much time making sure that those won't happen under Perl 6 semantics.

Aside from that, we played with the idea of is atomic, is critical and is throttled traits on Code objects, and they seem to capture many key abstractions found in everyday concurrency programs. The idea of providing an unified interface to multiple concurrency models -- lightweight multiplex, OS threads, and process forks -- is also alluring, so we toyed with more bizzare ideas like having $thread.detach promote the thread into a process so it can survive its parent's demise.

The feedback to both texts were so far very positive, although we really need to elaborate the text more. A new set of Visiolization diagrams won't hurt either, as it's about time to update the Cafepress merchandise designs.

Apart from Liz's amazing sense of "Right Thing"ness, Wendy has also been helpful during the design process; not suffering from overexposure to perl5 workarounds and perl6 mindset, she provides the much needed real-time usability feedback. I think I'll need to do a Type System design session with her soon, as a sanity-check for the "incremental staticness" idea of Perl6's -- it is rare that I meet someone with a higher internal clock speed and raw mental capacity compared to mine. :)

Last night eric256 extended the test matrix concept with a wonderfully informative Test Catalog that visualizes the link between tests, synopses, and smoke results.

Also, reading PickAxe and PyPy documentations makes me rethink if Perl 6 is really dynamic enough. For example, would defining &postcircumfix:<( )> for Hash classes do what __apply__ does for Python, namely having arbitrary hash serve as closures? Definitely p6l stuff, although I'll probably run those random thoughts off #perl6 before posting them.

Today I'm going to focus on coding up the lower layers of the object space, and see how much bootstrapping I can do with those bare primitives. It should be fun. Wish me luck!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Looking at S17, it appears that the concurrency model is basically MIMD. Its not immediately obvious how we'll be expressing data parallism for a SIMD or stream-based approach. With multicore and GPGPU becoming more common, we should try to ensure we can exploit these harware resources properly


        * []
        * []
    • Yeah, in S17 so far we only deal with explicit concurrency in MIMD mode. Perl 6 is going to have SIMD in forms of pipe operators, streams, hyperops and junctions, and those will be covered in S17 as well in the days to come. Thanks for the reminder!
    • Multicore is much more likely to be MIMD. The SIMD road seems to have run out some time ago, except for narrow media apps -- which has never been Perl's focus. I think it would be wise to keep Perl Perl, instead of trying to make it an all-singing all-dancing everything language. (Also cf Guy Steele, "Growing a Language".) It you want to do graphics, try Cg. Perl should be able to *talk* to Cg, not *be* it. IMNSHO.