Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: What criteria mark the closure of perl6 specification

13 views
Skip to first unread message

Chromatic

unread,
Feb 25, 2007, 12:32:49 PM2/25/07
to perl6-l...@perl.org, Richard Hainsworth
On Saturday 24 February 2007 22:42, Richard Hainsworth wrote:

> But while perl6 continues
> its evolution, without a tangible end, few are going to dedicate time
> and effort to write documentation for such as me. (eg. How out of date
> are the Exegesis files?)

You could make a very similar argument for Perl 5. I'm not sure anyone
expected--as recently as a year ago--that 5.10 would get a slew of new regex
features, for example.

-- c

Richard Hainsworth

unread,
Feb 25, 2007, 1:42:22 AM2/25/07
to p6l
When does the specification of perl6 come to an end? Are there criteria
or milestones which define that the perl6 specification stage is at an end?

I can see that setting a time line is not easy because the effort is
volunteer based, but what about a "conceptual" end?

Perhaps there could be a perl6.0 specification, with further changes
(syntactic sugar, new operators, renaming operators, etc) being
assigned/incorporated into a perl6.1 specification, etc.

I ask because I want to use perl6 for real things. Which means I need
the help of tutorials and existing code to see how to use the richness
of the language for the things I want, and to be able to use existing
perl5 CPAN modules. For I am not a guru or lambdacamel, who can grok the
C and Haskell and make things work that dont. But while perl6 continues

its evolution, without a tangible end, few are going to dedicate time
and effort to write documentation for such as me. (eg. How out of date
are the Exegesis files?)

pugs is great, so far as it goes (only the simplest perl5 modules can be
accessed and sometimes only in a roundabout way - I've written a simple
test that kills pugs dead, which arose when I tried to use a perl5 module).

While perl6 remains unstable in its specification (or is perceived to be
that way) and is looking (from outside a select group?) like a unending
road, wont this act as a deterrent to those who want to help hack it
into existence, usefulness and stability?

Richard

Herbert Breunung

unread,
Feb 25, 2007, 12:44:17 PM2/25/07
to perl6-l...@perl.org
hi richard


>(eg. How out of date are the Exegesis files?)

very *g* just use the synopsis *g*

herbert
(proton-ce.sf.net)
_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

cma...@gmail.com

unread,
Feb 25, 2007, 12:57:27 PM2/25/07
to perl6-l...@perl.org
herbert (>), Richard (>>):

> >(eg. How out of date are the Exegesis files?)
>
> very *g* just use the synopsis *g*

Hm, it might actually be a good idea to port the code examples from
the Exegeses to current Perl6, preferably also runnable in Pugs. The
ported programs could be put under examples/ in the Pugs repository.

Though short on time as always, I'll see what I can do to this end in
the next few days.

--
masak

Patrick R. Michaud

unread,
Feb 25, 2007, 1:17:25 PM2/25/07
to Richard Hainsworth, p6l
On Sun, Feb 25, 2007 at 09:42:22AM +0300, Richard Hainsworth wrote:
>
> While perl6 remains unstable in its specification (or is perceived to be
> that way) and is looking (from outside a select group?) like a unending
> road, wont this act as a deterrent to those who want to help hack it
> into existence, usefulness and stability?

Just to add another perspective... I should note that ongoing
changes to the perl6 specification have _not_ been obstacles
or deterrents to getting the Perl 6 on Parrot implementation
in place -- in fact, they've been uniformly helpful.

The delays in the Perl 6 compiler for Parrot have been largely
due to other items, including time and the design work needed
for some of Parrot's compiler subsystems, libraries, and tools.

Pm

Herbert Breunung

unread,
Feb 25, 2007, 1:02:27 PM2/25/07
to perl6-l...@perl.org
or include a disclaimer that they are outdated as juerd sugested,
or do both. anyway this is an issue since google finds the A and E first.
im really intrested if im with juerd the only one here seeing this as an
issue.

thanks
herbert
proton-ce.sf.net

Smylers

unread,
Feb 25, 2007, 1:49:33 PM2/25/07
to perl6-l...@perl.org
Richard Hainsworth writes:

> When does the specification of perl6 come to an end?

At a guess: when it's implemented.

Many of the recent changes have been made by Larry in response to his
trying to write the grammer, and encountering problems.

> Perhaps there could be a perl6.0 specification, with further changes
> (syntactic sugar, new operators, renaming operators, etc) being
> assigned/incorporated into a perl6.1 specification, etc.

There would be no point in freezing a specification that isn't
implementable. If we had labelled the spec as it was a year ago as
"Perl 6.0" and all subsequent changes as being part of "Perl 6.1" that
wouldn't've made any practical difference: it would be Perl 6.1 that
everybody was trying to implement!

Or to put it another way, feel free to assign the label "Perl 5.93714"
to a snapshot of the current spec, the state that it is in right now.
Then we can all agree that Perl 5.93714 will never change. But I doubt
it will help.

> While perl6 remains unstable in its specification (or is perceived to
> be that way) and is looking (from outside a select group?) like a
> unending road, wont this act as a deterrent to those who want to help
> hack it into existence, usefulness and stability?

If it's any comfort the road doesn't look anywhere near as unending as
it used to be! Many recent changes have been consolidatory, or
relatively minor syntax tweaks -- not deep changes to the core of the
language. Larry writing the grammar is a tangiable task which should
have a natural end, hopefully getting us to a relatively stable point
where the spec is at least consistent and implementable.

There are still some 'hey wouldn't it be great if ...' threads on this
list, proposing brand new features, but nowhere near as many as there
used to be. And at least some of us are trying to discourage such
things, hoping to deflect them away from taking Larry's time away from
getting finished synthesizing what we already have -- especially in the
case of things which could easily be provided by a module.

Smylers

Jonathan Lang

unread,
Feb 25, 2007, 3:15:18 PM2/25/07
to p6l
Smylers wrote:
> Richard Hainsworth writes:
> > When does the specification of perl6 come to an end?
>
> At a guess: when it's implemented.
>
> Many of the recent changes have been made by Larry in response to his
> trying to write the grammar, and encountering problems.

With all due respect:

Once the grammar is written, what's left to do in terms of finalizing
the Perl 6.0 specification? Surely we don't need to wait for the Perl
6 implementors to finish their work before declaring 6.0 to be fully
specified (and getting on with the business of working on 6.1
features)? Admittedly, the best way to know if something is
implementable is to implement it; but I doubt that it's the only way.

> There are still some 'hey wouldn't it be great if ...' threads on this
> list, proposing brand new features, but nowhere near as many as there
> used to be. And at least some of us are trying to discourage such
> things, hoping to deflect them away from taking Larry's time away from
> getting finished synthesizing what we already have -- especially in the
> case of things which could easily be provided by a module.

I submit that you'll have even more luck discouraging such things if
you can give a reasonable and believable timeline as to when the 6.0
spec will be ready and perl 6.1 features can start being considered.

--
Jonathan "Dataweaver" Lang

Larry Wall

unread,
Feb 25, 2007, 1:36:09 PM2/25/07
to p6l
On Sun, Feb 25, 2007 at 09:42:22AM +0300, Richard Hainsworth wrote:
: When does the specification of perl6 come to an end? Are there criteria
: or milestones which define that the perl6 specification stage is at an end?

It seems you are presuming a Waterfall model of development here.
We're not doing the Waterfall, we're doing the Whirlpool, where the
strange attractor whirls around with feedback at many levels but
eventually converges on something in the middle. In other words,
a whirlpool sucks, but the trick is to position your whirlpool over
your intended destination, and you'll eventually get there, though
perhaps a bit dizzier than you'd like.

: I can see that setting a time line is not easy because the effort is

: volunteer based, but what about a "conceptual" end?

The problem with the Waterfall chart is that is assumes the designers
are smart enough to design something in the absence of feedback from
the implementors. I'm certainly not smart enough to do that. Many of
the recent design changes have been driven by the problems we find
while implementing. I'm not primarily speaking of syntactic problems
here, but semantic and pragmatic problems. We're fixing some things
that are not as simple as they could be, and other things that are
not as *complicated* as they should be. Often both of those things
are happening with the same design change, but at different levels.
For instance, on one level, the recent decision to apply multi
semantics to tokens and rules makes them seem more complicated, but it
also unifies the notion of multiple dispatch across more categories,
and makes it much easier to write derived grammars that can override
part of a named rule. This is something I didn't realize till I
started writing the grammar of Perl 6 in Perl 6 a few weeks ago.

: Perhaps there could be a perl6.0 specification, with further changes

: (syntactic sugar, new operators, renaming operators, etc) being
: assigned/incorporated into a perl6.1 specification, etc.

Sugar is not really the issue here. We'll feel free to change the
sugar willy nilly right up until the time 6.0.0 officially rolls
out the door. When 6.0.0 is out the door, then we officially start
worrying about backward compatibility, but not before. My primary
concern right now is to make sure everyone is converging on a workable
*semantic* model.

: I ask because I want to use perl6 for real things.

How shocking! :-)

: Which means I need

: the help of tutorials and existing code to see how to use the richness
: of the language for the things I want, and to be able to use existing
: perl5 CPAN modules. For I am not a guru or lambdacamel, who can grok the
: C and Haskell and make things work that dont.

There are lots of things we can use help with that don't involve knowing
C or Haskell. Shoot, *I* don't know Haskell, and I've already learned
it several times. Why do you thing I'm writing the grammar in Perl 6? :-)

: But while perl6 continues

: its evolution, without a tangible end, few are going to dedicate time
: and effort to write documentation for such as me. (eg. How out of date
: are the Exegesis files?)

I agree that it takes a certain amount of vision to see the promised
land before we get there. I suppose it's only natural that people
wandering in the desert for 40 years will grumble a bit and maybe
set up a golden calf or two, or attempt to march into the promised
land on their own when they think it's right. But I must confess to
feeling a great deal of sympathy for Moses occasionally.

: pugs is great, so far as it goes (only the simplest perl5 modules can be

: accessed and sometimes only in a roundabout way - I've written a simple
: test that kills pugs dead, which arose when I tried to use a perl5 module).

Pugs is manna from heaven to keep us on our feet, but it's not normal food.

: While perl6 remains unstable in its specification (or is perceived to be

: that way) and is looking (from outside a select group?) like a unending
: road, wont this act as a deterrent to those who want to help hack it
: into existence, usefulness and stability?

As long as Joshua and Caleb see the promised land for what it really is,
I don't worry too much about what other ten spies think. The right people
will decide to work on Perl 6 at the right time if the vision is right.

Larry

Geoffrey Broadwell

unread,
Feb 25, 2007, 3:56:23 PM2/25/07
to Jonathan Lang, p6l
On Sun, 2007-02-25 at 12:15 -0800, Jonathan Lang wrote:
> I submit that you'll have even more luck discouraging such things if
> you can give a reasonable and believable timeline as to when the 6.0
> spec will be ready and perl 6.1 features can start being considered.

As I mentioned in another thread, but didn't make clear in that email: I
don't need a "finished" spec. I need the *current* version of spec to
actually be mostly implemented. I'm completely willing to surf a moving
spec, as long as I can have working or near-working[1] code the whole
time.

Some people are happy writing great gobs of code completely separate
from a working compiler purely for the mental exercise, but that doesn't
-Ofun for me. My programming style is extremely iterative, and I need
to be able to get something working right off the bat, or it's just not
fun for me. And if it's not fun, I won't end up putting any of my very
limited free time into it.


-'f

[1] "Near-working" in this case meaning "some feature's syntax just
changed slightly, and it will only take 5-10 minutes to get everything
going again."


Chromatic

unread,
Feb 25, 2007, 4:26:14 PM2/25/07
to perl6-l...@perl.org, Geoffrey Broadwell
On Sunday 25 February 2007 12:56, Geoffrey Broadwell wrote:

> As I mentioned in another thread, but didn't make clear in that email: I
> don't need a "finished" spec.  I need the *current* version of spec to
> actually be mostly implemented.

The implementors want the same thing.

> And if it's not fun, I won't end up putting any of my very
> limited free time into it.

Neither will the implementors.

-- c

Geoffrey Broadwell

unread,
Feb 25, 2007, 4:57:02 PM2/25/07
to chromatic, perl6-l...@perl.org

My apologies if what I said came across as critical; it wasn't intended
that way. I was merely trying to point out that there is at least one
user here that does not believe lack of a "finished" spec is the biggest
blocker for people wanting to switch to Perl 6. I don't believe that
the core team should be rushing the spec at all. That's just pushing
any possible issues from before first release to after first release,
and any team manager can tell you that's a recipe for making broken
things considerably more difficult/expensive to fix.

In the early days, the extreme flux of the spec was a bit of an issue,
because being away for a couple weeks meant that things had changed A
LOT in the intervening time. That doesn't seem true any more. Even for
a user with limited time, the current pace of changes don't seem
daunting to keep up with. Rather, the problem is that many things have
yet to work at all.

I'm not trying to say that the implementors should rush either, nor am I
complaining about current status; I grok the dynamics of volunteer code.
I merely disagree with the "spec is all-important" crowd. I personally
have a preference for "rough consensus and working code", and I wanted
to make sure that viewpoint wasn't lost.


-'f


Chromatic

unread,
Feb 25, 2007, 5:16:05 PM2/25/07
to Geoffrey Broadwell, perl6-l...@perl.org
On Sunday 25 February 2007 13:57, Geoffrey Broadwell wrote:

> I'm not trying to say that the implementors should rush either, nor am I
> complaining about current status; I grok the dynamics of volunteer code.
> I merely disagree with the "spec is all-important" crowd.  I personally
> have a preference for "rough consensus and working code", and I wanted
> to make sure that viewpoint wasn't lost.

Me too. I also want to point out that we're not nearly at the point where
adding more developers--for as much or as little as they want to
contribute--will slow things down.

-- c

Smylers

unread,
Feb 25, 2007, 5:42:15 PM2/25/07
to perl6-l...@perl.org
Jonathan Lang writes:

> Smylers wrote:
>
> > Richard Hainsworth writes:
> >
> > > When does the specification of perl6 come to an end?
> >
> > At a guess: when it's implemented.
> >
> > Many of the recent changes have been made by Larry in response to his
> > trying to write the grammar, and encountering problems.
>
> With all due respect:
>
> Once the grammar is written, what's left to do in terms of finalizing
> the Perl 6.0 specification?

Yeah, that's why I said "implemented" then immediately referred to
writing the grammar, purposefully fudging exactly what level of being
implemented is needed!

> Surely we don't need to wait for the Perl 6 implementors to finish
> their work before declaring 6.0 to be fully specified (and getting on
> with the business of working on 6.1 features)?

Maybe. The tricky bit is being sure that there isn't an awkward spot in
there somewhere which nobody notices until encountering it when trying
to run programs. It could be foolish to be in a position where Perl 6
hasn't yet been released but problem with it can't be addressed because
the spec has already been frozen.

Smylers

Geoffrey Broadwell

unread,
Feb 25, 2007, 6:11:27 PM2/25/07
to chromatic, perl6-l...@perl.org

Hmmm. Let's see if there is a way I can help to get what I want ....

Assuming that the answer to my question in the other thread is "packed
arrays aren't implemented anywhere yet", are any implementations close
enough that I can trade tests for implementation? Given my programming
style, creating a big pile of tests all at once won't really work (I'll
just end up creating a bunch of bad tests). But I could probably loop
over "add a couple tests, implement piece of feature, add a couple more
tests, implement another piece, ..." with someone.

It wouldn't be a particularly *fast* iteration, but at least there would
be some movement ....


-'f


Gabor Szabo

unread,
Feb 28, 2007, 1:24:43 AM2/28/07
to Geoffrey Broadwell, chromatic, perl6-l...@perl.org
On 2/26/07, Geoffrey Broadwell <ge...@broadwell.org> wrote:
> Hmmm. Let's see if there is a way I can help to get what I want ....
>
> Assuming that the answer to my question in the other thread is "packed
> arrays aren't implemented anywhere yet", are any implementations close
> enough that I can trade tests for implementation? Given my programming
> style, creating a big pile of tests all at once won't really work (I'll
> just end up creating a bunch of bad tests). But I could probably loop
> over "add a couple tests, implement piece of feature, add a couple more
> tests, implement another piece, ..." with someone.
>
> It wouldn't be a particularly *fast* iteration, but at least there would
> be some movement ....

wow, I think that's exactly the point.
Just write a missing test that fails as there is no implementation yet,
commit it to the Pugs repository and sooner or later someone will
implement the feature.
Then go to the next part og thre feature.

I wishe there were many people out there writing tests for not-yet
implemented features.

Gabor

0 new messages