Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of luqui (5770)

Wednesday January 11, 2006
09:40 PM

Today's Perl 6 Meeting Notes

[ #28319 ]

Damian:
        - things are looking up
        - I took a break, which helps
        - first week back at work from the near year
        - lots of mail
        - I'll be in Asia and Tokyo in March
        - otherwise enjoying the holidays
        - I've been tracking Larry's updates
        - intend to send more feedback soon
        - I'll be at a Linux conference in New Zealand the week after next
        - I'll have time then

Patrick:
        - lots of non-Perl busy-ness here
        - will pick up on PGE again tomorrow
        - another project moved up a deadline, so that was busy
        - should free up some time tonight

Jesse:
        - what's the next checkpoint there?

Patrick:
        - actually writing a parser for Perl 6 code
        - I have the various pieces in the constellation to bring them together
        - figuring out what to do with the parse trees comes after that
        - but we can generate parse trees
        - I'll also be on #parrot again

Allison:
        - working on extending Punie still
        - Patrick, I mailed a question about the operator precedence parser
        - working on comma-separated expressions
        - discovered an interesting thing
        - you can set up a PGE grammar to make it easier or harder to write tree
            transformations
        - the Perl 1 style of recursive rules makes trees harder
        - at least, harder than repetition within the rule

Luke:
        - what are you turning things into?

Allison:
        - some things need flat lists
        - some things don't, but flat lists are easier to iterate over

Patrick:
        - it can make a huge difference
        - it's nice to have both options with a nice syntax
        - is there a reason not to treat comma as an operator?

Allison:
        - not sure
        - I'll decide which way works best later
        - but I suspect repetition may be simpler

Patrick:
        - my plans for operator precedence allow list-associativity
        - so it may work easier

Larry:
        - Perl 1 had a lot of hard-wired things in its grammar
        - Perl 5 was more flexible

Allison:
        - definitely interesting and informative

Larry:
        - various bad luck
        - desperately trying to follow along on everything at once
        - not really responding
        - my day job is really busy for the next couple of weeks
        - haven't done anything on the translator
        - I'm letting that gurgle in the background

Jesse:
        - what's your goal for the translator?
        - 100% test suite?

Larry:
        - I don't know that it can ever get entirely there
        - but it's effectively there already
        - I don't know how much I'll have to warp it
        - I'm pretty confident I'm getting all of the information out
        - I don't know if I'm getting it all out in the most convenient form for
            the translator
        - it'd be good if someone could merge it back in to the Perl 5 mainline
            at some point
        - my impression is that Perl 5 is not mutating rapidly at this point
        - not a big rush

Luke:
        - what are its effects on parsing speeds?

Larry:
        - very little
        - only a few conditional tests if you don't want the extra information
        - a separate grammar file with extra goodies
        - just a wrapper around yyparse mostly
        - that was part of my original spec
        - do need some stuff in the tokenizer, but they're guarded by conditionals

Luke:
        - not much this week
        - thinking about generalizing the design of Parse::Rule into useful
            language constructs
        - I had to pull some dirty design tricks
        - talked a bit on p6l about composable modules
        - now thinking about building an object and type system out of them
        - haven't had much time to work on it
        - but it looks promising
        - my final project for cognitive science was on tree adjoining grammars
        - they seem appropriate for our metaoperators
        - instead of building a separate operator for each metaoperator-operator combination, you
            could set that up as an auxiliary tree in that theory
        - you can parse them top-down
        - as long as you have parameterized rules
        - I wonder if I can massage that into a grammar that actually works
        - does PGE do parameterized rules?

Patrick:
        - it only understands strings so far
        - subrule name, colon, space -- everything else is an argument
        - from Apocalypse 5
        - maybe never blessed into a Synopsis
        - official syntax is subrule( list )
        - PGE doesn't understand that yet

Jesse:
        - spent two weeks mostly not working
        - ended up writing some code, which was weird
        - heard from Chip on Monday; he's back now
        - have had some interest in Ponie pumpkining
        - is anyone blocking on anything external?

c:
        - what's the legal documents status?

Allison:
        - it's probably time for the public review

Luke:
        - Audrey is prodding us to come up with tagged unions
        - the theory.pod syntax isn't very nice
        - can't put my finger on why
        - I looked at OCaml's tag types
        - put a tag on a type and get a new type
        - then create unions of types and get a tagged union
        - but I've never seen them used in practice
        - I wonder how well they fit common uses

Larry:
        - the type becomes a value bit of the new tag
        - used as a discriminant at runtime, if not earlier?

Luke:
        - I think so
        - Perl has scalars where they are kind of deranged tagged unions with more
            than one tag at once
        - but ignoring that...

Larry:
        - I'm agreeable to the idea that unions should be discriminated
        - the C idea of unions is a complete botch
        - there has to be some way of telling them apart
        - if they're objects, they have their own built-in identity
        - but I'm not a great type theoretician

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.