The Perl 6 design team met by phone on 03 March 2010. Larry, Allison, Patrick, Jerry, Will, and chromatic attended.
Larry:
- noted how lastcall allows nextsame control of nested dispatchers
- reserved the final paren-based shape declaration syntax without committing to it meaning anything
- clarified that
Nil itself is defined but likes to produce undefined values when indexed
- added some clarifications of how the series operator deals with type information
- clarified that
Pair.ACCEPTS uses "so" and "not" semantics so :s returns True or False
- removed the
1/2 and +2-3i literal forms, now rely on angle forms <1/2> and <+2-3i> for literals, and the bare forms now rely on constant folding rather than a fragile special syntax
- in STD, made undeclared variables more fatal
- STD now tries to be helpful if the user makes the typical P5-ish variant-sigil mistake on arrays and hashes
- also improved error message on the
-{}> kind of mistake that P5 programmers will make
my $a, $b now gives better message- STD now reserves the
() shape syntax per current spec
- fixed regression on indirect method knowing that method name is not bound early
- moved unexpected-
!! panic from infixstoppers to infix:<!!> for better extensibility
- so a user's infix definition isn't ignored if it starts with
!!
- you can define user operators starting with that, and it only complains for the right reasons now
- STD now gives an accurate message when a prefix is missing its term
- removed deprecated rational and complex literal forms from STD
- much preliminary work for moving operator defs to CORE.setting, not yet checked in
- only blocker is not being in Copenhagen
Patrick:
- Jonathan, Carl, Moritz, and Martin will be there
- I proposed a panel discussion instead of my talk on Tuesday afternoon at 3 pm
- I'll be online then
- can't make it due to sudden personal reasons
- will be online quite a bit the next few days though
- can participate in the hackathon remotely
- worked mostly on helping other people get their tasks done
- updated the parser to handle more operator conditions
- working toward enabling user-defined operators
- quite a few new people submitted patches
- several were non-trivial
- one patch put grammars, regexes, and tokens back in Rakudo
- that's not trivial and it worked pretty well
- I'm reviewing patches and making comments
- lots of good progress
- expect lots more during the hackathon
Allison:
- going to work on code stuff this weekend instead of traveling
- had a very productive trip
- glad to be home to get work done
- working on the PCC branch this week
- should be, fingers crossed, small and easy to get done
- want to avoid creature feeping
- get the re-ordering through and move on
Jerry:
- having trouble building Rakudo on Windows
- have time to debug with people online
- this is preventing me from talking to Patrick about and working on S19
Patrick:
- we can work on that tomorrow
Will:
- saw that problem on p6c as well
- fixed a Parrot bug for Patrick related to STRING indices
- we have some speed fixes on top of that
- still working on the build cleanup
- hope to merge to trunk in the next two or three days
c:
- haven't had and won't have much time
- fixed a few bugs
- working on helping other people get stuff done
Jerry:
- is there a hackathon or meeting time available after OSCON?
Allison:
- recommend the weekend after
Patrick:
- there'd have to be a hackathon for me to get TPF sponsorship
Jerry:
- the pace of spec changes has picked up
- any ideas what's driving that?
- is it different from before?
- was the end-of-year lull the same as before?
Larry:
- everyone did take a break over Christmas
- most of the changes are still simplifications
- or responses to implementation issues
- dealing with inconsistencies
Patrick:
- a lot of implementation issues have come up over the past three weeks
Larry:
- ng has flushed out a lot of design issues
Jerry:
Patrick:
- that's great for Larry, but I have a deadline!
Allison:
- remember, it's a stake in the ground
- "This is a release of Perl 6 you can use NOW!"
Patrick:
- we're driving the spec with regard to lists and arrays
Larry:
- they essentially have the same structure
- they need separate typology
- you need to know whether to clone an iterator
- that's the only reason you have to know
Patrick:
- did you see my comment about binding being the distinguishing feature?
Larry:
- I think about that in inside out terms
- not sure I can put that in words yet
- had a conversation with Solomon about the FP view of iterators and arrays
- that's some of my thinking
- do we promise to hold a pointer fixed, or go on to the next thing?
- whether that thing is persistent is mostly the bailiwick of the GC, from the standpoint of the language
Patrick:
- I wasn't sure how that applied to my specific context
- maybe I should work up a description of words or implementation
- some lists I want to keep around reified elements
- some lists I don't
- the distinction is whether it's bound to any variable
Larry:
- may depend on what it's bound to
- we might make the keeparound promise only for binding to
@
Patrick:
- I came up with binding to
$ examples
- we can get laziness but eat up a ton of memory
- if we throw things away when iterating, we get more things wrong
Larry:
- it's a matter of tracking
- are we bound to something that tells the GC to keep the rest of the list around?
- that's the FP view
Patrick:
- that's not just a GC view
- it's how people refer to them
- my GC is taken care of by my virtual machine anyway
- it's about reachability from the HLL
- or did you see it disappear
Larry:
- that's whether you have a reference to it
Patrick:
- how do you know whether to keep a reference to it?
- I've produced this element
- can I send it back to the caller
- or do I need to keep it around so something else can get to it
- if the iterator itself is bound, you keep the reference
- if it's not bound, you can return it but not keep the reference around
- I'll write up my thoughts
Jerry:
- will these changes settle down after Rakudo *?
- are they a precursor to that release?
- will they continue afterward?
- will Rakudo * go stale?
- that's a tough one to answer
Patrick:
- I can't guarantee stability at this point
- we want a useful release
- we'd like not to have any deprecations after that point
- given how implementations and applications drive implementations
- Rakudo * exists to encourage people to develop applications
- we've never made that stability an explicit goal for Rakudo *
- we'll probably institute deprecation cycles when it comes out
- we don't want to change the world out from under people
- it doesn't represent a spec freeze
- thinking of a separate distribution release from the compiler release
- a three month stability cycle of releases for Rakudo *
- a different point of view
- any distribution release doesn't have to be tied to the newest compiler release
- I see Rakudo * as a series of releases, not a single release
