14 Mar 2010 chromatic   » (Master)

Perl 6 Design Minutes for 03 March 2010

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:

  • that's great!

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

Syndicated 2010-03-13 23:19:22 from pudge

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!