Stories
Slash Boxes
Comments
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 ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Thursday May 22, 2008
03:01 PM

Perl 6 Design Minutes for 21 May 2008

[ #36495 ]

The Perl 6 design team met by phone on 21 May 2008. Larry, Allison, Patrick, Jerry, Will, and chromatic attended.

Allison:

  • working on the exceptions migration
  • finished the last half of that
  • debugging failing tests now
  • I have eight failing tests
  • narrowed it down to three basic problems
  • had a question for Patrick on that
  • continuations taken on labels in the middle of a subroutine make very poor exception handlers
  • independent subroutines work much better
  • the problem is that setjmp/longjmp isn't stable or guaranteed to be stable in the spec

c:

  • that only surprises me if you're using a bad platform with an awful compiler

Allison:

  • longjmp isn't guaranteed to restore all of your variables properly
  • we're seeing memory corruption when we restore
  • we're ready for language testing on that branch
  • the places where this is a problem is throwing exceptions from C
  • throwing exceptions from within PIR is fine
  • it just inserts an exception handler as the next op in the runloop

c:

  • released Parrot 0.6.2 yesterday; seems fine so far
  • improved performance in Parrot yet again
  • ran out of time over the weekend to work on concurrency
  • will apply open patches and check for bugs this weekend
  • scheduled my trip to YAPC::NA, will be at the Parrot hackathon both days but not the post-conference hackathon

Jerry:

  • did some work on mod_parrot on a branch
  • rewriting the configure system to improve portability
  • some good progress there
  • added a couple of Perl 6 spec tests
  • modified a few to make them pass on Rakudo
  • talked to Moritz about a make target for just passing spectests
  • it's make spectest_regression
  • should get you noiseless, all-passing spec tests
  • they run through fudge for now, but eventually we'll take that out
  • trying to get back into Perl 6 development, but I can't keep up with Jonathan and Patrick

Patrick:

  • now you know how I felt!

Jerry:

  • I'll stick with the tests
  • GSoC starts in earnest within a couple of weeks anyway
  • want to make sure that all of the students have what they need

Larry:

  • took a side trip to Japan
  • gave my talk there on the current state of the parser
  • why and how we're making it extensible
  • continue to work on the parser to make language derivation more real
  • revamped the quoting to use real sublanguages and get all the mixins to work right
  • I Moose-ified the STD5 implementation
  • now does mixins correctly
  • now parsed double-quotes for escape sequences and properly returns a Match object
  • now working on regexes as a sublanguage
  • thinking how terminators match
  • the old recursive-descent parsing was kind of brittle
  • switched it to use the operator precedence parser
  • figured out that I could reuse the same one by supplying different term and infix expectations in the subgrammar
  • that effectively hides the parts of the regular grammar that you don't want to see
  • you don't have normal regular expressions popping out where you don't want them
  • there's no reason not to use the regular operator precedence table for that
  • don't have to worry about propagating terminators down so that they stop on double vertical bars

Patrick:

  • PGE does the same thing

Larry:

  • it looks cleaner
  • but it's untested
  • if the operator precedence parser works on regular Perl, it'll work on the real thing
  • the benefits of longest-token matching still work too
  • there are occasions where I don't want to derive a sublanguage just for a different quote terminator
  • playing with a single hard-wired stop pattern passed in from the dynamic scope
  • may need a start pattern so I can have nested brackets
  • should suffice for quoting needs without multiplying grammars for every different delimiter
  • instead of the preprocessor rewriting protoregexes, the standard grammar looks at protoregex data and rewrites it on the fly

Patrick:

  • had end of semester grading and stuff
  • that distraction is gone
  • created a new metaobject model on top of Parrot
  • makes Parrot objects act like Perl 6 objects .HOW and .WHAT methods
  • follow Perl semantics, not necessarily derived from a common base
  • gives a nice consistency to the toolset
  • PCT and PGE use that model now
  • that went quick
  • Jonathan and I are converting Rakudo to that model now
  • finding other updates in the process
  • seems to be going well
  • closing tickets, applying patches, answering questions
  • figured out an approach to solving scalars in Rakudo
  • will help with list assignment and list context
  • a new PMC type for the base class of mutables
  • we can attach properties to that
  • figured out how to clean up class relationships in PGE
  • need to refactor PGE
  • that helped me figure out how to implement protoregexes
  • that'll help us implement more of the standard grammar
  • not a complete longest token matching implementation
  • but it'll get us closer
  • need to refactor the operator precedence parser slightly
  • needs more introspection to make scalar assignment propagate context appropriately
  • not a minor refactor; PGE uses operator precedence parser to parse things
  • a fair amount of changes to PGE over the next couple of weeks
  • I don't expect any external impacts
  • our abstraction levels seem good to mitigate that
  • it's easy to change the world underneath without having to change things externally
  • no blockers at the moment, other than sleep

Will:

  • keeping an eye on the queue
  • trying to stay active on IRC
  • trying to get some people fill out CLAs and get commit bits
  • want to make sure we keep good patch submitters happy
  • some grant committee work this week, nothing particularly Perl 6-y
  • blocking on time

Allison:

  • how much do you depend on exception handlers being set as continuations within a subroutine?
  • how much would it hurt if they were separate subroutines?

Will:

  • I'd have to update a lot of code in Tcl
  • that wouldn't kill me

Patrick:

  • I like the way it works now
  • there could be reasons why that's not fully desirable
  • but it's really nice to have all of my registers in scope with labels as it is now

Allison:

  • at the moment, exceptions thrown within C require setjmp/longjmp to get to where we can insert a new opcode within Parrot's runloop
  • that's fragile
  • most exception problems now come from that
  • this is the same problem as the continuation from different runloops problem
  • longjmp doesn't know anything about the Parrot environment and doesn't restore it
  • that's the corruption problem
  • maybe the problem is how we handle Continuations

c:

  • I think the problem is with how we handle Continuations

Patrick:

  • there aren't many places where I do exception handling
  • there may be a lot of handlers, but they're mostly in generated code
  • not hand-written code
  • might not need to update many places if exception handler as label goes away
  • then the question is "How do I get to the context I had where the exception occurred?"

Allison:

  • from my perspective, an exception handler is basically a block in the HLL
  • the same way you'd use :outer with a block
  • the outer is the enclosing sub in the HLL

Patrick:

  • that's basically lexicals then
  • anything I want to preserve into the exception handler, I have to stick into a lexical

Allison:

  • yes
  • or rely on the information you insert into the exception itself
  • it can carry a payload

Patrick:

  • but we're talking about exceptions I didn't write
  • thrown from C
  • I can't put stuff into the payload there

Allison:

  • what information do you want?
  • PIR information?

Patrick:

  • and stuff in registers
  • if I create a class, there could be a "Class already exists!" exception
  • I branch around it
  • if there's an error, handle it elsewhere in the subroutine, then continue on

Jerry:

  • it's half-standard, when you write PIR
  • half of the ops return NULL
  • half of them throw exceptions

Allison:

  • is that an idiom because Parrot's exception handling doesn't work?
  • resume hasn't ever really worked so far
  • if that worked, would that help?

c:

  • that would solve some of them for me

Patrick:

  • it would for me too
  • but sometimes I want to do other things, and then resume
  • I'd need to store stuff in lexicals to have access to them

Allison:

  • the classic model is where you catch an exception, change a value, and then resume
  • that's tricky to do with separate execution for handlers

Patrick:

  • about half of my stuff is that
  • mostly default handling
  • testing to avoid the exception in the first place is a lot more work than trapping and fixing

Allison:

  • and that makes exceptions less useful, as you want to take the hit only when an exceptional condition occurs

c:

  • and there are race conditions

Patrick:

  • exception handlers as labels are useful, because you can call out to an external sub if you want

Allison:

  • we'll have to do some work on Continuations to call them from within C without breaking things horribly

Patrick:

  • before you go too far in looking at that, let me review where I use exceptions and how I use them to see what needs to change

Allison:

  • the confusion is between the HLL and C
  • they don't agree on how control flows

Larry:

  • C is wrong
  • the minute you put C and C in there, you're wrong

Allison:

  • that's what I thought when I saw them
  • I'll try to keep the ability to allow exception handlers at labels

Patrick:

  • I'll look at how I handle C from a PCT perspective

Larry:

  • C in Perl 6 allows you to go to the original scope from the exception handler
  • the stack doesn't unwind until you tell it to
  • it's not impossible... if you can find the right label to go to
  • the C itself unwinds the stack

Patrick:

  • what happens when you do C now?
  • in trunk

Allison:

  • it pushes a Continuation object onto the general stack

Patrick:

  • when the exception occurs?

Allison:

  • it pops it off the stack and invokes it
  • when you C, you push the exception back on the stack

Patrick:

  • anything that happens after you took that Continuation is still in effect when you get to that label

Allison:

  • invoking a Continuation doesn't restore your entire environment
  • only certain pieces of the context

Patrick:

  • it doesn't change register values back

Allison:

  • it's not pure
  • in the sense of no side effects

Patrick:

  • how does the new one work?

Allison:

  • it doesn't use the general stack at all
  • C adds a handler to the concurrency scheduler
  • like event handlers
  • when you invoke an exception, it searches through the concurrency scheduler's list of handlers
  • invocation hasn't changed at all
  • you'd store your exception information in the interpreter
  • then pull that into an Exception PMC
  • then throw that object
  • we've removed that interpreter structure part
  • superfluous
  • Continuation invocation hasn't changed at all

Patrick:

  • return exception returns a payload

Allison:

  • you control that

Patrick:

  • how about C and C?

Allison:

  • are they all subs?

Patrick:

  • PCT doesn't presume that the body of a C or C loop is a sub
  • not all languages require that

Allison:

  • I removed the idea of handler scope
  • the old implementation wasn't very good
  • my new idea is to store them in the context structure
  • they only exist in your own context
  • you attach those handlers to a block
  • if you throw an exception within that block, the handler for that block catches it
  • when you leave a context, the handler is no longer active

Patrick:

  • that doesn't handle C
  • have to stay in the loop
  • it skips the rest of the block
  • starts at the top again
  • C exits the block

Allison:

  • it hands control back to whatever controls the iteration?

Patrick:

  • I need the C and C opcodes to work properly

Allison:

  • the block catches it
  • the handler says "resume after everything else"
  • the ordinary control flow continues on the next iteration

Patrick:

  • I need to think about it some more
  • I could really use a way to push a new level into a lexpad
  • some optimizations there

Will:

  • Tcl has a C
  • I'm not sure how it works under the hood
  • it lets you do things with control flow

c:

  • Lisp does too (CL?)
  • let's take this to the list
  • Bob Rogers has lots of practical experience doing this in Lisp
  • good to get more feedback
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.