Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Wednesday June 04, 2008
07:23 PM

Perl 6 Design Minutes for 28 May 2008

[ #36589 ]

The Perl 6 design team met by phone on 28 May 2008. Larry, Allison, Patrick, Jerry, and chromatic attended.

Larry:

  • mostly off for this long weekend elsewhere
  • continuing to work on quoting roles
  • they need generic support to mix in roles with parameterized strings as starter and stopper sequences
  • that's an interesting problem, when mapped into Perl 5
  • no support for generic roles or parameterized types yet
  • I'll probably just do an eval

Allison:

  • reworked continuations in Parrot, based on our discussion last week
  • I have very high regard for the value of reading through the commit logs
  • found the source of the problem that way
  • someone committed the problem about a year and a half ago
  • now continuations work the way they should work
  • we now don't try to make CPS respect the dynamic environment stack
  • it's largely unused now that we don't store exceptions there anymore
  • tracking down one last bug
  • I can duplicate it
  • it's an exception thrown, caught, and resumed from an :onload subroutine
  • looks like they get executed differently from regular execution
  • first draft of the Bylaws and Articles of Incorporation for the Parrot Foundation
  • hired a lawyer in Washington state for incorporation there

Patrick:

  • added quite a few things in the Rakudo implementation
  • added a new metamodel that looks like the Perl 6 metamodel
  • with Jonathan's and Jerry's and Moritz's help, we converted the compiler tools to that model
  • cleaned up some of the inheritance hierarchy in Rakudo
  • builtin types report correct methods and types
  • a Parrot Integer reports itself as an Int in Rakudo, down to the metaobject information
  • fixed pair handling, especially for calling functions
  • people are testing those in great detail now
  • now it's obvious that Rakudo's and Parrot's and Perl 6's argument handling there somewhat disagree
  • doing some PGE refactoring
  • primarily fixing up its class hierarchy; looks pretty easy
  • may move Rakudo's grammar to use protoregexes
  • might help get the metaoperators working -- French brackets, for example
  • if we don't get this soon, people might submit patches doing things the wrong way (multiplying new operators for various combinations)

Jerry:

  • Google Summer of Code started this week
  • the aggregated feed of Perl GSoC 2008 student and mentor blogs is available
  • the students will report weekly status at the #parrotsketch meeting
  • the students and mentors will report at #perl6-soc on irc.freenode.net on Wednesdays at 18:30 UTC
  • all of the students seem to be on track now
  • made some spectest changes
  • made some changes to rakudo List methods, applied some patches
  • made some Rakudo test changes, should make test management easier and allowing us to create private and shared lists of tests we want to run
  • should make it simple for rakudo developers to specify a subset of test files, making focused development and focused testing easier

c:

  • not a lot of energy for hacking for some reason
  • applied a few patches
  • cleaned up a few tickets
  • talked with Andrew quite a bit yesterday about GC plans
  • he has some good ideas, including a clever marking scheme for which I have high hopes
  • mostly on the right track
  • will write up some guidelines on profiling and optimizing
  • have one idea to optimize keyed object attribute access
  • otherwise really need to work on the PIR profiler

Richard:

  • trying to plan a legitimate way to ascertain Perl 6 grants, given the donation from Ian Hague
  • planning a process around that
  • thinking about YAPC::NA and a grant process BOF

Allison:

  • Patrick mentioned argument passing in his report
  • we don't quite understand how it needs to work in Perl 6
  • Parrot will support whatever Perl 6 needs, though it may not necessarily be the default
  • one goal of argument passing is to make it lazy
  • you don't have to parse the whole list to start pulling out parameters
  • required parameter positionals are clear
  • required positional parameters are clear
  • you can pass in a required positional parameter as either a positional or named argument
  • Parrot maps the positional arguments to positional parameters
  • when it runs out of positional arguments, it starts checking named arguments

Patrick:

  • that's not really what Parrot does
  • Parrot fills positional parameters with positional arguments
  • then it fills in named parameters with positional arguments

Larry:

  • what do you mean when you say "named parameter"?

Allison:

  • pairs

Patrick:

  • all parameters are named in Perl 6
  • they can be filled by a named argument
  • Parrot has parameters that you can fill only by position
  • then there are parameters that you can fill by position or name
  • but Parrot fills them opposite from how Perl 6 would expect; it chooses the positional argument over the named one.

Allison:

  • I thought you needed a way to skip over a named parameter in a list
  • and then fill in its value from the named argument list
  • or scan the entire named argument list first, and then fill in positional parameters
  • it sounds like this is different

Larry:

  • the compiler should recognize arguments intended as named parameters
  • it can set up a data structure for efficient access
  • the other constraint is that any argument can depend on the value of a previous argument in the list
  • you have to bind them in the order of declaration
  • you go down the list
  • for each of them, you look up in the named argument list
  • to see if it's bound by a name
  • if not, you take the next one from the positional list

Patrick:

  • that can be lazy

Larry:

  • yes
  • that's the abstract view from the Perl 6 end
  • one reason we invented prototypes is so that the compiler can know that the first n arguments are positional
  • map any named arguments into positional without having to do the lookup
  • that's primarily a sop to efficiency
  • for a very small number of named arguments, brute force is probably faster

Allison:

  • do you never have any parameters which are strictly only positional?

Larry:

  • there's no way to write that
  • other than writing a bare sigil in the declaration
  • you're not giving it a name
  • but you can't access it, because it needs a name

Allison:

  • sounds like we want three different flags in Parrot
  • one for a purely-positional argument

Larry:

  • the optimizer might use that, if it sees a prototype

Allison:

  • we keep the :named flag
  • for named parameters

Patrick:

  • named-only

Allison:

  • we don't really have that
  • we have named that acts like positional

Patrick:

  • we have named that prefers positional, and then throws an exception if a matching named argument is also supplied

Allison:

  • might have four flags then
  • one that's either named or positional
  • maybe one that gives priority to the positional
  • not sure that's useful

Patrick:

  • I couldn't come up with a case where that's useful

Larry:

  • some languages want that

Patrick:

  • you can almost simulate that with slurpies in your code
  • or sticking in dummy arguments

Allison:

  • could come in useful if you have optional parameters
  • you don't have to pass anything at all

Patrick:

  • I proposed what you described as numbers 1, 2, and 4
  • the existing :named flag is named-only
  • the :positional flag is a named parameter that accepts positional arguments

Allison:

  • I'm trying to get down the ideas
  • I probably wouldn't use :positional for that
  • important to get the categories right

Patrick:

  • I couldn't figure out a case where you have a named parameter that prefers the positional over the name

Allison:

  • make it a positional and don't worry about it
  • if you make it positional, you don't have to scan the argument list

c:

  • look at Python's default parameter handling
  • I think it may follow the one case you couldn't figure out
  • not entirely sure

Patrick:

  • is the answer that Parrot's underlying model will likely change to support what Perl 6 needs?

Allison:

  • yes
  • exact details yet to be determined
  • as soon as possible so that you can use it

Patrick:

  • it's been the subject of at least five or six RT tickets in the Rakudo queue
  • they look like different problems, but they call come down to the same problem
  • it's becoming a pain point
  • I'm willing to implement it
  • there are probably three or four related tickets in the Parrot queue

Larry:

  • there was a question about writing Pairs various ways as arguments
  • are they intended to be named arguments or pairs?
  • how do you write the prototype for list, by the way?

Patrick:

  • I suggested putting colons in front of it

Larry:

  • but :a is always a valid term

Patrick:

  • you can always look ahead for a fat arrow

Larry:

  • I'd almost rather write :> for that
  • originally we always used the fat arrow
  • then we put in the colons
  • we wanted to use the fat arrow for arguments
  • people seem to be used to the colon for named arguments, not the fat arrow
  • maybe we should just bite the bullet
  • you need the name as the identifier
  • you don't need the general pair form
  • the fat arrow makes a Pair not intended for a named argument, unless you do processing on it
  • that'd be a simplification
  • you can tell by just looking at it
  • one is a named argument
  • the other is just a positional parameter

Jerry:

  • is there a method on a Pair that allows it to be passed as a named parameter?

Patrick:

  • prefix vertical bar?
  • S06 has options for making a Pair a named argument
  • or a hash as a list of named arguments

Larry:

  • we're trying to guess it based on the context of the argument list
  • if you pass the list to a function call, it assumes you want named arguments
  • otherwise you don't
  • that might be guessing too far
  • the list function might want to parse more like parens
  • but it behaves like a function
  • you don't want to pass those as named arguments
  • how do you tell the compiler that it's special
  • maybe you want to make it a macro, but that's kind of weird
  • maybe it's time to look at the cultural issue of how people want to write named arguments
  • maybe we can simplify that

Patrick:

  • there's a similar issue with the hash constructor
  • you can kinda get away with it, because order is less important
  • but it still exists
  • it'd be interesting to look at the existing tests and Synopses to see the results
  • there is some historical baggage toward using the fat arrow

Larry:

  • the guy who wrote that Synopsis was familiar with Ada's fat arrow for named arguments

c:

  • is there some sort of prototype declarator that says "It was an ordered list in the source code, and that's what I want!"

Larry:

  • macros are a lot like prototypes

Patrick:

  • Rakudo for now will treat them as special in the way that Pugs does
  • it'll treat list as a macro
  • do something special, it's not a normal argument list
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.