Patrick:
- customer project deadlines keep jumping and scopes keep creeping
- the deadline is next Wednesday
- I should be done then
- did send Allison an e-mail about the operator precedence parser
Jesse:
- you'll go into the Perl 6 parser then?
Patrick:
- yes
- maybe adding some features to PGE driven by parser demands
Larry:
- also have a work deadline
- but sneaked in a synopsis change from "till" to "ff"
- threw some conjectural stuff in S12 to bless ^ as a shorthand for .meta
Luke:
- I think it's important to keep the difference between a type and a
package concrete
- I thought ^ was for types
- I'll see what I make of your changes and *then* whine
Jesse:
- P5 to P5 is still about 95%?
Larry:
- haven't done anything on that in the last week
Luke:
- enjoying my processor arch class
- might dive into Parrot to apply some of my knowledge in a while
- otherwise working on an algorithm and paper to dispatch pure
multimethods as fast as possible
- can also incorporate compile-time information if it's available
- getting those two things at once is pretty hard
- the algorithm is still in progress
- I can build a decision tree that dispatches to the right multi-method
provably with as few checks as possible
- you can rule out some candidates based on compile-time information
- you can use a bit of the theory that falls out of that to do type
inference
- that's probably a couple of weeks away
- it might be worth a senior thesis
Allison:
- Punie almost does simple if statements
- meeting with Chip in a bit
- I'll work on operators next
- it looks like Patrick's solution might fix my problem
- have about five or six people reviewing AL 2.0
- don't know if I'll get any comments
- have one more week on it
Jesse:
- I asked to have that list created
- I haven't seen anything yet
- Chip answered some of Leo's questions on Monday
Luke:
- thinking about overriding stuff in classes
- attributes that have a constant value through the lifetime of an object
are different beasts from attributes that can change
- I'm searching for a way to make that distinction without imposing
horrible cognitive or finger blocks on people
Larry:
- like our readonly versus contant distinction?
- on ordinary variables
- bound in a constant way
- but not a constant
- different iterations of this function may have a different value
- can't optimize it away in that sense
Luke:
- the fact that attributes aren't read-only inside of an object causes
problems with inheritance
- that distinction may be nice to have if it works cognitively
c:
- is that an implementation detail not exposable?
Luke:
- more about the intent of its use rather than its actual use
