The Perl 6 design team met by phone on 14 February 2007. Larry, Damian, Allison, Patrick, Nicholas, and chromatic attended. These are the notes.
Larry:
- more of the same from last week
- trying to think through what the Perl 6 grammar will eventually look like
- almost all of the recent Synopses changes came from that
- apart from the fact that I can't actually test it, it seems to be shaping up rather nicely
- eventually I'll need more feedback and eyeballs on it
- completely bonkers or just a little bonkers?
Damian:
- I've liked the diffs that I've seen
- you'll get quick feedback if I don't
Larry:
- some of those things are marginally related
- you stare at quote declarators for a while and you see that they're the same as macros
- I'm looking at all of the places that I can simplify now
Patrick:
- I went "yay" when I saw that
c:
- be careful; down that road lies McCarthy, 1958
Larry:
- we have a ways to go
- we put a bunch of stuff in the basket
- now we're seeing what we can take out but still solve the problem at hand
Damian:
- working on getting the Perl 6 POD parser shippable
- very close to that now
- currently augmenting the test suite to cover everything in S26
- then I'll ship it and a working POD 6 to XHTML translator
- as well as a text translator
- and a module to let you write POD 6 in Perl 5 programs
- expect that by the middle of next week
- taking up my time this week
- getting performance pretty reasonable
- been watching Larry's Synopsis diffs very happily
- very happy with the minor change of making the short form of heredoc
Larry:
- if I can't recognize
:t, no one else will recognize it
Damian:
- it's a very good change
- sometimes those little ones are the very important ones
- they can be the ones that happen all the time
- putting together my various tours for the year
- preparing for a talk early next month in Sydney
- the Australian copyright collection agency
Patrick:
- spent this past weekend sick
- looked over Larry's grammar
- find it interesting and intriguing
- I can't wait for someone to actually parse it!
- oh wait, that's me
- I'm optimistic about it
- may be able to come up with something quickly
Larry:
- trying to keep in mind the bootstrap as I go
Patrick:
- it helps me with some of the other features it'll need
- if I see anything that offends me, you'll hear about it quickly
- I have to deal with it earlier than other people will
- otherwise, just watching the various changes
- I like what I've seen so far
- hope to get lots of implementation done
- I'll be around all day on Bug Day on Saturday
- should be able to do the Parrot monthly release on Monday or Tuesday
- do have reference working
- much more work than I originally anticipated
- next thing is compilation units and
END blocks
- I know how to do them
- I just need a day to come up with a good design
- it's not an all-at-once thing either
- can check it in incrementally without breaking things
c:
- came up with an interesting approach to running Perl 5 on Parrot
- I sent in a code example
- curious to see what Larry and Nicholas think
Larry:
- what's the story with XS?
c:
- I'm punting now on that
- we do run things through
xsubpp
- we do have some flexibility with redefining macros
Larry:
- even 90% is better than a kick in the head
Nicholas:
- this approach is part of what I planned to do with Ponie
- you're starting from a different place than I was
- there are a lot of complex opcodes...
- but it doesn't require modifying the Perl core
Larry:
Damian:
- the question keeps coming up
- if we have a C to Parrot compiler, in what way doesn't that solve the problems?
- apart from that being the problem
Nicholas:
- in the moment, Parrot is written in C
- you can link them together
- having C running alongside Parrot, the trick is getting them both not to realize that that's what's going on
Damian:
- sounds like you may need to try some of the hairier opcodes
- if those seem feasable, that says something
c:
- I can look into that
- may try some dynpmcs to solve the SV problems
- right now
print assumes that it only gets SVs with POK
- that doesn't help if you pass an array
- took about an hour and a half
- I wouldn't have done it if I thought it were more complex
Allison:
- sounds like it's worth more exploration
Damian:
- maybe with input from Nicholas as to which alleys to walk down
c:
Damian:
Nicholas:
- even the
add op isn't that simple
- some magic in there
- you even hit polymorphism on
SvTYPE
c:
- was thinking about making the PMC wrapper code do magic that way
- makes things easier
- may not support ties and overloading yet
- although putting that magic in the PMC vtable methods might simplify it...
Allison:
- put out an Objects PDD revision
- particle's reviewing it
- pretty solid conceptual update there
- did the refactor of
HLLCompiler that Pheme needed
- you can delete stages from the tree transformations
- just need an extra subroutine to make adds work
- Pheme needed one bit to override the OST grammar
Larry:
- as I'm doing this grammar, I keep finding that I want to have context variables for rules
- the only way I can declare them now is by putting them in the singature as an optional argument that I just don't pass
- seems kinda kludgey
- should there be a way of declaring variables for a rule or regex or token
- or should all the name components of a particular match be contextual?
- you're parsing and find a scope declarator
- you might parse another declaration which wants to know its scope
- you may have to pass that down another few levels though, so a context variable might be nicer
Damian:
- have you thought about what kind of syntax you would like for that?
Larry:
- the best syntax is no syntax
- run up the dynamic stack and look for a match
- treat all of the named match variables as potentially contextual, you get that for free
Patrick:
- we ran into something similar in TGE
- a node in the match tree doesn't know its own name
- "I want to know something that only my parent knows"
- sounds like the same question
Larry:
- using
caller() to find your own identity in Perl 5
Patrick:
- we want to match all of the statement nodes
- but none of them know that they are statement nodes
- maybe there's a generalized solution
Larry:
- it's on the order of attribute-grammarish
- things propagating down and up the tree
Patrick:
- not sure that we're looking exactly for contextual variables
- but I get the same positive as I did when I saw captures
Larry:
- trying to make this look as declarative as possible
- even if some things are procedural
- context declarations are procedural: run up the stack
Allison:
- inherited attributes, maybe
Damian:
- if you're going to use the existing components of a higher-level rule
- you start creating difficulties in the sense that you have to design your entire grammar so that names don't clash
Allison:
- I don't think you'd want it on every variable through the system
- "this variable is special; it propagates"
- you don't want every one propagating through the tree
Larry:
- we're doing that through the rule parameters right now
- I'll keep thinking about that
- I'm happy to stick with the parameter approach for now
- okay, I'm not, but I'm less unhappy with that than installing a kludge
c:
- how much of this information escapes the rule?
- reminds me of the implicit environment passed around in Scheme and Lisp
