Perl 6 Design Minutes for 06 June 2009

brian_d_foy on 2009-06-21T14:22:00

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:

  • makes sense to me

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 Subs in Parrot

Allison:

  • do you want all Subs 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 Subs
  • 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:

  • sometimes it does

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.