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
Friday January 12, 2007
Perl 6 Design Team Minutes for 10 January 2007
The Perl 6 Design team met via phone on 10 January 2007. Larry, Damian, Allison, Jesse, Nicholas, and chromatic attended. These are the notes.
- 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
- 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
- the next thing we need before implementing the PDD is the objects PDD
- I've been working on that this week
- 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
- seems to be some demand for that
- it's high on my priority list
- taking some down time to feel better and ramp up
- 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?
- is it Luke's pure proposal?
- 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
- has he been making much progress?
- 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
- 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
- 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
- I was just hoping it would be a pamphlet
- 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
- you just pass the pumpkin and when the music stops, you make a release?
- Jerry's sure demonstrated that he's a trooper
- 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
- 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
- if your only resolution mechanisms are to go to a global default or to go with left- (or, equally right-) most wins
- I was thinking of the default being local to the current ambiguity set
- multiple defaults for current semicolon levels?
- 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
- for that particular ambiguity set
- I'd really like to see a syntax for that
- 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
- and if they're ambiguous?
- they will be
- I can see two equally specific defaults turning up
- 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
- we're definitely dealing with edge cases here
- 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
- 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
- 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
- but pointing people to a file might get you to the Perl 5 problem where the implementation specifies the behavior
- unless you version the file
- I thought it would be a Synopsis
- I thought you meant a source file!
- 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
- when you said "lexical scope" I thought you meant the person defining
- and I thought calling, but....
- just hate to get into the Perl 5 trap of having to worry about changing anything because it breaks someone's code
- if you rely on an old semantic, then you have to request that that interface give you that version of semantics
- how do you know when the current becomes old?
- 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
- 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
- that's perhaps the best way to do it
- maybe "is default" means "autogenerate this for me"
- 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
- a lot of people think they understand voting, but they don't
- a lot of people know they don't understand vector math
- is there a lightweight way to declare a specific variant signature that aliases to a general case?
- 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
- 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
- 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
- the other problem with doing the thing in the body is that you'll do the dispatch again
- notionally it's done with the magic goto
- you'll expect the call frame on the stack
- or you're lying and inconsistent
- a compile-time referential assignment is an excellent idea
- we have syntax, but it may not be optimal
- has Sage shown any more interest in 5 to 6?
- he's pretty busy with school
- Damian, has it really been that quiet for the Perl 6 POD reception?
- I did have a couple of offline comments which I addressed in the second draft
- have you given any thought to using metaroles instead of metaclasses in the objects PDD?
- I'm still thinking of separating those currently
- 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
- anything you can do, I can do meta
- I never meta-model that wasn't obsessed with reflection
- that's why I took a month off
- 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?
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.