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 February 25, 2009
08:05 PM

Perl 6 Design Minutes for 18 February 2009

[ #38552 ]

The Perl 6 design team met by phone on 18 February 2009. Larry, Patrick, Allison, Jerry, Nicholas, and chromatic attended.

Larry:

  • fixed STD so that if you added A::B, it added A as a subpackage
  • so as not to complain about a missing package declaration
  • can now have $! as a parameter
  • mostly working over a lot of the error messages to be friendly to Perl 5 programmers
  • if you use do/while or do/until it now complains
  • if you use if or one of the keywords as if it's a function, it tells you what the problem is without saying "I don't recognize that function name"
  • people coming from a Haskell background think they can write 1.. to get an indefinite range
  • it now tells them what they should write instead
  • fixed a bug which reported runaway strings which start and stop on the same line
  • not really a runaway
  • now it reports that only if the string crosses a newline
  • in the spec space
  • to accompany the ability to use a bare sigil in declarations as an anonymous name, now you can use a bare :: to signify an anonymous package name or type
  • allows us to have a package named is without ambiguity
  • blew away the Main package; combined it with the GLOBAL package
  • everything in the main program comes up starting in the GLOBAL namespace

Patrick:

  • oh, I'm happy!

Larry:

  • thought the distinction served no useful purpose
  • continued doing spec work combining context variables with globals
  • at least in terms of twigils
  • realized that filehandles belong to the PROCESS namespace, not the GLOBAL namespace
  • continuing on the vein of .Whatever on most normal operators builds a closure of one argument
  • made *.method do the same thing
  • even in places which are not syntactically special, we can use *.prime in a grep for example
  • equivalent to putting .prime in the curlies
  • now we have a fairly general mechanism of writing closures of a single argument
  • actually reads pretty well if you don't want the curlies
  • we could go as far as to undo the special syntax on whens and ~~ so you have to say *.foo to call a method
  • still thinking about that
  • would regularize the syntax slightly

Patrick:

  • had a little emergency over the weekend, but things are fine
  • improving Rakudo's build process to make it easier to build
  • someone who wants to build it can get a copy of the repo and pass a special option to Rakudo's Configure.pl
  • that'll download a copy of Parrot from the right revision and build it for you
  • people who want to play with Rakudo don't have to play with Parrot dependencies
  • Jonathan and I have most of the guts ready to start writing Setting code
  • we can start to write methods in Perl 6 instead of in PIR
  • we'll gradually migrate methods which make sense to rewrite in Perl 6
  • moving those over into the Setting code
  • that'll make it easier for people to hack on
  • some things will remain in PIR, but we don't know what those are yet
  • most of my plans for this week is doing more cleanups in the build process
  • rewriting Rakudo's t/harness to remove dependencies on Parrot files
  • have that mostly done
  • writing some articles discussing Rakudo's new home
  • how to get it, how to build it, and updating websites

Allison:

  • working on Parrot's install process
  • making it so that Patrick doesn't have to build and install a whole copy of Parrot to build Rakudo

Patrick:

  • we'll need that for some time

Allison:

  • trying to make it so that people who build and install packages have an easier time
  • you won't have to depend on a Parrot build directory
  • you can run against an installed Parrot

Patrick:

  • I would like to get rid of the build tree dependency

Allison:

  • the patch I have gets rid of most of the build tree dependencies
  • there are a few header files in weird locations
  • they don't get included in PMCs and dynops
  • I've fixed all of the build tools
  • all that's left is C-level stuff
  • should probably send you to the patch to experiment with
  • lots of stuff preparing for the release
  • seems to be encouraging that we've been getting more novice questions
  • seems to be an influx of interest here

c:

  • talking to Richard Blackwell about YAPC
  • Parrot and Perl 6 hackathon needs
  • working on TODO/SKIP test review for Parrot
  • also pondering bug triaging guidelines for Parrot
  • having some discussions about release policies and deprecations (though mostly Perl 5)
  • setting expectations early seems to help a lot

Nicholas:

  • what projects did you look at, or did you look at things afresh?

c:

  • Subversion's really early milestone release process was a real inspiration
  • the Linux kernel's backwards compatibility policy was also
  • not much besides that

Jerry:

  • Ubuntu's long term support is pretty nice

c:

  • I'm a little less thrilled there
  • even six months time is a long span between releases

Allison:

  • that's kind of a corporate support guideline

Patrick:

  • I like knowing that Hardy will be supported for a few years

c:

  • that's a risk for them
  • how long are they going to support KDE 3 when upstream doesn't?

Nicholas:

  • RHEL and other enterprise distributions support Perl 5.8 until 2011 or so
  • but we haven't heard anything from downstream there
  • and we only support critical security fixes there

c:

  • I put in expicit language about vendors promising long-term security fixes
  • that's your vendor's problem, not the problem of volunteers

Nicholas:

  • in Perl 5, you used to do package; with no namespace
  • removed somewhere in 5.8.x
  • was such a thing considered for Perl 6?
  • you basically banned all unqualified variables

Larry:

  • it was a hack in Perl 5
  • I want to make new mistakes

Patrick:

  • I expect to do Rakudo's next release next Wednesday
  • that's a target anyway
  • I'll be out of town this weekend
  • we'll start its regular release clock with that release
  • we'll do monthly releases
  • that exact date will vary by a few days here or there until we get the release process down

Jerry:

  • will you have a similar release structure as Parrot
  • multiple release managers?

Patrick:

  • yes
  • I don't want to be the single release manager
  • I'll probably do the first couple
  • I want at least one other person to do some by May or June
  • ideally a team
  • the Rakudo release needs to happen very quickly after the Parrot release
  • we won't be able to do this this month
  • what do we need to think about for POD in Perl 6?
  • what we have now is "DRAFT DRAFT DRAFT"

Allison:

  • can you say "We'll target this version and update if necessary?"

Patrick:

  • that's exactly what I've done so far

Larry:

  • I agree

Patrick:

  • I expect to generate or write a fair bit of POD

Larry:

  • it's amenable to mechanical translation
  • someone should write a standard parser for POD

Allison:

  • Parrot might as well stick with the standard

c:

  • are you suggesting a Parrot-based POD6 parser?

Allison:

  • if you develop a POD6 parser in Perl 6, could we compile it back down to PIR and use it?

Patrick:

  • we'd more likely target NQP
  • Rakudo expects the Perl 6 runtime available
  • it'd be nice to say that that's just a PBC, but it's also PMCs and dynops

Jerry:

  • makes me wonder how small we can make a Parrot distribution that only contains NQP as a language

c:

  • that's the Parrot 2 proposal

Jerry:

  • I meant ripping out all ops and PMCs you don't need
  • maybe no IMCC

c:

  • it's not PBC compatible though

Allison:

  • he's talking about a version of Parrot built on as few basic opcodes as possible

c:

  • no PMCs or ops written in C

Nicholas:

  • I thought the computer scientists proved that you only need one operation to make things work, sort of a compare and jump

Jerry:

  • then you have Lisp

c:

  • but you need infinite storage space

Jerry:

  • disk space is cheap, and getting cheaper

c:

  • but not infinite
  • you can climb that asymptote all you want, but it keeps getting steeper

Patrick:

  • the ultimate slippery slope argument
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.