Allison:
- continuing to work on Punie using TGE
- working on a grammar to convert Punie match results to PAST nodes
- think I have a complete set of PAST nodes
- simple core class and subclasses
- mostly based on Pugs's PIL
- didn't bother with Haskell-specific nodes
Luke:
- PIL 1 or PIL 2?
Allison:
- looked at both
- closer to PIL 2
- not exactly either one
Luke:
- I can't figure out where PIL 2 encodes its structure
- it works? That's cool
- I don't know how
Allison:
- I'm not familiar enough with Haskell to mimic the implementation
- but I don't need to mimic the implementation
- seemed like a nice set of abstract nodes to start
- hope to finish that Punie match trees -> PAST grammar and nodes and
tests today
- might play with opcode syntax tree
- it's going pretty fast so far
- Roberta is on vacation for the next three weeks
- we're still passing around license and contributor agreements for review
now
- if you have suggestions for people to review it, please let me know
Patrick:
- a few minor updates to S5
- answering questions about that
- minor changes there
- added a Perl 5 pattern parser for PGE on Thursday
- it understands rudimentary and basic Perl 5 patterns
- Jerry Gay is porting over Perl 5 regex test suite
- we can test PGE against them
- there are 800 tests, he has to skip 290, and 155 are failing
- I'll add a few things to handle those as time permits
- not a high priority
Jesse:
- that's a fairly late milestone
Patrick:
- I'll work on it when I feel like getting a few quick tests out of the
way
- ought to be handoffable to someone who expresses interest
- I'll post a message about that
- there's already a test suite
- they get a lot of quick wins
- otherwise, I'm trying to catch up with Larry's changes
- I'm just going to have to reread the Synopses again
Jesse:
- you were originally planning to work from a snapshot of the Synopses
- did that work out?
Patrick:
- we'd have to take another one to do that now
Jesse:
- are you spending enough time churning that it's worthwhile
- or are the changes useful enough to track?
Patrick:
- they're useful
c:
- hope to make more progress on Parrot Test::More this weekend
Luke:
- scrapped theory.pod v1, working on v2
- it has nothing to do with theories anymore
- reading TaPL
- coming up with a core calculus for types
- it's the the same calculus as for execution
- embracing executing code at compile-time
- leveraging that into the type system
- hope to start with something simple
- writing a toy language right now
- hope to implement union types and subtyping within the toy language
- wondering how I can do inference in that
- but it looks like I can build just about everything we need
- way cool
- surprised me
- being thoroughly impressed with Haskell
- it was up and running in 200 lines of code
- becoming more of a convert every day
Allison:
- Patrick
- meta-information from match nodes
- you're printing line number and source string in the dump?
Patrick:
- PGE's built-in dump?
- not using Data::Dumper?
Allison:
- I'm using Data::Dumper
- name of the rule, source string, character number on the line?
- is there a way to get the line number of the source code for the match?
- how can I get that string you're printing in the dump?
- it's the raw source that this particular rule matched
Patrick:
- for every match object, there are from() and to() method
- offsets to the beginning and the end of the match
- the match object contains a reference to the entire string it's matching
- also then has the offsets for the portion that it matched
- when you ask a match object for its string value, it gives you that
substring
- in Parrot, if you assign it to a string register, it stringifies
- you get the substring that it matches
- match objects duplicate the semantics of S5
- if you ask a match object for an integer, it gives you the integer
conversion of the string
- boolean, did it match?
Allison:
- lines are harder
Patrick:
- because you have the from position, you can use it against the original
string and find out how many newlines occurred before it
Luke:
- ugh
Allison:
- it'd be nice to report what line of the source file had an error as I
write compilers
Luke:
- who cares about cost when you report an error?
Patrick:
- that's better than incurring the cost of counting newlines as you go
- just count them in the string
- I could write a method for it in the match object
- but that's all it would do
Luke:
- people will want to annotate the parse tree node with the line number
- if it has a run-time error, it can report the line number
Patrick:
- that's pretty easy to do
- no problem
- I'm not certain how to fit that in
- whenever we're matching, we have to figure out where to do that
c:
- need some rule with a closure that annotates the tree at newline points
Allison:
- but you have to count every newline, even if it's in an embedded string
or heredoc
Patrick:
- you don't need to annotate every node
- just the interesting things
- match objects tend to know a little bit about their context
- each could easily report how many newlines were prior to it
- and how many newlines it contains
Allison:
- is this the wrong solution?
- is it more at the level of where we read the file?
- but I just read up to the maximum buffer size
Patrick:
- me too
- but this'll change in the future anyway
- as long as the match objects contain the offset... provided you have the
source lying around somewhere
Allison:
- I think you're right to delay expensive operations
- if I store the offset
- figure out some way to make the original source string available to the
error reporting routine...
Patrick:
- I've come up with enough cases where it seems useful to have a target()
method on match objects
- return the whole string they're matching against
Luke:
- we want to support streams too
Patrick:
- that's not a permanent idea for the design
- we could throw it in right now
Allison:
- it's just a question of where to put the error reporting
