Stories
Slash Boxes
Comments
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

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Friday January 12, 2007
03:51 PM

Perl 6 Design Team Minutes for 10 January 2007

[ #32133 ]

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:

  • that's right

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:

  • is he still in contact?

Larry:

  • I see him on IRC rarely

Nicholas:

  • Damian, has it really been that quiet for the Perl 6 POD reception?

Damian:

  • yes

Nicholas:

  • good

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:

  • yes

c:

  • hope so
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.