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 ]

Journal of luqui (5770)

Thursday November 24, 2005
02:11 AM

Today's Perl 6 Meeting Notes

[ #27720 ]

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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.