The Perl 6 design team met by phone on 03 September 2008. Larry, Allison, Patrick, Jerry, Jesse, Nicholas, and chromatic attended.
Larry:
- I was at the Lightweight Languages Conference in Tokyo last week
- about a thousand people there
- a large Ruby presence, as well as some of the other "scripting" languages
- gave another variant on my talk
- seemed well-received
- mostly just vacationing and touring around otherwise
- did some work getting STD and the test suite to agree with each other
- now have symbol table checking in STD
- a global scale, not lexical
- can tell when you call an undefined function
- found surprisingly few difficulties with the existing parsing
- that makes me happy
- hanging out on IRC and email, doing a little bit of spec work
- the standard parser can parse itself in under 30 seconds
- I have other ideas to make it faster
- not sure I want to implement them yet
- it might adversely impact other work with installing a real LTM
- they remain ideas for the moment
Patrick:
- most of you saw the announcement about Paula
- we celebrated last Friday
- mostly answering questions and debugging problems on Rakudo
- expect to be back full-time on hacking tomorrow
- Jonathan's out on vacation this week
- Moritz and Carl and other people have been continuing to make progress
- I've been responding to them
- not a lot has happened beyond testing improvement
- the primary coders are on vacation or busy with other things
Allison:
- another nice quiet and productive week
- we have a new, much cleaner dispatch route in Parrot
- it uses signature objects, which are like Perl 6's Captures
- everything you need to invoke a sub is all in one place now, not spread out over lots of calls and varargs and unpacking varargs and...
c:
- you realize that code has always been haunted, right?
Allison:
- I'm ripping out some of the old code, but some of it will stick around
- we can make another branch to clean it up
- the branch has some problems in TGE
- I probably haven't caught all old dispatch instances yet
- we're ready to launch the new Parrot website
- doing some work on that
- almost ready to launch the new Parrot mailing lists too
- just need to ask Ask or Robert for subscriber lists
c:
- started a couple of arguments online
- need to work on the "How to Help the Patchmonster" document
- worked on vtable cleanup in Parrot, had MMD problems, may have to wait a bit
- otherwise applying patches
- should have more time in the next couple of weeks
Nicholas:
- I love parallel tests in blead, and I'm missing them in 5.10
Jesse:
- I've been working and traveling for the past two weeks
- also been trying to goad chromatic to post suggestions to p5p
Allison:
- which seems to have worked
Jesse:
- is there anything I can do to help you?
Patrick:
- I just need time and energy
- so maybe saying "Get back to work!"
Jesse:
Jerry:
- haven't had any commits recently
- helping lots of people with implementation questions
- talked to Evan Phoenix about the Rubinius VM
- he had some questions about Parrot's architecture and design decisions
- good chat
- we started talking about bytecode and AST translation
- they're lacking a well-defined AST now
- just S-expressions
- we'll chat more frequently
- there are only so many people interested in implementing VMs
- we should all get together
- still talking to Microsoft
- they want to know what an ideal testing environment would look like in their labs
- I need to figure that out
- it could be good for Perl 6, Parrot, and Perl 5
Patrick:
- is that worth taking to the mailing list?
- Allison mentioned something about old MMD and new MMD
- what's the difference from a PIR perspective?
Allison:
Patrick:
- there should be no difference in PGE and TGE then
Allison:
- there are a few places internally which are C code
- if there's a direct C call into the old MMD system, bam!
- I've been replacing them with the new C-style calls
Patrick:
- it's just that PGE is exposing the bugs
- it's not a source
Allison:
- that's why it's so perplexing
- I haven't been able to trace it back to a particular call
Patrick:
- I'll look at it too
- I'm happy to see Parrot taking this new model
Allison:
- we can avoid a lot of indirection
Larry:
- there have been discussions of different levels of test harness support
- we need to straighten out the namespace
- "What does
use Test; mean?"
- it has overloaded meanings for many people
- should that be the minimal thing, and everything else be larger
- or should the minimal test thing be built into the language
Jesse:
- that would be fascinating
Jerry:
- and everything's
multi and can be overridden?
Allison:
ok() and is() are easy to write- easy to include in the language
Larry:
- just in the standard Prelude
- it's like POD's play to bring documentation into the language to make it easy
- it could be a module that Prelude brings in
Patrick:
- just a module that implements these?
- they print what they print now?
- I'm happy with that
- I'd like to define the minimal set of functions that the test suite can rely on
Larry:
- or the fancy set should be the default set
Patrick:
- I can argue it that way too
- but that seems to be the wrong way
- I'm happy for any clarity the Perl 6 designers throw in there
Jerry:
- for a Perl 6 implementation to be a real implementation, it uses the core tests only
- and builds on top of those
- any other fancy test library is out of the core and builds on Perl 6?
Patrick:
- the test suite functions are part of the official test suite
Nicholas:
- that scared me slightly in how the perl 5 core bootstraps itself to testing, and trusting/testing its test system
- the very early tests run inline
- you can't be sure that
require works
- the next step uses a file named test.pl
- doesn't use
++ for example
- everything beyond the core ops tests are free to use
Test::More
- written in proper grown-up Perl
- uses constructs which may have failed earlier
Larry:
- we still have two of those things
- the third level is potentially possible
- the core definition of standard Perl 6 could have a fancier test module
- the test prelude we're talking about is the equivalent of that test.pl
c:
- and if you're implementing this, you can hardcode these as special cases in the compiler
- and then you can rewrite them in your Prelude when you have that working
Patrick:
- we can get rid of the line
use Test; in our tests now
Larry:
- that's part of the motivation
Patrick:
- we don't have to worry about getting our namespaces working first
- I'm in favor of that
- that would have sped up a lot of stuff in Rakudo development
Larry:
- the only other major argument against it is the notion that the function names are Huffman-coded for testing
- not necessarily general use in a language
- a user might want an
ok() function that does something else
- that's okay, if we do the overriding properly
- but there's a conflict with the current spec because there are two different meanings of
is
- I can change the meaning of
is Dog;> within a class
- it can be specific, so it only parses on
is followed by a type name
Jerry:
- or it's only a single parameter
Larry:
- multidispatch could handle that, but it's declaration
- declarators need compile-time resolution
- it needs compile-time distinguishing
- the other
is has multiple arguments
- this one never does
Patrick:
- it hasn't been a problem in Rakudo yet
Larry:
- it's doable
- the question is if it's too much of a hack
- or if there's a better way
Patrick:
- that depends on what the meaning of "is" is
- what kind of equivalence does it do?
Larry:
- in the header, it's either a trait
- or if it's a type name, it turns into an
isa
- there's some argument of some kind
Patrick:
Larry:
- or we can do
is_eq, is_eqv
- or just
ok
c:
- but you do lose diagnostic messages
Larry:
- unless it's a macro
- but that could be too clever
c:
- what if someone thinks
is is infix?
- equivalent to
== or eq?
Nicholas:
- or
is can do smart match
- you have smart match in Perl 6
