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

### Journal of luqui (5770)

Monday December 19, 2005
11:26 PM

### Core rule calculus

Lambda calculus is a beautiful compiler backend. When I wrote my Toy language a month or so ago, I used this core data structure:

data AST
= Lambda  VarName AST
| Apply   AST AST
| Var     VarName
| Literal Value

That's it. Those four nodes and I could do anything. I wrote an interpreter for this language in half an hour. I wrote a type inferencer in an hour, scrapped it, and took another hour to write another type inferencer. That's the beauty of a small core calculus. The optimial calculus is hard to come up with, but once you have it, everything else is cake. That's why PIL is so important.

Recently I've been porting PGE to Perl 6, so we can have rules in the Javascript and Perl 5 backends. Perl 6 rules are another fairly simple language. However, Patrick Michaud's calculus has 15 nodes. That's huge! I mean, it's not huge if you're taking the approach of executing the parse tree, as is done by Perl 5, P6C (the initial take of Perl 6 written in Perl 5 for Parrot), and Pugs's first runtime. But my toy language was a powerful experience for me, so I'd like to come up with a simple calculus for rules.

The following three nodes get you to context-free (displayed in Haskell for its consice description of data structures, even though I'm actually writing it in Perl 6):

data Rule
= Literal String
| Union   Rule Rule
| Concat  Rule Rule

Anyone with experience in formal languages will say "That's not context-free! That's not even regular!" Oh, but I neglected to mention: I allow infinite, recursive structures. It's easy to see how to build an inifite structure for the Kleene star. A similar technique will allow you to model every context-free language.

After playing with this structure a little bit, I have concluded that allowing infinite structures is a bad idea. It means that in order to do any processing that isn't straight-up execution, you have to use the graph variants of whatever tree algorithms you were going to use. Those can get complicated, and some algorithms even become impossible. It's like the waterbed theory: I'm pushing too much complexity out of the core calculus.

If we disallow recursive structures, then we need to add Kleene star to get back to regular. To get to context free from here, we basically need symbolic reference. But I'm not going to do that. I have an objection to symbolic reference, and that is that you have to add all sorts of machinery to get it to work in a powerful way: Lexical pads, full qualification, etc. What I'm looking for is a lambda-calculusesque fix, which allows you to build recursion without symbolic lookup or infinite structures.

Maybe that means that I just mimic the lambda calculus and do pretty much what Parsec does: build a value out of functions that can be used to match strings. That gives you the full power of the lambda calculus, and all the research that has been done on it, to match strings. And Parsec can do predictive parsing, which is something I've wanted. The only thing it can't do is bottom-up parsing, which is also something I've wanted. But bottom-up parsing is more restricted than Perl 6 rules, so maybe that belongs at a earlier stage in processing.

Wednesday December 14, 2005
07:10 PM

### Today's Perl 6 Meeting Notes

Allison:
- worked on Pod::Simple
- almost have Parrot recompiled
- network trouble here, making it hard to get the code
- almost have the change to use precompiled PGE grammars working
- the next goal in Punie is to start parsing and compiling other
operations besides print

c:
- fetch, store, and rewind tape, right?

Allison:
- what's the next most important thing after print?

Jesse:
- a conditional
- print "ok 1" if 1

Allison:

Jesse:
- increment, then decrement
- Audrey is in the process of retooling Ingy's Perl6::Bible into p6doc
- synthesizing from the canonical spec
- trying to make them more accessible
- they roped in Skud
- they're trying to make it a better starting point
- trying to extract useful information from the Synopses
- they're a bit sad that Perl 6 Essentials is not open

Allison:
- so am I

Jesse:
- it sounds like Larry is making insane progress
- it's a wonder having something else to work on

Thursday December 08, 2005
02:50 AM

### Today's Perl 6 Meeting Notes

Allison:
- Punie now compiles and executes statements
- print a single digit, multiple digits, or a string with word characters
- no space characters

Jesse:
- that's certainly a start

Allison:
- I want to use Patrick's Text::Balanced hack
- oh, it also parses multiple statements

Jesse:
- that's a good way of keeping your code concise
- is Roberta still gone?

Allison:
- she'll be back December 14th

Luke:
- I'm doing finals
- they're final projects
- thinking about the type system stuff in my free time
- also talked to Autrijus about it
- he convinced me that leaving out a type system is a bad idea for
interoperability
- he said some extremely large undecidable calculus
- trying to come up with a good type system as dynamic at Perl 5's at
runtime, but at compile time

Jesse:
- doesn't sound like much

Luke:
- fairly well-researched except not at all

Larry:
- only worth two or three PhDs

Jesse:
- when do you start to free up again?

Luke:
- my last final is on Monday
- I'll probably start madly hacking, as long as I have something to
procrastinate

Larry:
- merrily hacking away on the Perl 5 to Perl 5 translator
- translates 73% of the test suite successfully
- successfully collecting all the type information that the compiler loses
- starting to think about how I'll use that information
- also for translating to Perl 6
- that's still in thought status
- I'm past the hump on the thing
- I guess there are two though
- getting the first 5% of the tests to pass was really hard
- probably the last 5% will be really hard too
itself
- the tricky thing is I'm not sure what to do about BEGIN blocks that
skip tests
- don't bother compiling the rest
- maybe I need a shim that says "this BEGIN block said to exit, but don't"
- usually a runtime reason, not a compile-time reason
- I'm only interested to running until CHECK time basically
- also worth two or three PhDs

Jesse:
- then do you plan to spit out an arbitrary AST or go straight to Perl 6?

Larry:
- I want to be able to spit out the AST, just for Perl 5
- somewhere in there
- when I have that done
- we can open it up
- pulling the information out of Perl 5 is the insane part of it
- having the AST out in some form cleanly is a point at which we can open
up the project to multiple contributors

Jesse:
- I can see some of the crazy Pugs kids compiling straight to JavaScript

Luke:
- to PIL first
- then we get JavaScript automatically!

c:
- also Perl 5! yay!

Jesse:
- when did you pull from blead?
- not sure how painful the merge back will be

Larry:
- I'm at 5.9.2 at the moment
- it ought to be mergeable
- this hairy dance back and forth between the program which does the
final translation and the internal code which spits out the initial XML
- my basic philosophy is to make minimal changes to the Perl core
- to what extent you just mark up the things as they're going out and
messing up the tree versus intuiting what should have been there...
- only time will tell whether I made the right decisions
- I figured that you can drive it one way or another
- one way and you break the semantics of existing code too much
- "Just don't do constant folding" breaks plenty of things, such as
interpolated constant subroutines
- too much guessing after the fact means I may not have guessed correctly
- there are intermediate forms in there too
- go ahead and keep the same structure
- then annotate it with just a little extra type information for the
backend
- I've been doing that compromise more and more
- seems to work out pretty well
- the ordinary regression tests have two or three failures that need
fixing before the merge
- I don't test that part of it as often as I test the translator

Jesse:
- I bet we can find some help to deal with that

c:
- checked in Test::More in PIR
- talked to Jerry Gay and it looks like we have an easy way to add PIR
tests to the Perl testing harness
- I'll check in some of my library tests and see how that works
- should let us rely on those a little bit more

Thursday November 24, 2005
02:11 AM

### Today's Perl 6 Meeting Notes

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
- 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
- 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
- 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

Monday November 21, 2005
06:57 PM

### New theories

Okay, here's an update on my current thinking for theory.pod version 2. For those of you who read, understood, and were comfortable with theory.pod version 1, prepare to be surprised. I'm completely turning it on its ear. However, I think there won't be a big acceptance issue, since nobody (including me) understood and was comfortable with version 1.

Version 1 gave Perl a (broken) type system with tagged union types and type classes. The system, had it not been broken, would have been turing-complete, and thus you could do all the fancy stuff you wanted, but you'd have to encode it in the language of the type system. For instance, if you wanted to make a vector class that would only allow you to add vectors of the same length, you could do that, but it would be a major pain to implement Peano naturals to encode numbers in the type system.

But that's so stupid. We have a great language, Perl 6, which knows all about numbers (among other things ;-), and we're forced to recreate them for the type system. The number one goal of version 2 is to get rid of this stupidity, and let you talk about the types of your Perl program in Perl. Here are the features I'm trying to support (in rough order of importance; i.e. rough order of required elegance):

* Type metaprogramming; i.e. talk about types in Perl, not some weird type language
* Roles and Classes with mandatory allomorphism (a property of version 1: types are only interfaces)
* Type classes and parametric polymorphism
* Inferrable
* Tagged unions with allomorphism
* Union types [1]

At the moment, I'm doing a lot of research out of TaPL and ATTaPL. It's hard to get a concrete grasp on what those books are saying sometimes, so I'm going to implement a little syntaxless language (not unlike Blondie) with the hard parts of the above points: in particular, an inferrable, metaprogrammable type system.

Incidentally, I think that an inferrable metaprogrammable system needs a logic engine. Cool. I also think that embedding a logic engine in Perl 6 can be done in a unintrusive and easy-to-implement way, providing (and this is the hard part, but it is already specced) support for hypotheticals.

[1] Which happen to screw over inference algorithms. That's why it's way at the bottom of the list. If it doesn't fit, I'll even consider trying to argue us out of supporting them.

Saturday November 19, 2005
04:26 AM

Okay, I thought about this some. I walked around the house, talked to myself, played with some fresh fruit (moving them here and there, describing their properties), and I think I've come up with a very vague idea of this fourth control paradigm.

First, here's how I started. I figured, I'm trying to classify the three existing control paradigms (imperative, functional, logical) into two orthogonal properties. Well, it has to be one of these:

A              B
X | Imperative | Functional |
Y | Logical    | ???        |

A              B
X | Functional | Imperative |
Y | Logical    | ???        |

A              B
X | Logical    | Functional |
Y | Imperative | ???        |

That covers all the possible cases. I then did a little scanning back and forth, and settled on the second diagram, where A ~~ "doesn't change anything" and B ~~ "does change something". Then I did some brainstorming to figure out what X and Y were based on that.

And I think this is it: You give a functional program an object, and it tells you some property of the object (these can be very complex objects and properties, but it ultimately reduces to that). You give a logical program a property, and it gives you an object that satisfies that.

Then, the imperative parallel is: You give an imperative program an *action* and it tells you the result. So, the fourth paradigm is the converse of this; a generalized inverse kinematics engine: you give it a result, and it tells you the action.

A prime example of this kind of paradigm is the UNIX diff program. You give it a file, and the result of some action on that file, and it tells you how to modify the original to get the result. Also, in gaming, pathfinding and inverse kinematics (the process of finding how to move, say, a human body from one position to another in a physically sound way) are both examples of this paradigm.

So what does a language that enables this paradigm look like? And what would you name it?

03:48 AM

### What is the fourth paradigm?

At OSCON, Ovid cited the four paradigms like this:

* Procedural
* Object-oriented
* Functional
* Logical

I've also seen this list in several other places. However, I think this mixes up its concepts a bit. There are really two orthogonal properties acting here: the abstraction style and the control style.

The abstraction style refers to how you break up the logic of your program. It falls into two categories:

* Procedural
* Object-oriented

The difference is what you put in name. In the procedural style, you put mappings (functions) or actions (procedures) into names. In the object-oriented style, you put things (objects) and messages (methods) into names.

The control style describes how the control flows through the program. It falls into three categories:

* Imperative
* Functional
* Logical

In the imperative style, you are instructing the program to do things, to manipulate the state of the world. In the functional style, you are instructing the program to compute things, to evaluate a very complicated mathematical function. In the logical style, you are instructing the program to find objects that satisfy a complex condition.

Here's a table of common languages:

Abstraction | Procedural    | OO
Control     +---------------+------------
Imperative  | C             | C++, Java
Functional  | Scheme, ML    | OCaml, Haskell, Lisp (under CLOS)
Logical     | Prolog        | Curry

A lot of these languages actually cut across the table in various ways. If a language is capable of OO, I've put it in the OO section, even if it has procedural capabilities as well. In fact, all of these languages have procedural capabilities except Java (which still does, but tries to deny it).

Anyway, what I'm wondering has to do with the control style. Three is a strange number for a classification. Usually classifications are powers of two: combinations of orthogonal binary capabilities. What are the orthogonal capabilities in the control style? What's the combination of those that has gone unnoticed?

Friday November 18, 2005
05:55 PM

### theory.pod sucks

In trying to prove some interesting properties about theories relating to multimethods, I stumbled upon this fact that completely invalidates them. I'm embarassed to post it here, since it is so simple and obvious that I should have seen it sooner. But, alas, I was cursed by my hubris, not verifying that the most essential properties held, and just assuming that they did. This is why mathematicians insist on being rigorous!

So, let's illustrate by example. Let's say we have a theory Ring{^T} that requires that ^T have a ring structure. We have a role Int for integers, and a role Nat for naturals. Let's also call the set of integers Z and the set of naturals N. Clearly N is a subset of Z.

Given Ring{Int} (the integers form a ring),
Int{Z} and Nat{N} by definition
Ring{^T} <= Int{^T}                  # expand model definition
N subset Z implies Int{N}, so Int{N} # role relation
Ring{N} since Int{N}.

But the naturals do not form a ring (under integer operations), though I seemed to have proven that they do. The error came in when I "expanded the model definition" from Ring{Int} to Ring{^T} <= Int{^T}.

This can be fixed. The changes necessary to fix this are very minor from the point of view of the theory user, but very major from the point of view of the theorist. In particular, they imply that theory expressions can no longer be reduced to first-order constraints on unnamed types. Instead, the system becomes unbounded-order, which is a bummer for the implementor.

However, I have that unbounded-order system almost entirely formulated in my mind. I'm pretty sure I can keep the benefits of theories while maintaining the solvability of an explicitly annotated system (we know that completely inferring a system this complex is equivalent to the halting problem and thus undecidable). I hope that it is also inferrable "most of the time". Updates soon.

Wednesday November 16, 2005
06:41 PM

### Today's Perl 6 Meeting Notes

Luke:
- hacking on Pugs a lot
- getting more comfortable with its internals
- now Haskell itself isn't an issue
- I just have to get my brain around Autrijus's brain, which is difficult
- but it's coming along
- thought also about the laws of Perl 6 builtins a little bit
- I can't come up with anything

Larry:
- it's like trying to think up the laws of English

Luke:
- reading "Types and Programming Languages"
- how would you implement an inferencer for a purely predicative system
like Theory?

Allison:
- checked in TGE last week
- that and refactoring and documentation took up my type last week
- I missed the implementors meeting because I forgot about it
- currently working on the AST in the Punie repository
- using the tree grammar stuff there
- I've just built up some node objects
- building up a tree grammar to go from Punie PGE output to AST
- the next step is nodes for the opcode syntax tree
- another grammar to go from the AST to the OST
- the last step is the little bit to compile the OST into Parrot
- will probably do something similar to Leo's PAST prototype
- it has the hooks for telling IMCC how to compile down a data structure

Larry:
- I have a commit bit!
- bright and shiny
- I shall have to use it shortly
- working on wreaking havoc on the Synopses this past week
- Luke has been very helpful in getting me to clarify my thinking in
places where it's too muddy
- other than that, just a lot of infrastructural things
- getting the latest Parrot things
- I can actually contribute on that level
- mostly I think I'll just be looking at tests and things
- checking validity
- also learning XSLT
- mostly because I don't think a language that that's ugly should be
able to do things that Perl can't
- this fits into the tree transformation stuff
- there are things it does better than attribute grammars
- they seem not to handle lists of children well

Allison:
- more toward named nodes

Larry:
- that's something we have to fix
- that's something XSLT does better

Luke:
- attribute grammars aren't that good at looking around

Larry:
- they're very constrained as to how you look around
- there's some power in that

Luke:
- have you seen CDuce?

Larry:
- I haven't looked at it

Luke:
- it has an interesting signature syntax

Larry:
- now wait, I did look at it

Luke:
- your list of predicate type signatures thing is reminiscent

Larry:
- that was some of the grist
- you're explicit about AND and OR in CDuce
- I did look at that

c:
- does XPath add better selectors to XSLT
- or does it have better node selectors on its own?

Larry:
- it's procedural, but more top-down

Luke:
- sort of like a regular expression?

Larry:
- yeah
- sort of like a hierarchical SQL statement
- we do need a better syntax than XML though
- may take another whack at my Perl 5 -> Perl 5 thing
- try to do that with XSLT instead of Perl

c:
- that's what I tried to do a few years back
- I learned that you can be right and still fail with bad code

Patrick:
- primarily worked on S5
- checked in the latest draft I sent out
- it's not on the website yet

Jesse:
- I believe Robert has a daily cron update

Patrick:
- I'm happy to make corrections if anyone has comments

Larry:
- you could make yourself the maintainer too

Damian:
- I'm planning to send you some minor feedback

Patrick:
- I also tried to reduce some redundancies
- if I omitted anything, let me know
- more updates to the grammar engine
- now does lookbehinds, though it cheats for now
- a variety of other small rules
- mostly doing some internal Parrot things
- driven by the desire to have Unicode work
- better string escaping

Damian:
- very good job on S5 too, by the way

Larry:
- convenient, that he's the one implementing it

Patrick:
- it's much easier to cut than it is to create

Larry:
- for you, maybe
- I'm too sentimental

Patrick:
- give me a knife
- I'm ruthless when it comes to prose

Luke:
- speculating is too much fun

Patrick:
- just catching up with other updates
- continuing on with this path
- one nice thing from the past week is the lexical stuff implementation
- that's a big plus
- it opens another door for me to continue pushing forward

Damian:
- I've been busy
- had the most appalling jetlag after I returned to Australia
- this week I'm away teaching in Melbourne
- next week too
- earning a living gets in the way of *everything*
- I have a whole backlog of postings to read and think about
- especially from Larry
- life stacks up while I'm traveling

c:
- I poked at Parrot::Test a little bit
- I'm stuck thinking about how to change STDOUT/STDERR

Jesse:
- someone sent mail to TPF
- an editor of the "For Dummies" books wants a date on Perl 6
- Andy Lester asked me for completion or milestone dates
- I've tended to stonewall on this
- they're getting it cheap
- we want it good
- sticking dates on things won't do anyone any good
- what do you think?

Allison:
- that's what I've always said
- we explicitly do not have scheduled dates
- the editor in this case wanted to know if there'd be a release this year
or next

Jesse:
- that's sort of a "maybe"

Luke:
- not *this* year

Allison:
- I told her there may be a beta at the end of next year
- she wanted to know if she should publish a book on it now

Jesse:
- is there any way that fixing dates to anything might help you all out?

*not really*

Allison:
- I work on the internal date of "as soon as possible"

Luke:
- it seems that putting pressure on people in OSS projects tends to make
them lose interest

Jesse:
- I agree, but there are a few notable exceptions

Luke:
- actually, when I have due dates for school, I work on Pugs!

c:
- shave a yak, write Perl 6

Jesse:
- is anyone blocking?
- no answer makes my life better
- okay, questions

Luke:
- Patrick, Autrijus and I were talking about porting PGE to Perl 6
- not for the fast side, but for the working side
- supporting you get PGE stable, would you be interested in helping?

Patrick:
- sure
- it's stable now

Luke:
- I thought so

Patrick:
- you want a Perl 6 implementation?

Luke:
- alternate runcores could use it then
- even though it'd be slow

Patrick:
- the biggest issue is being able to parse expressions into a match tree
- I did the first version with a rec-descent parser
- now it uses the precedence table which is much nicer
- I'd have to look and see what it would take
- I don't want to get sidetracked
- but I can certainly help if you have questions

Thursday November 10, 2005
03:21 PM

### Today's Perl 6 Meeting Notes

Patrick:
- lots more stuff with PGE
- sent out a message on Friday
- now support for commit operator, Unicode characters (as far as Parrot
can), hex, octal, newline, conjunctions, subrules with arguments,
documented public interface
- it helps that particle has created so many tests
- so have the Tcl guys
- beyond that, just catching up with Chip's draft design documents
- going to do parser things next

Allison:
- working on the tree grammar stuff
- have it checked into my local mirror
- haven't merged it back into mainline yet
- Parrot has some extraneous requirements on new files
- converting some of my little test scripts to test files
- I couldn't run tests until I added libraries into Parrot repository
- Patrick, what's your advice on where to put the test files?
- PGE keeps the test files in the Parrot hierarchy
- for the language, I want the tests in the languages/ directory

Patrick:
- PGE's tests went in the Parrot thing because of Dan's advice
- PGE is a part of Parrot
- I separated them out as p6rules tests
- there are several different syntaxes to do pattern matching
- Perl 5 rules, for example
- in this case, if we consider TGE as a part of Parrot, then it goes in
the Parrot repository
- or sensibly a subdirectory in compilers/ subdirectory

Allison:
- I'll do that for now
- it's not a big deal to move them later

Larry:
- some overhead with work and family
- otherwise hanging out on p6l and p6c
- thinking about design issues for roles and things
- thinking about some of Patrick's regexp issues too
- actually writing a few Perl 6 programs to see if it feels right
- running into interesting Pugs bugs there
- also playing with attribute grammar stuff and thinking about tree
transformation syntax

Jesse:
- did Autrijus send out the doc that he and Liz have started to put

Larry:
- I didn't see it

Jesse:
- I encouraged them to show it to people who've done stuff in Perl 5
- then make it public
- how's the response to licensing stuff been, Allison?

Allison:
- just a handful of responses
- most questions were from the Perl 5 cabal about the amount of time
required to turn in their agreements
- they wanted more than a week
- it'll be more like six months

Jesse:
- it should last through at least a conference season for in person
haranguing

Patrick:
- I thought it looked clear and well-defined
- I wish other open source licenses were as clear as this one

Jesse:
- the only one that blew me away was Microsoft's clear and simple group of

Larry:
- I've been trying to recompile Pugs
- I get a weird message from GHC about unrecognized "-i" flags
- GHC 6.4.1
- one of these years I'll have to start submitting some tests myself

Jesse:
- have you been submitting bug reports?

Larry:
- I mentioned one on the list
- I don't know what my commit procedure would be
- I haven't taken anyone up on a commit bit

Jesse:
- I can make sure that you get relevant documentation
- that'll make the Pugs crowd very happy

Patrick:
- I'm still eager for S05 to show up

Jesse:

Patrick:
- yes
- I'm getting enough questions from people that it'd be nice to have a
document point to

Jesse:
- is there any reason not to put a big warning on top of the last draft
and check it in?

Patrick:
- I have no problem with that
- the only thing that may change is the whitespace flags
- we can put a notice around that
- other than that, it looked good

Larry:
- anything new is good

Patrick:
- Damian has the latest draft

Larry:
- what's the status of the S29 draft?

Patrick:
- there's one in the Pugs repository
- I could review it and pass it around

Larry:
- at some point we should do it

Patrick: