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 ]

Perl 6 Design Meeting Notes for 13 June 2007

Journal written by chromatic (983) and posted by davorg on 2007.06.15 7:21   Printer-friendly
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:

  • how was your talk?

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:

  • that's on my list

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:

  • you're right
  • I'll fix it

Damian:

  • oh
  • okay

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:

  • depth or breadth?

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
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.