The Perl 6 design team met by phone on 13 June 2007. Larry, Damian, Patrick, Jesse, and chromatic attended. These are the minutes.
Larry:
- worrying about the special case
- sharp at the beginning of the line is always a line-end comment
- I think I have a better formulation for that now
- it solves the problem of somebody putting an embedded comment at the start of the line and expecting something at the end to run
- seems to clean up a couple of other issues
- makes it possible to comment out POD
- I think it's a keeper
- differentiating bracketed comments into embedded forms and line-oriented forms
- hacking in the grammar to do that
- added an optional namespace above global
- it's process global
- if you're embedded in an Apache server, for example, it distinguishes the process namespace from the global namespace
- the global namespace continues to look like what you get in a standalone Perl
- it's still cleaner to separate that out for various reasons
Jesse:
Larry:
- it went pretty well
- I spent a great deal of my time writing that talk
- it's an interesting conference
- several hundred programming language geeks of the CS variety
- they tend to have very specialized interests and speak very technically
- Perl came off pretty well during the weekend
- the functional programming panelist as much as said that Perl was one of the successful functional programming languages
- he counted among the failures Lisp, Scheme, and Haskell
- this was the Scheme guy saying this...
- I think some people cottoned to the notion that we're doing something special here
- being a "scripting" language is not inconsistent with doing other paradigms well
- if we can get more academic attention and stay practical at the same time, that would be good I think
- other random interactions on forums
- stomping on the conditional operator complexification
Damian:
- things are getting better
- took a long weekend for our 17th wedding anniversary
- also stomped on the ternary complexification
- thinking about Larry's new plans for comments
- looking at the POD parser to prepare
- I have lots of questions and feedback
- starting to prepare for YAPC::Europe
Patrick:
- Coke and c have done a lot of work in passing the Perl 6 sanity tests
- we have only two sanity tests failing now
- one of those is only loading the
Test module
- the other is handling the
Bool::True type and returning the correct value there
- we're very close to being able to pass 01-sanity
- it looks like we'll have that before YAPC::NA
- probably even before this weekend
- we may even make it in time for the release
Jesse:
- please blog the hell out of that when you get it done!
Patrick:
- that may be what I spend the next couple of days doing
- also have the new quoting syntax from S05 working under Parrot now
- (the ability to do proto regexes and
:sym<...> is still not implemented)
- I've started converting some of the grammars over to that syntax
- it's a piecemeal approach
- the grammar that we're using for Perl 6 on Parrot can now converge with Larry's standard grammar
- we don't have some of the pieces yet
- but we won't have syntactic differences
- it looks much nicer
- that'll make it easier for people who want to look at the standard grammar and not deal with syntactic differences
- finally also working with the Perl 6 light language
- substantially easier due to Coke's work
- he added for loops and iterators in the AST
- that'll make building this language a lot easier
- we'll use that to do transformations in the parse tree instead of TGE and PIR
- that means a substantial code reduction and clarity improvement
- this week should be a very productive week
c:
- whacked on Perl 6 a bit
- sanity tests are getting close
- I'm waiting on some of Patrick's stuff at the moment
- also tracking down a few bugs
- found a very nice (up to three times) optimization in Parrot
- it's not complete, but it's decent
Jesse:
- talked to Patrick about his status
- also talked to Flavio S. Glock about Perl 6 on Perl 6
- he's having a lot of trouble convincing people that they don't need to know lots about Parrot internals or Pugs internals
- there are a lot of small tasks
- I'm trying to get him to write a lot more about his work
Patrick:
- we talked yesterday
- he's interested in working together on the Perl 6 light language in Parrot
- I'm happy to turn that over to him if that helps
- it might be simpler than having to deal with P6 on P6 stuff
- he's interested in getting the two projects to converge
Jesse:
- that could be interesting
- have you talked about what would make your S05 stuff more useful?
Patrick:
Damian:
- I have some concerns about the multi-line comment syntax and its relation to POD
- it's a great language construct
- my concern is just this interaction
- POD has always been a layer above the code
- you don't have to understand the code to parse it
- this new language feature sits above the POD as well
- it mixes the levels
- the rationale is to comment out POD
- you could already do that with the
=comment block, which comments out POD in POD
- why is it necessary to put this type of comment at a level above POD?
- why not just a programming level construct that works as it works?
Larry:
Damian:
Patrick:
- in order to put precedence levels on tokens, the new standard grammar defines the return type on each token
- I agree about folding them in in that way
- the Perl 6 language ties those into
tighter, looser, and equiv at the subroutine level
- I'm looking for soemthing cleaner than a return type
- Python, Parrot, abc, etc want to use the bottom-up method
- doing it through the return type seems unclean
- precedence and associativity really attach more to the token than the subroutine
- it's a function of parsing
Larry:
- we are returning a token
- we're not returning a subroutine
- the subroutine gets written later
Patrick:
- in terms of writing the grammar
- we're defining that as mix-in return type
- that feels funny to me
- I could see doing it for Perl 6
- but I want to get a better answer for the compiler tools for other language
Larry:
- the precedence has to come back with that return object
- whether has-a or is-a doesn't matter
Patrick:
- I'm just looking for something syntactically nicer
- is it the nicest we're going to get for a while, or could we look for something nicer?
Larry:
- the Perl 6 grammar factors out those precedence levels into type roles
- anything that ends up setting your match object with a retrievable precedence and associativity is fine by me
- with a match object, you might just poke it in as named fields or something
- it felt more like an attribute of the object itself than a match parameter
Patrick:
- these are definitely attributes of the thing returned by the rule
Larry:
- to me, the current way seems like the cleanest
- maybe we have different definitions of clean
Patrick:
- I'm not comfortable having 26 different types, one for each return level
- that could just be me
Larry:
- the other view is that you have a different type for every return object if you're just mixing things in directly
Patrick:
- is that an advantage of how we're doing it now?
Larry:
- you end up repeating information all over the place
- you have to mark different things at the same precedence level
Patrick:
- I was looking from the Parrot level, where they all end up referring to the same object
- I'll just go with what we have now
- I think I'd have to come up with something I like better to negotiate it
- if I come up with something in the next couple of weeks, we can discuss it
- my intermediate plan for people not doing Perl 6 compilers is that they'll continue to use the pointy sub syntax to identify their tokens
Larry:
- if the heavy magic is for Perl 6 to allow extensible grammars and other languages don't want to tap into that magic, that's fine
Patrick:
- it's simple in Parrot to get their precedence levels bottom-up now
- if I switch to the Perl 6 approach, their complexity goes way up
Larry:
- it's sort of a duck-typing non-duck-typing issue
- we can leave it at that for now
Jesse:
- what's your sense of the completeness of the Pugs test suite?
Larry:
- we should probably double it
Jesse:
Larry:
- not sure
- there are interesting things in the unspecified directories
Patrick:
- there are a lot of tests written from a Perl 5 point of view
- there probably needs to be some review
Larry:
- it's a whirlpool, not a waterfall
Patrick:
- Coke added a make target that pulls in the Pugs test suite
- without adding to the repository
Larry:
- we want to avoid duplicating test suites
Patrick:
- for the time being, the Pugs test suite is the official one
- that's an explicit edict now
- from the Parrot side, I want to go through them one-by-one and see where they match the spec
- if they don't, we'll discuss the spec, or I'll check in the corrected test
- after we can run Test.pm, we can look in the test suites in great detail
- is the test correct?
- what do we need to do to get this test to run?
Larry:
- that will be very valuable
Patrick:
- that's why I really want to have this running by YAPC
- we can recruit more people then
- we discussed the Parrot talks on #parrot yesterday
- the sequencing of talks is almost perfect
- an introduction to Parrot through the Perl 6 Compiler in several talks
