The Perl 6 design team met by phone on 01 October 2008. Larry, Patrick, Jerry, Jesse, Nicholas, and chromatic attended.
Larry:
- busy as usual
- did some hacking and a bit of spec work
- defining how assignment operators behave when the left side is a protoobject
- took out the curly stars at the end of rules a few weeks ago
- put in the correct semantics
- calls a reduction with the current tag now
- don't need an action now
- broke macro parsing
- you can't define and parse factorial now there
- going to the University of Illinois tomorrow
- an ACM conference: Reflection/Projection
- giving a keynote on Friday night
- a workshop on Saturday
- that's more or less my standard parser talk
- my keynote is the Studies in the Ballistic Arts talk
- slightly more general interest
Jesse:
- did you say that recent changes should make it easier to parse more Perl 6 in Perl 5?
Larry:
- it should make it easier to translate more of
gimme5 with a Perl 6 parser not a custom parser
- should make it easier to parse more Perl 6 into the corresponding Perl 5
- then I can rewrite
cursor from Perl 5 into Perl 6, and backtranslate it to whatever engine
Patrick:
- not a lot of coding
- lots of helping others code
- getting a lot of things done
- fixed some Parrot issues out of the way
- chromatic fixed floating point constants
- lots of spec tests passing
- close to 800 new ones in the past week
- 20% in just one week
Jesse:
- how much more spec are they covering?
- how much is it checking addition of pairs of numbers?
Patrick:
- some broken features now work
- many of them are that Moritz and friends have found passing tests in the whole suite and included them in our suite
- some are new features
- it's a pretty good mix
- there's little addition of tests for existing features
- lots of tests for features we didn't test yet
- Stephen Weeks implemented loop control exceptions in PCT
- also for Cardinal
- that was this morning
- we're looking at those exceptions in general
- we want to handle them in a sane manner in Parrot
- otherwise, just asking design questions
- answering questions on IRC
- lots of thinking about fixing reference and value types in Rakduo
- trying to get momentum in my head to do that quickly
- will require refactoring plenty of things in the existing code
- I'll have to review a lot of Jonathan's code in the process
Jerry:
- things are going well
- have a lot more time lately for Perl 6 and Parrot
- currently looking at S11
- the documentation for exportation
- want to get namespace exporting in Rakudo
- that's another step toward writing Rakudo in Perl 6
Patrick:
- we should talk about that
- I'll tell you how to do it
- I have some pretty specific ideas
Jerry:
- submitted a grant proposal to TPF for S19
- the command-line implementation
- lots of IRC conversations
- lots of good questions
- it's hard to give Moritz enough praise for the work he's been doing on the spec tests
- it's amazing progress
c:
- haven't had much spare time
- willing to concentrate on blockers
- may be able to fix one or two crazy bugs a week
Patrick:
- we found a workaround for the weird problem we had last night
c:
- you had a lopsided exception handler
Patrick:
- I saw that
- switched the order of a few statements
- then saw the lopsided exception handler
- I'll file my example code as a bug so we can fix it
Jesse:
- I talked to Robert about how to get a prominent download link for Rakudo on perl.org
- if it's doable to get a nice target page for how to build and use Rakudo, that's easy to get up
- need a page to describe the four steps you need to get /usr/bin/perl6
Jerry:
- and maybe a link for binary distributions
- Debian for example
Jesse:
- that's not terribly common in the Perl world
- Windows maybe
- if the package downloads exist, that's a good idea
- I don't recommend delaying things for that though
Patrick:
- one problem with those distributions is that things go so quickly out of date
Jesse:
- the last release was only a couple of weeks ago
Patrick:
- the difference from week to week can be huge
- list assignment immediately starts working, for example
Nicholas:
- the idea is to shut up naysayers who say "It's not there" or "It's not easy"
- people who say "I tried it, but this didn't work" you can point to something current
Jesse:
- is there a page which describes how to download a tarball and make it go?
- versus a Subversion version?
- is there a "How to build Rakudo" page?
Patrick:
- I'll put one up on the wiki
- someone can help keep it up to date
Jesse:
- there's no reason not to have the canonical version on the wiki
- when someone complains, it can get updated
- mostly I'm just working and running a small business in a slow economy
Patrick:
- do you envision the global flag on regexs part of the regex or the caller?
Larry:
- I've thought of it as part of the thing that calls the regex
- I could see it going the other way too
- no good arguments in my head one way or the other
Patrick:
- tradtitionally I would have preferred it as the thing that calls the regex
- I like it if regexes do one match, and whatever's driving it does it next
Larry:
- if you want
.*? semantics inside the regex, you ought to use it
Patrick:
- when we parse
:g, it's an adverb to the operator, not the regex
Larry:
- inside we have submatches with
~~
- people will want adverbs on those
- we need to think about whether that's reasonable or possible
Patrick:
- I'll start with the thing that calls it
Larry:
- we can rethink that later if we need to
- we can recast it as rewritten rules of various sorts
Patrick:
- it affects the grammar engine as to what it produces and returns
- I could do it
- but I'm about to refactor PGE and want to get my strategies in place
- Mitchell wants to tag match objects with the rule that generated them
- what do you think?
Larry:
- if we can think of a reasonable name that makes sense downstream
- not everything has one
- apart from a reference to an object
- maybe that's good enough
- it's a bit problematic in a Perl 5 version of the matcher
- there really aren't code objects
Patrick:
Larry:
- I see no major conceptual problem in the Perl 6 context
- just an implementation problem
Patrick:
- how much might S05 change?
Larry:
- it has potential ramifications in terms of memory use and GC use
- other than that, it's a vague uneasy feeling
- I can't prove anything
Patrick:
- the
.keys, .values, .kv, .pairs methods
- when used as functions, are they named unaries?
Larry:
- I'd like to avoid making more named unaries than are culturally acceptable in mathematical notation
- they tend to confuse people
- not as confusing as zero-or-one, which we've tried to get rid of
- like
rand
Patrick:
- just looking for a quick answer
Larry:
- I'm prejudiced against them
Patrick:
- I'm prejudiced against named unaries as well
- if something starts to look non-Perl 5-ish, I get prejudiced
Larry:
- you force people to use parentheses
- but mathemeticians don't want to say sign of something and use parens
Patrick:
- plenty of tests in the suite test that the values of colon pairs are booleans
Larry:
- any boolean used in numeric context turns into zero or one
- if we stringify booleans, we have to turn them into zero or one as strings
- none of this null string as in Perl 5
Patrick:
- they do smart match against bool
Larry:
- preserve the type information
- make it as usefully context-dependent downstream
- the issue is how they stringify
- similar issue as to how proto-objects stringify
- you want to know whether you want to use them as their name or their value
- we really don't make that distinction right now
- except
.perl really wants to know the name of things
- if stringify
Object, does it print Object or the null string?
- if it's our new
undef, it should print the null string
- when you print values of things, it's not useful to print a null string where they were expecting a value
- which is why I wanted to distinguish between stringification and printification
- it's probably too subtle of a distinction
- if you use a protoobject and stringify it, it returns null
- but by default it should produce a warning
- the warning presumably says what the name of the protoobject was
Patrick:
- it might be too subtle or wrong a distinction to be useful
- a scalar initialized to a protoobject effectively holds a reference to the object
- when you stringify the reference, you want that to be the null string
- if you print the object, you don't have a reference
- you're sending the protoobject itself
- I see all sorts of nasty flags floating around that
- that distinction will be there from the Parrot side
- whether it's there conceptually is another question
Larry:
- in general, if I don't answer immediately it's because I'm scratching my head
