Larry:
- trying to figure out types
- and everything else
- rewriting the world
- put out new versions of S02 and S06
- already have things I want to change
Luke:
- good thing committing only takes a couple of seconds
Larry:
- also I was in Hungary
- it was thirsty
- they apparently don't believe in caffeine there
- I spent a goodly part of that with a headache
- the conference was pretty okay
- getting ready to give a talk to HP on Thursday
Jesse:
- Perl 6-ish?
Larry:
- variant of my 9.3 State of the Onion talk that I gave at EuroOSCON
- it'll be by teleconference
- my slides will be a Java app running in everyone's browser
- part of the reason I did EuroOSCON with just words is that I wanted it
to still work in case everything blew up
Jesse:
- I'm pleased using the Takahashi method Autrijus found
- it just works
- I can edit them in a text editor
Larry:
- the named arguments are now marked with colon instead of plus
Luke:
- makes many people happy
Larry:
- probably the type sigil is up arrow, rather than a cent sign
- as in caret
- we're trying to iron out all of our terminology for what's a class and
what's an abstract class that isn't really a class
- probably relates to Luke's "a class is not anything"
- think we're making good progress on that
- looks like I'll be home for the next couple of months
- I'll probably accept a position at the place where I'm currently
consulting
- I'll still be spending the majority of my time on Perl 6
Patrick:
- checked in my shift/reduce parser last night
- busy cleaning it up
- it works pretty nicely
- getting ready to parse all sorts of Perl 6 expressions
- then I found a segfault (which I reported earlier)
- I think I'll be able to parse out most Perl 6 expressions now
- including all of the weird whitespace things
Larry:
- can that all be in one spot, like we talked about?
Patrick:
- yes
- register a token and specify if it's whitespace okay or not
- if you need to do fancy things from the bottom-up parser, you can
always call a rule
- it tells the shift/reduce parser "this is what I have, now continue on"
Larry:
- okay
- does the rule vs. token distinction we discussed make sense in this
context?
Patrick:
- for general in Perl 6 rules?
- not at the moment
- I like the way :w works in general
- pretty nice way of doing it
- :r :t that Damian proposed didn't do anything for me for these things
that I needed to parse
(On the cabal list we have been discussing separating the concepts of rule and token for whitespace dwimmery purposes. -L)
- now I'm working on parsing out the ternary operator
- think I have that working in the past five minutes
- next steps are to test and check in some examples
- Perl 6 expressions, Perl 6 rules, general expressions
- parsing gives you a nice match tree with the nodes in the right place
- useful starting place for figuring out the tree transformations we need
to do
- especially true for the grammar engine itself
- once I parse it out to the tree, we want a bunch of transformations and
optimizations
- I'll write PIR code that does that for now
- we can catalog those we need and how we might want our TTL to look
Larry:
- and not box ourselves in so we can't use "use" statements
Patrick:
- also promised to update the milestones document for PGE today or tonight
- just haven't done it yet by being too busy writing code
Allison:
- sent a patch to p6i to update the opcode mismatch error message
c:
- not sure that's the right approach
- I like your second suggestion better
- I can look at it if you like
Allison:
- that's why I sent in the patch, not checking it in directly
- this made my life easier though
Larry:
- are these capturable by something running atop Parrot?
Allison:
- it's an interpreter exception
- working today on finishing the PIR attribute grammar implementation
- coming along nicely
- because of the closures issue, I've made it much more heavily OO
- instead of relying on closures to capture a certain value, I'm passing
around relevant objects
- AttributeGrammar::Rule object, for example
- pass that down to where it needs the information
Luke:
- might be a better approach, given Parrot's architecture
Allison:
- seems to be working better in PIR
Luke:
- which version are you interpreting?
- I released a new one this week
Allison:
- started with the old one
- figure I'll update it later
- the old one was simpler in the model
- which parts did you change?
Luke:
- completely rewrote it
- most of the algorithm's semantics rely on the simple semantics of the
thunk
- used to traverse the tree, find out the attributes, made thunks if I
need them
- new version makes thunks for all the attributes it may need eventually,
starts with the first one, then goes on
c:
- was this to help memory usage?
Luke:
- yes
- it's hard to tell when Perl cleans up memory
- you can't use this technique verbatim in Parrot because of the
difference in how they handle pads
- write destructor code that tells you when things are cleaned up
c:
- it would be nice if destructors worked
- last time I tried, they didn't
- we need some sort of finalization and destruction
- I want to release non-memory resources at a reliable, known point
- I don't really care when Parrot GCs the dead object
Allison:
- block exit, right?
c:
- that's fine with me
Allison:
- you want to know that you have reliable finalization at some point, not
necessarily at the same time as destruction
- I'll check this into my personal repository tonight
Jesse:
- I'll try to come up with an idea for a more public repository for this
sort of thing
Luke:
- mostly school
- lots of tests recently
- rewrote the attribute grammar module
- nice and memory-efficient, at least I think
- algorithmically it has a better bound
- also started the Perl 6 port of Language::AttributeGrammar
- still thinking about how to do that given Perl 6's handling of pads
- much different from Perl 5
- think that's about it
- attribute grammarsr are a great base for the tree transformation
language we're thinking about
Jesse:
- I was in Stockholm for the Nordic Perl Workshop
- presented 205 slides in 23 minutes
- missed the implementation meeting, but it happened
- need to send out mail about the upcoming time change
- that's it from my side
Patrick:
- Allison, are you waiting on anything from PGE on what you're doing?
Allison:
- I'm doing the part that doesn't depend on PGE right now
- after I finish the port, then I'll start trying out transforming PGE
trees
Patrick:
- I'll send you some PGE trees then
Luke:
- I heard that Larry and Autrijus did some work on tuples
- I'd like to see a summary of that
Larry:
- read S02 and S06
- basically the tuple constructor we stole with \()
- we didn't think that we should throw regular parens at that
- the signature constructor is different from that
- it's still :()
- a tuple is parsed rvalues
- a signature parses differently
- that's how it currently sits
- also there's no special casing about having a comma on the end
- the fact that you are passing it to a function makes it a tuple
- the recognizer for a tuple in a signature is also a backwhacked variable
- Autrijus talked about that part of it
- the slurpy scalar will just slurp one argument at the top level
- I'm sure you'll find other stuff out there, some of which is probably
bogus
Jesse:
- not much conferency coming up
Allison:
- MIT's Little Languages workshop may be the first week of December
- at least, I hope it is
