Perl 6 Design Minutes for 14 January 2009

chromatic on 2009-01-24T02:21:50

The Perl 6 design team met by phone on 14 January 2009. Larry, Allison, Patrick, Will, Jerry, Jesse, Richard, and Nicholas attended.

Allison:

  • spent the week working on pumpking stuff again
  • merged in several branches that I and others had been working on
  • did a lot of patch review
  • planning on doing the migration to parrot.org today
  • I'd said today because we had three days where we could figure it out; what works, and what doesn't, and delay it if necessary

Larry:

  • been doing spec work, and answering questions
  • things are hectic at work right now, so I don't have a lot of time for my true vocation
  • keeping my nose above water on the mailing lists and IRC channels
  • removed the old .contains method, that was standing in for the .exists modifier on hash lookups in a hash.
  • mostly answering questions and hoping that someone else will clarify the specs for me, when I answer questions about functions and pod.
  • trying to use my spec writing time for clarifying things that other people can't do themselves
  • I have trips planned in April

Patrick:

  • worked on getting the branch merged in that refactored variable handling in Rakudo
  • got it done on Friday. It worked out well.
  • ... though not for people who were relying on misfeatures of Rakudo
  • I've been helping people by pointing out ways to fix it
  • it's a stronger basis from which to continue
  • passing 60 more tests than this time last week. 6233 now passing.
  • we lost 30 when we merged the branch, but gained 90 back, so a net plus for the week
  • I've closed a bunch of tickets, or put a note on that we can close when we have a test
  • done over over 2 dozen. Still more that could be closed like that.
  • it just takes time to find them. It feels good closing tickets that way.
  • I've also been helping others
  • I was going to read PGE refactors, but now figuring out what to do with Rakudo repository is a higher priority

Allison:

  • it doesn't matter if Rakudo's repository moves, just that it's not in the same repository as Parrot.

Patrick:

  • I'd rather not move it and then move it straight back.
  • there have also been some discussions about moving Rakudo to git
  • I don't want to go to the community and say "Oh, this week it's here" and then the next week "Oh this week's it here", and have the documentation on where to get Rakudo be constantly out of date

Allison:

  • let's get you cc'd on the list discussion with the admins

Patrick:

  • we will now be figuring out a Rakudo plan for this so that we can notify the Rakudo community about the changes coming up

Will:

  • I have one task assigned for Parrot this week -- rip out all the deprecated items. There are about half a dozen left; a depressing number.
  • trying to get volunteers to look through and remove what is just a hack and slash

Nicholas:

  • nothing to report

Richard:

  • I had dropped out of the calls about mid way last year because I didn't feel that I had anything to contribute
  • before I dropped out around June 2008, we did a huge amount of TPF work on how it would improve things until I had things to say
  • then I backed off, at least partly because in July 2008 my wife had a baby
  • in the past month or so, I'm coming back on the radar
  • we have a 5.10.1 release grant going on right now
  • Dave working on it, Nick the grant manager

Nicholas:

  • I watch him commit things. I don't know more more detail than that, as I've not communicated with him recently.

Richard:

  • even an revised expected release date would be good
  • when I was talking with him setting it up it was "late Jan, early Feb"
  • would be good to know if there is updated information
  • Also Hague grants. A lot of good things are happening about that.
  • I took a trip last month to New York to see Ian, to say thanks, and give him an update. It was an excellent meeting. He is happy with the progress going on, feels respected as a donor, and is happy with the amount and level of communication.
  • I'm looking into the legal details of splitting apart what is Parrot and Rakudo. Drawing up the assignment agreement with Roberta (the TPF lawyer)
  • TPF got a nice donation from booking.com ($50,000) booking.com asked TPF to be vocal. Tell the world.
  • they did not put a specific requirement on the donation. They said "we hope to support Perl 5.10 with this", but not the level of surety on it that I had with Ian on his donation.
  • I'm sure that some 5.10 support will come out of that, but after that we have a general donation to work with. Could well be part of the grants through the grants committee. There is a growing desire for funding there. Even a couple of quarters there would not exhaust it, so we will figure out other good ideas for what to do with it.

Jesse:

  • as mentioned last week, it's time for me to step back as project manager type person. Do we want a replacement project manager, or is it more a community organiser type person?

Patrick:

  • all I did was write code last week, so I didn't have time to think

Jesse:

  • we can't be having that!

Allison:

  • I think we're okay without a project manager

Jesse:

  • as long as everyone is okay with that, I'm happy not to foist someone else upon you
  • I will update the world on my blog next week. It's likely to get flameage just because it contains the term "Perl 6".

Allison:

  • "Oh no! Perl 6 is dead. It doesn't have a project manager!"

Jesse:

  • I wonder if I can get to Reddit number one on that

Richard:

  • maybe "The Perl 6 implementation efforts are so strong right now they're basically self managing to good effect."

Jesse:

  • I might pop by the call in the future to see how you are

Larry:

  • it would feel much better if you went out with a major rant

Richard:

  • it is traditional

Jesse:

  • it should be "career limiting"

Patrick:

  • rant that the implementations are doing so well without your input

Allison:

  • and "I'm just not useful any more"

Patrick:

  • and rant how you've tried to kill it but it's [just too strong to die]

Jesse:

  • I've enjoyed this. It's been fun and interesting, and I hope it's been helpful. At times it's been maddening, but that's true of any project.

Allison:

  • thanks for everything that you have done

Jesse:

  • thank you for actually making it happen

Missing a discussion on .trim and gilding the lily.

Nicholas:

  • if I wanted PHP I know where to find it

Patrick:

  • wasn't aware that .trim is not a Perl 5 built in

Larry:

  • PHP has 3000+ functions, so we have a way to go yet
  • seeking to strike the right balance

Larry:

  • my question for the day "To what extent do unary hyperoperators descend into containers?" I think that they do, to some degree.
  • also the exact definition of what .perl means.
  • been doing a lot of thinking on that

Patrick:

  • that's a good question to be thinking about, from a Rakudo implementor's position

Larry:

  • that's why I might appear to be ignoring mailing lists

Patrick:

  • can I .perl a sub?

Larry:

  • you won't get the exact the same object back

Patrick:

  • but a representation that compiles to the same sub?

Larry:

  • I think it would be good if we could
  • but at some point a lot of businesses are going to say "Oh, you just made it very easy to reverse engineer my sacred code".
  • I don't think we can guarantee it, but whether it's strongly encouraged, but turn offable, or similar
  • at least the types of code that are idempotent, or otherwise stateless such that they can be easily reconstituted
  • in some ways we already have to be able to do that to save the state of the current language, as we have to save the current grammar and all the methods on it, to do prelude snapshots, or do an eval, without having to rebuild all from scratch
  • I don't know where the balance point on that is

Patrick:

  • sounds good. Aiming at the point I'm thinking of.

Larry:

  • need to think about it
  • do what's reasonable. not do doing something that will set the whole project back a whole year

Patrick:

  • I mailed the list about pairs. Didn't spot a reply.
  • if I iterate over a list of pairs, are the values of those pairs...?

Larry:

  • those are references back to the original
  • likewise pairs coming out of a hash should be references

Patrick:

  • by "References" you meant the values, as the keys are immutable?

Larry:

  • yes

Will:

  • Tcl question
  • for Parrot, I was going to have an attribute to save the high level source. It was going to return the text of the sub and let the user recompile it
  • this is sane?

Patrick:

  • I had that as a fallback, but wasn't what I really wanted to do

Larry:

  • it's a good degenerate solution as a minimal solution that can serve as a backstop

Patrick:

  • but that would mean that my PBC files would have the entire source code in them
  • hence my question about .perl and subs was "Do we have to do that?"

Will:

  • there's another language out there that needs to do that
  • we could share infrastructure

Larry:

  • you run into the Deparse problem
  • what you see is after the optimiser got at the code
  • it might be what you want, but it's not the original source

Jerry:

  • is it possible that the spec could say that? The default is a sane default?

Patrick:

  • you're forgetting that one of the Perl 6 mottoes is that it exists to torture implementation on behalf of the users

Larry:

  • not so much that it never happens

Patrick:

  • who defines that? I might have quit back in 2004.

Larry:

  • with a rant preferably. :-)

Jerry:

  • I've finished most of the technical details of S19. It needs a re-write. It doesn't read well.
  • as far as a working copy goes (from my perspective, as the implementor) it's in a good place
  • there may be some ambiguities, but I've moved onto the implementation
  • next deliverable is a set of spec tests
  • to implement them properly I'm building a test harness, so I'm coding before I can write the tests
  • eager parsing, eager meaning .*?, as opposed to greedy, which would be .* behavior
  • no one likes the terminology "eager"
  • pulled it from S19
  • didn't want to define something as non-greedy
  • found "eager" in S5.

Larry:

  • especially as in the rest of the language "eager" means "greedy"
  • "frugal"?
  • "parsimonious"?

Patrick:

  • that was the term Mastering Regular Expressions uses
  • lazy would be bad also
  • yes, it's called Lazy

Larry:

  • probably okay. Eager : Lazy :: Greedy : Parsimonious.
  • that is how the rest of the language treats lists. "Eager" vs "Lazy".

Patrick:

  • in the context of regular expressions, we'd call that ? qualifier lazy
  • the association doesn't immediately come to me

Larry:

  • it can be implemented with lazy lists. That's how Cursor.pm works.

Jerry:

  • will take a stab at changing POD

Patrick:

  • I'm going to be in S5, so I could

Larry:

  • if Jeff Friedl uses that term too, that's good

Jerry:

  • noticed that Larry weighed in on some issue relating to preludes that I'd mentioned in S19, so it looks like that part has been approved

Larry:

  • well, I suggested it in the first place.
  • I don't know if it makes *sense*. :-)
  • maybe an alternate prelude doesn't make sense
  • I don't think of preludes as actually preludes -- instead they're the surrounding lexical scope

Patrick:

  • really we're waiting on the implementation so that we can see how it works in practice

Larry:

  • I'm thinking of the same way an eval works
  • the outer language is serving as a prelude for that eval
  • it's the same thing, except that the current language can be frozen into the file, and then you're effectively starting up again from there

Patrick:

  • it's layers, all the way down

Larry:

  • well, all the way up

Patrick:

  • the core compiler does an eval of the prelude, which brings a bunch of things into scope, which then does an eval of your code

Larry:

  • it's more the parse of the eval. We use this to implement -n and -p
  • it's not eval in the sense of recompiling each time through the loop.
  • it's that eval does a sub-parse. That's what needs to be generalised
  • Make good use of the ability to wrap compilations in one or more outer contexts. Whether we call it, prelude, or outer-lude
  • what's the opposite of an interlude?

Jerry:

  • environment variables also
  • I considered a switch which let you set an environment variable
  • this would let you do it on the same line for shells that don't provide such behavior

Larry:

  • rn had one of those

Jerry:

  • same as adding it in the prelude

Larry:

  • except that environment variables are scoped dynamically
  • another question about environment variables, which are essentially global
  • can a dynamic scope override them?
  • how easily within perl 6 code, just for that dynamic scope
  • we speculated about connections between contextual variables and environment variables, or the globals

Jerry:

  • I was under the impression that something was decided, and then changed

Larry:

  • we can give that appearance :-)

Jesse:

  • thank you everyone for the last few years. Enjoy your call next week.