- almost finished with the tree transformation thing that takes a grammar
- last remaining piece is tricky
- if you use compreg and compile a subroutine on the fly from a string of
PIR text, can you have parameters in that?
- can you accept subroutine parameters?
- do you have to declare it as a named subroutine?
- you have to compile it as a named subroutine
- you can make it anonymous
- give it a name, but put
- that's exactly what I need
- you get back a PMC that you can call like any other subroutine in a PMC
- I'll have a version of the engine that uses grammars by the end of this
- parses the tree grammar file using PGE
- does a tree transformation on the match result
- then loops through the tree (an array of rules, where each rule is a
- compiles rules for an attribute grammar from that result
- you can compile from a tree grammar file to a working tree grammar
- you use a tree grammar to use this
- an abstract syntax?
- your attribute grammar
- I can create that from a syntax file
- I do that using attribute grammars
- for me, it ended up being less readable than doing it by hand
- but it's fun to bootstrap
- it was my way of testing if I can use an attribute grammar
- before I put it into the repository, I want to make sure that I can
parse the output from a PGE match and transform it
- this proves that that is possible
- also Roberta and I finished our final draft of the Artistic Licence 2.0
and the contributor agreement
- the next step is to solicit reviews from a few interested parties,
including the patent lawyer
- then we'll do a general public review
- will Perl 5 come under this agreement as well?
- we took that into account for the contributor agreement
- can you have the Perl 5 cabal review it too?
- PGE has grown by leaps and bounds
- converted it to use a shift-reduce parser internally
- everyone else can use that parser
- probably 25% shorter in parsing code, much faster
- also added support for custom whitespace rules
- create a grammar with its own rule
- now does closures; can embed them in a rule
- can specify what language it'll send to which Parrot compiler
- can you give it a lexical pad to start with?
- does Parrot already do that?
- haven't done anything with that yet
- shouldn't be hard
- we can do whatever we want
- I'm still waiting for the dust to settle on the design
- suppose I wrote a lexer for a LALR(1) grammar?
- can I have PGE understand that?
- as long as it understands match objects
- you can control how it handles tokens
- "give me a match object"
- "call this subroutine which tells me how much to consume"
- the subroutine can be a rule
- go from recursive-descent to shift-reduce or vice versa at any point
- we don't have to worry about backtracking over Perl comments, for
- they're atomic
- pretty straightforward
- can you commit yet?
- will that allow us to clean up memory that we don't need?
- not yet
- but I know how to do it
- you can take any match object and call the same rule
- it gives you a match object that starts there
- drop the old object and the GC will clean it up
- continue from where that match started
- I can build that trivially in about 15 minutes now
- I did lookaheads
- I'll do lookbehinds in the near future, with a naive implementation
- particle on IRC has committed around 200 tests for PGE
- I'll clear off a lot of the TODOs there to reward him for his work there
- my next plan is to start parsing Perl 6 expressions
- I'll go as far as possible
- should be able to go quite a ways
- already an expressions parser in the examples directory
- you can get back a parse tree with precedence taken into account
- now that that's a rule, I'll start working on statements
- we'll see where it goes from there
- probably can produce fairly complete parse trees for Perl 6 programs in
- may not have all of the esoterics in there, but most will be available
- one question
- I can fairly rapidly build an interpreter based on the match tree
- is that a direction to bother going down?
- it would be useful just in a sense of having bits and pieces being
usable right away
- that's the way I want to go
- I'll start building an interpreter
- it may be slow
- my intermediate goal is to get the language interpreter far enough along
that it can run the Pugs test harness
- that's what Pugs did for a while
- that sucks
- all of your special cases get into the big, bloated runtime
- we're working on the syntax tree at the same time
- we will do that
- it's just nice to have something running
- I think Luke means "don't go too far with it"
- you don't want to go too far in that direction
- people could spend their time adding features to a bloated interpreter
rather than building a small, scalable one
- where do you stop?
- where do you throw it out and start with PIL?
- when I push the tree transformations two steps further and Patrick can
use that instead of the interpreter
- PIL and the interpreter aren't entirely in conflict
- my goal is the compiler
- I don't want to target PIL directly
- I need something to evaluate my syntax trees relatively interesting
- you don't want to go too far, like Pugs in throwing so much away
- the best way to check the grammar and PGE is to have something that
actually works while he's at it
- you can help out, Luke
- when you think it's going too far, say so
- it goes too far with other contributors, not you
- we don't really have other contributors now
- we could get some very quickly
- "thanks for your help, but we're throwing it away now"
- we'll just tell them up front
- I'll create a new languages/ directory so it's clear it's not the
official Perl 6 system
- we will watch for that very carefully
- if this system doesn't have a release schedule but the Perl 6 compiler
does, it'll be clearer about our priorities
- one more thing though
- Perl 6 is a complex language
- I think that interpreter will be bigger than you expect it to be
- I don't expect to write a complete interpreter
- I expect to write enough to get me to a compiler in a comfortable
- after writing PGE as a compiler, I know that's how I want to go
- describing it as a development aid and experiment might help
- I'm planning to send out an e-mail later tonight if I can stop coding
long enough to document things
- I'm happy that everyone else is making good progress
- I didn't this week mostly because of school
- I was going to write a couple of things, but they're still on my queue
- also going to port Language::AttributeGrammar to Perl 6
- are you blocking on anything else?
- only learning my way around the new Parrot
- working on the book
- writing a proof of concept in Perl 5 that I can port to PIR pretty
- requires the OpenGL bindings
- are those maintained?
- I have a proof of concept on my hard drive
- I think it'll be pretty easy
- don't need to wrap them in a nice interface as I did SDL
- should be a quick port
- Autrijus and Liz have been enumerating their desires for S17 and
concurrency in Perl 6
- once they feel like they have a draft they like, should they send it to
the cabal and ask where to go from there?
- maybe the answer will be "no, this isn't what we want!"
- yes, that is the right way to go
- I remember discussions from Perl 5 several years ago
- someone needs to go over the proposal and see if there are portability
problems and guarantees
- they're talking about STM for this
- seems like a disconnect between what Ponie wants
- the fact that everything in Ponie goes through a vtable means that
there's no speed hit for going through non-shared code
- there'll probably need to be the concept of closing in Parrot
- as soon as you start a thread, you'll have to replace the parent vtables
with shared ones
- this probably needs Chip
- don't know how much Chip has thought about it yet
- it sounds like the right thing to do is to pass the draft around to
everyone who's thought about threading in Perl 5
- next week, the call will be at the DST time
- 10 pm UK
- GMT now