Perl 6 Design Minutes for 21 May 2008

brian_d_foy on 2008-05-24T11:06:00

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

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

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

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?

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

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

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