The Perl 6 design team met by phone on 06 May 2009. Larry, Allison,
Patrick, Nicholas, and chromatic attended.
> Larry:
- refactored my phone
- refactored various functions
-
comb
now defaults to matching single characters - a
words
method now does what comb
used to do - did some work on
pick
- looked at most of the functions in containers to see whether they out to return a
List
or a Capture
which returns an Item
- depends on whether the function would ever be used to pull a single thing out
- whether people expected it to do the right thing as an
Item
-
pick
is one of those functions - worked on the semantics of
has
- the initializer semantics; the syntax hasn't changed
- worked on the relationship between multiple
has
if you have multiple attributes - straightened out a mismatch between prefix parsing specification and implementation
- turned the term "protoobject" into "type object"
- thinking about the notion of braided languages
- Perl isn't a single language
- also a regexp language, a quoting language, a quasi-quoting language
- they hand off to each other
- they have to keep track of each other; I call that a "braid"
- how you override one language in another
- how do you handle regexp language changes from regular Perl, when you're not in the regexp language at the time?
- thinking about how to get the derivations to work correctly
- when you parse a regexp or a quote
- now instead of starting at a language like
q
, it starts at the current q
-ish language in your braid - in support of that, I implemented temporization of context variables in
gimme5
- used to temporize current braids to a lexical scope
- added a block after
try
in parsing - it uses that rather than parsing the block as the first argument of a list operator
- likewise the other statement prefix operators
- added the auxiliary
hides
trait - the
\c
notation for characters allows any radix of integer inside the list - the
\c
, \o
, and \x
notations all parse consistently now - enums are parsed more correctly
- they don't give bogus duplicate warnings
- if you declare a lexical symbol with
::
in it, assumes you're referring to a subpackage of the current lexical scope - means something different from a symbol intended to scan outward
- along with the notion of braided languages and derivability, derived languages can add more parser variables (
$?foo
) with a virtual function for lookup - avoids clobbering the core definitions
- worked on role parameters
- they're now in the role's pad, like normal signature parameters
- started playing with the
YOU_ARE_HERE
stub used to define the effective insertion location of your code into a Setting
- determining which lexical pad to dump as the
Setting
's context for use by other compilation units - did a lot of work on error messsages
- some of my
||
s suppressed panic messages - more useful error message on the null pattern (
//
) - gives a better message if you slurp your control block in the preceding expression
Patrick:
- had a lot of discussions online
- not as much coding as I like
- seem to be answering questions for others
- quite a bit of work on Rakudo internals refactoring
- that'll make it easier to switch it over to be its own HLL in Parrot
- moved things around
- made a single constant definition we can change when we move it over to its own HLL
- also moved all of the Parrot HLL mangling into its own source code files
- easy for us to manage there
- fixed some bugs
- talked with Jonathan about refactoring the P6object implementation
- used in Rakudo and PCT for Perl 6 object-like behaviors
- he's working on that refactoring now
- found and fixed a couple of bugs handling implicit slurpy positionals
- made Rakudo's standard IO handles default to UTF-8 encoding
- gives people behavior more like they expect
- working on changes to the
Array
and List
implementation - currently
List
inherits from ResizablePMCArray
- we'll change that to contain it
- that should clean up a lot of behavior
- Rakudo passed the 11,000 spectest mark as of two days ago
Allison:
- spent some time on ticket, milestone, and roadmap maintenance
- helping other people start or continue their tasks
- launched the install PDD out of draft
- it doesn't address every question, but I cleaned out all of the inaccuracies
- fits our current plan
- probably needs more expansion when we figure out the source of some of our problems building Rakudo and Partcl
- the general problem is that we've built all of our languages from the build tree, never and installed Parrot
c:
- I've been explaning Perl 6 roles on my new weblog
- lots of feedback
- still lots of explaining to do
- also been profiling Parrot and Rakudo startup
- Parrot's a lot faster now (cotto and bacek's work on vtable init helped immensely)
- Rakudo's getting faster, but it has a ways to go
- will keep working on that, but the progress has been decent with little investment
- discussed exception handling with Allison
- came up with a preliminary design to handle the interior runloop exit there
- just syntax to hide tricky semantics
Patrick:
- when dealing with exceptions, handlers, and returns for subroutines
- it'd be nice to force a return from a subroutine higher up in the caller chain
- akin to Perl 6's
leave
semantics - trying to do that without throwing an exception....
- if we do it with exceptions requires every block to have a handler
Allison:
- invoke the return continuation several levels back?
Patrick:
- is that easily doable at this point
Allison:
- we have all of the ability for that, but no syntax for it
Patrick:
- I don't necessarily need syntax for it
- the natural approach is to find the appropriate caller
- I need to do that anyway
- then ask for its
ReturnContinuation
- then invoke that with the values I want to return to its caller
c:
Patrick:
- that may exist in PIR syntax like that anyway
- if the easy invoke doesn't work, use some combination of
set_returns
Allison:
- not sure if we have in PIR right now the way to ask the caller for its return continuation
- you can do it from C
- we can add something which does that
Patrick:
- if I ask for a
Sub
's current context - I could write a method on a sub to do that
- it'll be easier and nicer when our contexts are PMCs
- as an intermediate case, that would be it
- related to that, this might be there too
- is there a way for a
Sub
to register behavior to execute just before it exits
Allison:
- are those like the
LEAVE
hooks in Perl 6? - we have a place to store them now
- we don't right now have a way of flagging a particular handler to execute at block scope exit
- would it make sense to call that an event?
Patrick:
- it might
- before saying what we do and don't have
- one piece of this is that there's still a
push_action
opcode
Allison:
- it never worked
- we're removing it
- the global stack never synchronized with continuations
- it dummied up to work, but it doesn't have the automatic stack cleanup behavior
Patrick:
- the other possibility is the presence of
ONEXIT
or LEAVE
hooks on Sub
s in Parrot
Allison:
- do you want all
Sub
s to have that - or at runtime would you want to attach a handler to that sub?
Patrick:
- it might be nice to have that at compile time
- I suspect it'll end up being an attached block
Allison:
- can we tie that cleanly with other execution pieces?
-
NEXT
and LAST
etc
Patrick:
- the biggest difference with
LEAVE
is that it's not exception-based - Larry thinks of it as natural to a block
- PCT models the rest as exceptional
Allison:
- it sounds like a handler to store in the local handler list
- mark it so that it's clearly not an exception
- we have handler flags -- exception, event, etc
- we add to the execution code for
Sub
s - as it returns or ends, it checks to see if there was a handler
- invokes it if so
Patrick:
- sounds good to me
- it's come up if you're thinking about these issues anyway
Nicholas:
- how useful is MAD that's in Perl 5 blead still?
Larry:
- I don't know
- it may turn out to be very important
- depends on how possible it is to write a decent Perl 5 parser in Perl 6
- where decent is a very peculiar definition meaning "indecent"
- this is unknown
- for interleaving Perl 5 and Perl 6 on various VMs, some VMs will use a Perl 5 compiler written in Perl 6
- that may not be a solution as nice as using the real Perl 5 parser which knows its own idiosyncracies
c:
Larry:
- that's the point
- I'd hate to have to have to hack it up again
- that was a lot of work
Nicholas:
- it seems to suffer slow bitrot
- no one seems to try to keep it up to date
- when people change the parser, they don't change it
- the question is if people still use it
Larry:
- the vision is still to have a Perl 5 to Perl 6 translator
- that's been on hold until we have a viable target to translate to
- the demand for that will re-arise at some point
- if it bitrots, it bitrots
- that doesn't bother me as much as if people felt like ripping it out
- the way to unbitrot it was roundtripping the test suite and fixing any problems
- we'd just go back to doing that again until everything was reannotated the way it needs to be
- the standard for when you know you're storing enough information is being able to reproduce it
c:
- is there a test target to handle that?
Larry:
- I used special scripts to do that
- didn't expect other people to maintain that
- it's MAD for a reason
- nobody's tried to write a Perl 5 parser in Perl 6 yet
- it's theoretically possible
Patrick:
- depending how much fidelity you need for the actual Perl 5, you can get a pretty good way
Larry:
- considering how much effort has gone into PPI, you can get a PPI-like result
- that only takes you so far though
Patrick:
- maybe a GSoC project next year would be for someone to start hacking something together with PPI
- it'd be a worthwhile project
Larry:
- we already have a Perl 5 to Perl 6 translator based on the state of MAD
chromatic's new blog
aufrank on 2009-06-16T19:46:58
c--
Where does the new weblog live? Are you talking about the Modern Perl blog?
Thanks,
/au
Re:chromatic's new blog
chromatic on 2009-06-17T00:53:38
Yes, that's the one.