The Perl 6 Design team met via phone on 10 January 2007. Larry, Damian, Allison, Jesse, Nicholas, and chromatic attended. These are the notes.
Allison:
- things are quite well
- worked on Punie some
- adding a few more features: subroutines in specific
- went astoundingly quickly
- a few small IO questions remaining
- sort of a lazy evaluation on the list
- thank you for your comment yesterday
Larry:
- I sent another one today
- how much abstraction do you want?
- there are ways to hide things that may or may not buy you any performance
Allison:
- the next thing we need before implementing the PDD is the objects PDD
- I've been working on that this week
Damian:
- things are quiet here
- took some time off
- doing a lot of family stuff
- that'll continue into the foreseeable future
- sending tiny bits of feedback to Larry on occasion
- mostly very happy with what I've seen
- otherwise starting to gear up for the year ahead
- want to get the POD 6 parser out
Larry:
- seems to be some demand for that
Damian:
- it's high on my priority list
- taking some down time to feel better and ramp up
Larry:
- mostly recovered from my own bout with the crud
- this one seems to asymptotically approach asymptomatic
- alternately horrifying and pleasing Damian in absentia
- have most of the re-think of smart matching done
- moved on to reading and re- and re-re-reading the MMD draft
- is it possible, optimizable, and teachable?
- is there a different angle to approach it that's easier to explain but has well-defined semantics and is teachable that I can understand?
c:
- is it Luke's pure proposal?
Larry:
- a bunch of people hashed it out based on that
- you don't calculate distance
- that doesn't work well with roles and subtypes
- you can just say that this is narrower or wider than this one
- you have to avoid too many ties
- we've always had these semicolons that do this Australian preference voting
- count my vote here only if there's a problem with my first preference
- seems to be a decent notional way to solve these things
- but the devil is in the details
- the current draft lets all of the candidates vote
- they each have to keep their own scorecard as to what they think counts
- there may be a different way of looking at the same thing that involves going forward with a series of semicolons terminating
- then finding a tie and backing up to a previous set of semicolons and revote
- I'm trying to reformulate that in words to see if it means the same thing and is easier to grok
- also trying to keep Flavio on track for the MiniPerl bootstrap
- hopefully his direction will also be complementary to the world of Parrot
Jesse:
- has he been making much progress?
Larry:
- he's sort of a Lewis and Clark type
- blazing the initial trail
- it's hard to stop him
- he's working on KP 6, or Kinda Perl 6
- next step of getting a compiler written in Perl 6 that looks like Perl 6
- coming at it orthogonally
- trying to get a platform-agnostic bootstrap
- Patrick and Allison have more or less a bottom-up bootstrap
- Haskell was the top-down bootstrap
- but it's hard to find people who like Perl and work on Haskell
- it does seem like it's converging and will happen eventually
- the holidays were tough for sickness and holidays and the Taiwan earthquake
- Audrey's been out of touch
- the MOP folks have been on hiatus
- I suspect they'll pick up shortly
Nicholas:
- the semicolon thing sounds ambiguous and hard to understand
- it scares me that it'll end up in the C++ problem
- is it a function declaration or what?
- those ambiguities make C++ hateful
- maybe some of these optional things shouldn't be
- but you know better than me
Larry:
- it may be best practice, by convention at least, to avoid putting semicolons in contradictory places
- we have to give Damian something to work with for Perl 6 Best Practices
Damian:
- I was just hoping it would be a pamphlet
Jesse:
- the People's Coup of Parrot appears to be proceeding cleanly
- Jerry will cut the next release next week
- we'll have a new pumpking every month
- the cabal now has Parrot permissions
Nicholas:
- you just pass the pumpkin and when the music stops, you make a release?
Jesse:
Larry:
- Jerry's sure demonstrated that he's a trooper
Damian:
- just observations about the current MMD resolution proposal
- I echo Larry's concerns about the high probability of ambiguity
- under the scheme, the proposed solution is "insert more semicolons"
- that leads to a leftmost-argument wins scheme
- other languages have tried that and found it wanting
- many of the few languages that have multi-methods use that scheme
- look at the first argument and choose the best match at that point, then the next point, then....
- that's unsatisfactory
- it biases the selected method toward the first argument
Larry:
- doesn't get you much over nested switch statements
- S12 still talks about marking the default
- I don't think we would lose that
- it's not in the proposal, but I think they say that when you end up with a tie that no one specified a default
Damian:
- if your only resolution mechanisms are to go to a global default or to go with left- (or, equally right-) most wins
Larry:
- I was thinking of the default being local to the current ambiguity set
Damian:
- multiple defaults for current semicolon levels?
Larry:
- sort of orthogonal to whether there are semicolons there or not
- number + int versus int + number
- there's a num + num too
- maybe this is a bad example
- you could mark one of the two symmetrical ones as the default
Damian:
- for that particular ambiguity set
- I'd really like to see a syntax for that
- challenging
Larry:
- just an "is default" declaration maybe
- if you get an ambiguity, you'll always take the most specific default that is in the list of permissible candidates
- I think that works
Damian:
- and if they're ambiguous?
- they will be
- I can see two equally specific defaults turning up
Larry:
- then you're no worse off than you were before
- to some extent, I want to say that we can define all of this mechanism, but most multimethods will only have two things with named options maybe
- most people will put a prototype in their so their compiler can figure out what the call will look like anyway
Damian:
- we're definitely dealing with edge cases here
Larry:
- how much embroidery do we want to handle to nail down the edge cases?
- if we can figure out the most specific candidate, we'll call that
- if we can't, we won't
- it's usually obvious, when you compare any two things, which is strictly narrower than the other one
- beyond that, you're getting into heavy magic and you want to learn some more
- most people don't want that
- those specific rules might not even go in the Camel book
- go read this file for the nitty-gritty details
Nicholas:
- do we have to nail down all the edge cases yet?
- if it dies with ambiguity, then people using Perl 6 will start to produce ambiguities
- we'll have a lot of use cases to work out which way it should be
- there may be a danger of picking arbitrary rules that surprise people
- you have to treat this as an N-dimensional search
Larry:
- we probably don't know enough yet
- the fact that we defined this to start with lexical scope
- we can substitute in different policies in lexical scopes
- maybe deprecate the current policy in favor of a new policy in a new version
Nicholas:
- but pointing people to a file might get you to the Perl 5 problem where the implementation specifies the behavior
Larry:
- unless you version the file
Jesse:
- I thought it would be a Synopsis
Nicholas:
- I thought you meant a source file!
Larry:
- there is a conflict between the definer of a set of multimethods and the user of the set
- they could expect different semantics
- we have to make some minimal attempt at defining some mechanism that will work from the view of the person defining the set
- we can't leave it only up to the user
Nicholas:
- when you said "lexical scope" I thought you meant the person defining
Larry:
- and I thought calling, but....
Nicholas:
- just hate to get into the Perl 5 trap of having to worry about changing anything because it breaks someone's code
Larry:
- if you rely on an old semantic, then you have to request that that interface give you that version of semantics
Nicholas:
- how do you know when the current becomes old?
Larry:
- either you default to the current
- or if the current changes, you start a deprecation cycle
- we'll change the semantics, but we'll pay attention to the requested version of the semantics
- that and a higher bar for CPAN modules specifying their version
- we require anything going into the library to have a version number
- you can build a Foo.pm without a version number and use it
- but installing anything into an official library requires a version number
Damian:
- regardless of the MMD algorithm that you choose, you can always resolve ambiguities by declaring another variant
- if your application defines a number of variants and you get ambiguities, you can always define more specific variants
- even if they do nothing more than wrap a particular variant that you want
Nicholas:
- that's perhaps the best way to do it
Larry:
- maybe "is default" means "autogenerate this for me"
Damian:
- you get one of those for free
- any more you have to pay for yourself
- in that regard, we don't have to get all of the edge cases
- different people will have completely different intuitions
- people will think about this in entirely different ways
- the current proposal uses a voting metaphor
- the earlier proposals I had thought in terms of multidimensional vectors
- they're two entirely different approaches to the thing
- maybe 80% of the time they end up with the same answer
- it's not necessary for us to define the edge cases, except to document that writing another variant will do what you expect
- the deeper problem is teachability
- even if you don't give them an algorithm, you have to give them a metaphor
- one comes from sociology and one comes from physics
Larry:
- a lot of people think they understand voting, but they don't
- a lot of people know they don't understand vector math
c:
- is there a lightweight way to declare a specific variant signature that aliases to a general case?
Larry:
- you'd have to use the &name variant which includes an addendum
- doesn't look like a normal variation of a new sub
- or maybe we allow you to start with a normal declaration but instead of a body it's
::= something else
Damian:
- or when you have an MMD variant whose body consists of entirely a call or a magic goto, you optimize it
- it'd be nice to have a proper syntax with the referential nature
Nicholas:
- but with the dynamic wrapping, someone can change the definition and expect its definition to be the one
- hopefully the binding type thing will cause the compiler to cause hissy fits
Damian:
- the other problem with doing the thing in the body is that you'll do the dispatch again
Nicholas:
- notionally it's done with the magic goto
- you'll expect the call frame on the stack
- or you're lying and inconsistent
Damian:
- a compile-time referential assignment is an excellent idea
Larry:
- we have syntax, but it may not be optimal
Nicholas:
- has Sage shown any more interest in 5 to 6?
Larry:
- he's pretty busy with school
Nicholas:
Larry:
Nicholas:
- Damian, has it really been that quiet for the Perl 6 POD reception?
Damian:
Nicholas:
Damian:
- yes
- I did have a couple of offline comments which I addressed in the second draft
c:
- have you given any thought to using metaroles instead of metaclasses in the objects PDD?
Allison:
- I'm still thinking of separating those currently
- although...
- I hadn't been thinking of making separate metaobjects for both
- I thought of making them a single core meta thing
- I wasn't going to call it meta
Larry:
- anything you can do, I can do meta
c:
- I never meta-model that wasn't obsessed with reflection
Damian:
- that's why I took a month off
Nicholas:
- the existence of interfaces in Java lessens the need for multiple inheritance
- does the existence of roles in Perl 6 make multiple inheritance less necessary?
Larry:
c:
